Prevent Pi from sleeping on stretch lite

Question

I have a pi 3b running the latest raspbian stretch lite and I use putty to SSH into it because I don't have a monitor.

Anyway, I am using it to host a website, so I don't want the pi to go to sleep, yet after about half an hour, Putty tells me the session was terminated and the client has disconnected, I'm not sure this is putty's doing or the Pi's either way, I want to stop the pi from sleeping.

The command $setterm -blank 0 -powerdown 0 produces the following: setterm: terminal xterm does not support --blank

What do I need to do to stop it from sleeping?

Answer 1

Easiest question today! Answer: Do nothing! :) The Raspberry Pi is not sleeping... it doesn't have a sleep state (as @goldilocks states in his answer). PuTTY has simply terminated the session due to inactivity. Your RPi and any services (your webserver for example) will continue to run, and respond to http requests.

And wrt PuTTY, while this is not a PuTTY forum, and I've not used PuTTY in a while, I recall that there was a setting to prevent activity-based session termination. Under the Connection category in PuTTY Configuration, set the value Seconds between keepalives to some positive value greater than zero.

Answer 2

I want to stop the pi from sleeping

This is an XY problem, except fortunately you sort of mentioned X.

The Pi cannot go to sleep. It has three basic states, one of which is "unplugged". The other two are running and shut down. It cannot come back from the latter without rebooting it by cycling the power.

Your implied problem here is that the web server goes offline. If this is the case, you will have to diagnose that properly, starting by checking the logs.

Whether and when the SSH server on the Pi disconnects is a matter of how it is configured. Try editing /etc/ssh/sshd_config (you need superuser privileges for that, e.g., use sudoedit), find these fields, uncomment them (remove the #), and change their values:

ClientAliveInterval 120
ClientAliveCountMax 20

Then restart the server (sudo systemctl restart ssh <- Hopefully that is the right service name, if not try sshd). This will cut off your remote connection if that's how you do it, which is okay. You should be able to connect again right away unless you flubbed something in the config file, in which case you will have to fix it on the pi (a good reason to make a back up copy of sshd_config before you touch it).

To understand better what those options mean, have a look at man sshd_config. As explained there, this will mean unresponsive clients are cut off after being unresponsive for 40 minutes (120 seconds * 20).

Generally an "unresponsive client" refers to one which did not disconnect properly but is no longer replying to the server, meaning mostly likely the system it is on went offline (e.g., if your laptop goes to sleep).

There may also be parallel settings for PuTTY, I can't help you with that (but it looks like Seamus has already).

Starting processes via SSH

If you start something via the command line in SSH, that process is a child of the interactive shell (i.e., the command line interpreter) from which it was started, which is a child of the sshd process controlling your session -- which is started by the master sshd process, which is a child of the system's first process (init/systemd). Ideally, when you exit and the immediate ancestors of that something you started exit with you, the something (now considered an orphan) should be adopted by the first process. However, this may not work out, particularly if that something was running in the foreground.

Instead, you should either:

1. Start the process via nohup and background it:

   nohup [your process] &
   

   You can start it in the foreground with nohup, but the output (which is presumably why you wanted to run it in the foreground) will be redirected to a file (nohup.out). See man nohup for its general purpose; in short, it runs a "command immune to hangups". Hangup refers to the fact that when you leave a foreground process without a foreground (which exits with the ssh session), it receives a SIGHUP from the OS. This can be caught and handled by the process if it was programmed to do so, but if it was not (usually, they are not), the default reaction is to exit.

   And your server stops. In my experience a better solution than nohup is setsid, which starts a process "in a new session", meaning it will be a child of the first process (init/systemd) instead of your shell, sshd, etc.

   setsid [your process]
   

   By default when run from the command line, setsid should fork to the background, but it may not if you put it in a script. In this scenario (ssh) you want it to, so if it doesn't, add a & to the very end of the command (after any output redirection such as ^>).

   Newer version of setsid have an explicit --fork option; check man setsid to find out if this includes yours.

   If you want to watch the output, redirect it to a log file:

   setsid [your process] ^> my.log
   

   To now watch it, use tail -f my.log.

2. You can start a process in the foreground and come back to it latter via screen. This is not something I've done much, but if you search around online linux screen tutorial or gnu screen tutorial you'll find stuff.