Sporadically, my session will crash after resuming from suspend. According to journalctl, first systemd-logind crashes
systemd-logind.service: Main process exited, code=dumped, status=6/ABRT
then, when opening a new session, X fails to start which causes sddm to crash
systemd-logind[17674]: New session 3 of user yann.
sddm[1250]: Adding new display on vt 1 ...
sddm[1250]: Loading theme configuration from ""
sddm[1250]: Display server starting...
sddm[1250]: Running: /usr/bin/X -nolisten tcp -auth /var/run/sddm/{76c955c5-7732-4e88-8e7f-13344b89817b} -background none -noreset -displayfd 19 -seat seat0 vt1
sddm[1250]: Display server failed to start. Exiting
systemd[1]: sddm.service: Main process exited, code=dumped, status=6/ABRT
org.kde.KScreen[1442]: The X11 connection broke (error 1). Did the X11 server die?
org.kde.kglobalaccel[1442]: The X11 connection broke (error 1). Did the X11 server die?
Then, X failsafe troubleshooting mode is activated
During resume, your time is fluctuating, jumping back and forth. When going back in time, logind gets killed by watchdog. Might be connected with your RTC. Don’t know how to fix that, though.
Thanks a lot for your insight. I was assuming that these discrepancies were happening because events were not flushed in order. It seems that this is related to known problems with systemd services and is related to a kernel bug where the monotonic clock is not behaving as documented (ie. “moving” during suspend when it should not).
Following this comment from a systemd dev, I could confirm that my kernel (4.17.0-996-generic) does exhibit this anomalous behaviour, using the following Python script