Subject: | |
From: | |
Reply To: | ~Stack~ |
Date: | Thu, 9 Mar 2017 18:44:24 -0600 |
Content-Type: | multipart/signed |
Parts/Attachments: |
|
|
On 03/09/2017 12:14 PM, Konstantin Olchanski wrote:
> Hi, there. I wonder if anybody else is seeing the same problem with el7:
>
> The symptoms are: no ping, dead video, dead keyboard. After power cycle,
> syslog shows that the system has attempted to go into sleep or suspend
> or whatever they call it.
>
> This is very strange, usualy a system will go into suspend mode when you
> close the laptop lid, but these are not laptops. They are normal desktop
> machines (and at least in one case, there is no local user to blame for
> pressing the "sleep" button).
>
> So what's in the syslog:
> - normal activity (systemd spam)
> - network manager reports "sleep requested"
> - some kind of nm_dispatcher activity
> - systemd reaches sleep and suspend targets.
> - continues spewing sundry messages, never recovers (never goes into actual sleep).
>
> The machine is effectively dead after network manager put the network interfaces to sleep.
>
> The best google-advice I see it to disable the systemd sleep and suspend targets:
> systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target systemd-suspend.service systemd-hybrid-sleep.service
> (now waiting for this machine to go to sleep).
I had something very similar.
First, make sure on your EL7 boxes that your systemd journal is being
saved between reboots (peeves me off that this isn't default, but that
is another matter). Systemd doesn't log everything to syslog and
journalctl can help capture information.
$ mkdir /var/log/journal
$ chown root:systemd-journal /var/log/journal
$ chmod 2755 /var/log/journal
Then I had to increase systemd's log level to spit out everything.
In /etc/default/grub edit GRUB_CMDLINE_LINUX to add
"systemd.log_target=kmsg systemd.log_level=debug"
Don't forget to update grub!
$ grub2-mkconfig -o /boot/grub2/grub.cfg
That should kick up all of the messages from systemd on next reboot. I
can't remember if I turned the log level to debug in the
/etc/systemd/system.conf...Meh, can't hurt. :-)
For me, once I did that the actual trigger stood out. I have had a
handful of systems that trigger systemd's sleep mode. Reported every
single one of them to the systemd-devs and they insist that it's "bad
hardware" every time. Sure, that's why the hardware works perfectly for
years on non-systemd OS's. *rolls eyes*
Anyway, once you get used to debugging and disabling all of the stupid
stuff systemd does, it's not /too/ bad. Just gotta learn to get good at
learning how to debug its weirdness. :-)
~Stack~
|
|
|