SCIENTIFIC-LINUX-USERS Archives

March 2017

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"~Stack~" <[log in to unmask]>
Reply To:
~Stack~
Date:
Thu, 9 Mar 2017 18:44:24 -0600
Content-Type:
multipart/signed
Parts/Attachments:
text/plain (2491 bytes) , signature.asc (834 bytes)
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~






ATOM RSS1 RSS2