>>> "Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx> schrieb am 12.08.2021 um 10:01 in Nachricht <6114D548020000A100043229@xxxxxxxxxxxxxxxxxxxxxxxx>: >>>> George Avrunin <avrunin@xxxxxxxxxxxxxx> schrieb am 12.08.2021 um 01:44 in > Nachricht <20210811194453.2dd47326@g.localdomain>: >> On Wed, 11 Aug 2021 15:24:25 ‑0700, Luis Chamberlain wrote: >> >>> On Wed, Aug 11, 2021 at 05:11:21PM ‑0400, George Avrunin wrote: >>> > Aug 07 14:09:22 ext.math.umass.edu kernel: ACPI: Preparing to enter >>> > system sleep state S3 >>> >>> That's suspend to ram. Depending on the distribution it may or not be a >>> a default after a period of time of idle. The idea is that moving a >>> mouse would resume it. For desktops this is stupid. Try: >>> >>> systemctl mask sleep.target suspend.target hibernate.target >>> hybrid‑sleep.targe >>> >>> To re‑enable: >>> >>> sudo systemctl unmask sleep.target suspend.target hibernate.target >>> hybrid‑sleep.target >>> >>> Luis >> >> Thanks, masking the sleep, etc., targets will presumably stop it. >> >> But I don't think it was a default setting to suspend after a period of >> being idle, at least not once the machine was back on AC power (unless >> something got reset somehow). This machine is used as a mail and web >> server, as well as for some computations that my students and postdoc run >> remotely, and it's never done this before when there was no activity at >> the console. (And during the pandemic, there's been very little activity >> at the console‑‑we've all mostly been working from home.) > > Considering my previos message, that may answer while it does not go to Sorry; the "while" above should read "why"... > sleep > while being connected. > >> >> So I'd still like to understand what caused it to start the suspend >> operation. If there's an easy way to get just a little bit more logging >> about that, it would help me and probably others. >> >> George