On Sun, May 17, 2020 at 12:02:20AM +1000, elvis wrote: > > On 16/5/20 10:15 pm, Henning Follmann wrote: > > On Fri, May 15, 2020 at 11:39:44AM -0700, Chris Rhodin wrote: > > > Hi, > > > > > > I've installed Debian Buster on a desktop system I use as a server. I > > > also > > > occasionally use this as a regular desktop system so it has a monitor, > > > keyboard, and GUI. During installation I selected the ssh server in > > > tasksel (so during installation there was some indication this was a > > > server). > > > > > > The problem I have is that when the console screen goes black and locks, > > > the system becomes unresponsive to network activity. If I have an ssh > > > session running when this occurs it stops responding. It doesn't kick me > > > off, the ssh connection is still there. If I then go to the console and > > > shake the mouse the screen lights up and the ssh session starts responding > > > like nothings wrong, until the console goes to sleep again. > > > > > > Searching online I found this command which seems to solve the problem: > > > > > > sudo systemctl mask sleep.target suspend.target hibernate.target > > > hybrid-sleep.target > > > > > > So my question is what is the correct way to manage this? Is there a > > > document that goes over the various power states and how they impact > > > running services? > > > > > > > > > ChrisR > > Just disable following targets: > > > > systemctl mask sleep.target suspend.target hibernate.target > > hybrid-sleep.target > > > > That will avoid the system going to sleep. > > Instead of doing that, wouldn't the "correct" way involve editing > /etc/systemd/sleep.conf ? > > > I ask because I edited the file and the system seems to have still gone to > sleep.. what is the point of a conf file if you still have to mess with the > base unit files? > >
How can it be "correct" if it doesn't deliver the correct result? Just say'n -H