<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Try to set the systemd user instance's log level to 'debug'; I'm guessing it's not that systemd kills processes directly but that something triggers a 'systemctl stop' of the session .scope that they were in.</blockquote><div><br></div><div>Here are the logs at debug level with some annotations inline:</div><div><br></div><div><b><wake up at 21:57:30></b></div><div><br></div><div>Jan 28 21:57:34 edison plasmashell[3114743]: KCrash: Application 'plasmashell' crashing...<br>Jan 28 21:57:34 edison plasmashell[3114743]: KCrash: Attempting to start /usr/libexec/drkonqi<br></div><div><br></div><div><b style=""><This is because of <a href="https://bugs.kde.org/show_bug.cgi?id=396359">https://bugs.kde.org/show_bug.cgi?id=396359</a>, could be related to subsequent events but I'm pretty sure I've seen this same problem even when Plasma doesn't crash></b></div><div><br></div><div>Jan 28 21:57:34 edison systemd[2551]: Got message type=signal sender=org.freedesktop.DBus destination=n/a path=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4294967295 reply_cookie=0 signature=sss error-name=n/a error-message=n/a<br>Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: D-Bus name org.kde.plasmashell now not owned by anyone.<br>Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Changed running -> stop-sigterm<br>Jan 28 21:57:34 edison systemd[2551]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/systemd1/unit/plasma_2dplasmashell_2eservice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=10389 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a<br>Jan 28 21:57:34 edison systemd[2551]: Sent message type=signal sender=n/a destination=n/a path=/org/freedesktop/systemd1/unit/plasma_2dplasmashell_2eservice interface=org.freedesktop.DBus.Properties member=PropertiesChanged cookie=10390 reply_cookie=0 signature=sa{sv}as error-name=n/a error-message=n/a<br>Jan 28 21:57:34 edison systemd[2551]: Received SIGCHLD from PID 3326812 (idea.sh).<br>Jan 28 21:57:34 edison systemd[2551]: Child 3326812 (idea.sh) died (code=killed, status=15/TERM)</div><div><br></div><div><b style=""><This seems to indicate that systemd is receiving notification that IDEA died. Not sure why killsnoop.py seems to think that systemd is the process that <i>sends</i> the SIGTERM -- it's still unclear to me where IDEA is receiving the SIGTERM from></b></div><div><br>Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Child 3326812 belongs to plasma-plasmashell.service.<br>Jan 28 21:57:34 edison systemd[2551]: Child 3114994 (kio_http_cache_) died (code=killed, status=15/TERM)<br>Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Child 3114994 belongs to plasma-plasmashell.service.<br>Jan 28 21:57:34 edison systemd[2551]: Child 3328167 (adb) died (code=killed, status=15/TERM)<br>Jan 28 21:57:34 edison systemd[2551]: plasma-plasmashell.service: Child 3328167 belongs to plasma-plasmashell.service.<br>Jan 28 21:57:34 edison systemd[2551]: Received SIGCHLD from PID 3328167 (n/a).<br></div><div><br></div><div><b><bunch more processes dying similarly, plasma restarting, etc.></b></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Can't think of any events directly related to monitor wakeup that systemd would react to (unless you meant the processes die on full system suspend that usually follows). Do you have any screensaver running? Do the processes actually get killed when the monitor goes to sleep or only when it wakes up?</blockquote><div><br></div>No screensaver, just the lock screen. It's a desktop -- it doesn't hibernate. The monitors just go to sleep according to the energy settings, and then they wake up when there is keyboard or mouse activity. The processes get killed only at wake-up time -- not at sleep time. It's also at wake up time, not at login time.<div><br></div><div>Just as a test I killed plasmashell to see if that would cause other processes to shut down (recognizing that a SIGTERM is not the same as a crash). It did not. All processes remained running.</div><div><br></div><div>Regards,</div><div>Raman</div><div><br></div><div><br><div><div><br></div><div><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 28, 2022 at 6:41 AM Mantas Mikulėnas <<a href="mailto:grawity@gmail.com">grawity@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Try to set the systemd user instance's log level to 'debug'; I'm guessing it's not that systemd kills processes directly but that something triggers a 'systemctl stop' of the session .scope that they were in.<div dir="auto"><br></div><div dir="auto">Can't think of any events directly related to monitor wakeup that systemd would react to (unless you meant the processes die on full system suspend that usually follows). Do you have any screensaver running? Do the processes actually get killed when the monitor goes to sleep or only when it wakes up?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 26, 2022, 15:39 Raman Gupta <<a href="mailto:rocketraman@gmail.com" target="_blank">rocketraman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Does anyone have any tips for debugging this or getting more information? Should I create an issue for this?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 23, 2022 at 3:43 PM Raman Gupta <<a href="mailto:rocketraman@gmail.com" rel="noreferrer" target="_blank">rocketraman@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote">(A variation of this message was originally sent to fedora-users)<br><br><div dir="ltr"><div><span style="white-space:pre-wrap;color:rgba(0,0,0,0.87);font-family:Roboto,Noto,sans-serif;font-size:13px">I have a couple processes that have been consistently dying every time I wake up my monitors after the system has been idle. One is Slack Desktop and the other is IntelliJ IDEA.</span></div><div><span style="white-space:pre-wrap;color:rgba(0,0,0,0.87);font-family:Roboto,Noto,sans-serif;font-size:13px"><br></span></div><div><span style="font-size:13px;white-space:pre-wrap;color:rgba(0,0,0,0.87);font-family:Roboto,Noto,sans-serif">I used an eBPF program (killsnoop.py at </span><a href="https://github.com/iovisor/bcc/blob/master/tools/killsnoop.py" style="font-size:13px;text-decoration-line:none;font-family:Roboto,Noto,sans-serif" rel="noreferrer" target="_blank">https://github.com/iovisor/bcc/blob/master/tools/killsnoop.py</a><span style="font-size:13px;white-space:pre-wrap;color:rgba(0,0,0,0.87);font-family:Roboto,Noto,sans-serif">)</span><span style="font-size:13px;white-space:pre-wrap;color:rgba(0,0,0,0.87);font-family:Roboto,Noto,sans-serif"> to trace where the signal to shut down these processes was coming from, and it appears that systemd is sending pretty much every active process signal 15 and then 18.</span><br></div><div><span style="font-size:13px;white-space:pre-wrap;color:rgba(0,0,0,0.87);font-family:Roboto,Noto,sans-serif"><br></span></div><div><span style="font-size:13px;white-space:pre-wrap;color:rgba(0,0,0,0.87);font-family:Roboto,Noto,sans-serif">TIME PID COMM SIG TPID RESULT<br></span></div><div><span style="font-size:13px;white-space:pre-wrap;color:rgba(0,0,0,0.87);font-family:Roboto,Noto,sans-serif">... on monitor wakeup ...</span></div><div><span style="font-size:13px;white-space:pre-wrap;color:rgba(0,0,0,0.87);font-family:Roboto,Noto,sans-serif">12:16:58 2551 systemd 15 2938613 0<br>12:16:58 2551 systemd 18 2938613 0<br>12:16:58 2551 systemd 15 2938814 0<br>12:16:58 2551 systemd 18 2938814 0<br>12:16:58 2551 systemd 15 2938832 0<br>12:16:58 2551 systemd 18 2938832 0<br>12:16:58 2551 systemd 15 2938978 0<br>12:16:58 2551 systemd 18 2938978 0<br>12:16:58 2551 systemd 15 2939432 0<br>12:16:58 2551 systemd 18 2939432 0<br>12:16:58 2551 systemd 15 2939899 0<br>12:16:58 2551 systemd 18 2939899 0<br>12:16:58 2551 systemd 15 2942192 0<br>12:16:58 2551 systemd 18 2942192 0<br></span></div><div><span style="font-size:13px;white-space:pre-wrap;color:rgba(0,0,0,0.87);font-family:Roboto,Noto,sans-serif">...</span></div><div><span style="font-size:13px;white-space:pre-wrap;color:rgba(0,0,0,0.87);font-family:Roboto,Noto,sans-serif"><br></span></div><div>Process 2551 is the PDF of the source of the signal according to killsnoop, 15 and 18 are the signals being sent, and TPID is the target PID, which among many others, does include my dying processes. Process 2551 is indeed systemd, specifically the user process:<br><br>raman 2551 1 0 Jan07 ? 00:00:10 /usr/lib/systemd/systemd --user<br></div><div><br></div><div>This behavior is relatively new. What is going on here? I haven't found any other reports of this behavior anywhere else.<br></div><div><br></div><div>I'm using systemd-249.9-1.fc35 on Fedora 35.</div><div><br></div><div>Regards,</div><div>Raman</div><div><br></div></div> </div></div> </blockquote></div> </blockquote></div> </blockquote></div>