Control: tags -1 + moreinfo Am 13.05.2017 um 16:48 schrieb Mike Edwards: > Package: systemd > Version: 232-23 > Severity: critical > Justification: causes serious data loss > > * Note that this report applies to 232-22 - I just did an apt upgrade > immediately before filing this bug report. > > > This is the second time in as many days that this system has hung (console > unresponsive, > unreachable on network, VMs it hosts with Xen dead). Unfortunately, the > first time > this occurred, logs weren't synced to disk at the time of the crash, so I had > nothing > to go on. This time around, I was able to have an external host capture log > entries, > of which there are two: > > May 13 04:04:05 balrog0 systemd[1]: systemd-logind.service: Watchdog timeout > (limit 3min)! > May 13 04:04:05 balrog0 systemd[1]: systemd-logind.service: Killing process > 1270 (systemd-logind) with signal SIGABRT.
But this is systemd-logind, not systemd, which doesn't respond. And apparently systemd is still active, otherwise it couldn't kill the non-responsing systemd-logind process. Where exactly does systemd crash? Where is the data loss? Please provide more details. If you can't access the system via network, it sounds more like a kernel problem, maybe hardware or Xrelated. If systemd/PID 1 crashes, it would only freeze itself, but the system would still be running and accessible via the network. So my guess is, that the problem you see is not related to systemd at all. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth?
signature.asc
Description: OpenPGP digital signature
