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?

  • If you are starting the web server from an ssh session, it will die when ssh disconnects unless 1) You start it via a systemd service, 2) You use nohup or better yet setsid when starting it: raspberrypi.stackexchange.com/q/9806/5538 – goldilocks Jul 15 '18 at 12:03
  • So, your answer that you provided a link to mentions sudo setsid --fork myscript.sh. does that mean I put sudo npm start into myscript.sh, then run sudo setsid --fork myscript.sh? or am I missing something? – Jacob Schneider Jul 15 '18 at 12:06
  • I used myscript.sh there because the question asks about a script. You would use sudo setsid npm start. I do not think you need the --fork because node.js will do that itself (are you should it's npm start?). "Fork" refers to going to background as a new process; if the command you are using normally returns right away that's what's happening. If instead it blocks (i.e., you don't get the command line back), use --fork. – goldilocks Jul 15 '18 at 12:37
  • 1
    ok, so use --fork because the node app runs an express server which listens, blocking up stdio – Jacob Schneider Jul 16 '18 at 9:14
  • Yes. I haven't used node in a long time ;) – goldilocks Jul 16 '18 at 11:36

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.

  • I did a bit of digging and discovered that the webserver was terminated as soon as putty goes offline. I had it running for not even 2 minutes, close putty and the server's offline. – Jacob Schneider Jul 13 '18 at 3:23
  • Did you started the server directly on the command-line via ssh? By "directly" I mean, not via a system service (sudo systemctl start server) but by invoking a long running executable (myserver.py). If so you should use nohup: raspberrypi.stackexchange.com/q/9806/5538 – goldilocks Jul 13 '18 at 11:25
  • No, I just type sudo npm start – Jacob Schneider Jul 14 '18 at 13:50
  • That's why it is getting snuffed after your ssh session ends. Again, try it with nohup or better yet setsid (I will edit that old answer to mention this, I should have said setsid to start with). – goldilocks Jul 14 '18 at 14:13
  • So, your answer that you provided a link to mentions sudo setsid --fork myscript.sh. does that mean I put sudo npm start into myscript.sh, then run sudo setsid --fork myscript.sh? or am I missing something? – Jacob Schneider Jul 15 '18 at 12:04

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.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.