<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jul 14, 2016 at 8:17 PM, Harald Sitter <span dir="ltr"><<a href="mailto:sitter@kde.org" target="_blank">sitter@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Thu, Jul 14, 2016 at 8:06 PM, Andreas Hartmetz <<a href="mailto:ahartmetz@gmail.com">ahartmetz@gmail.com</a>> wrote:<br>
> On Donnerstag, 14. Juli 2016 16:19:15 CEST Harald Sitter wrote:<br>
>> On Thu, Jul 14, 2016 at 3:43 PM, Andreas Hartmetz<br>
> <<a href="mailto:ahartmetz@gmail.com">ahartmetz@gmail.com</a>> wrote:<br>
>> > Hello,<br>
>> ><br>
>> > Am Donnerstag, 14. Juli 2016, 11:11:26 CEST schrieb Harald Sitter:<br>
>> >> Hola!<br>
>> >><br>
>> >> ever since systemd and or sddm started not killing all our session<br>
>> >> processes we have had problems of poweroff/reboot getting hung up<br>
>> >> waiting for processes to quit.<br>
>> >> Recently systemd then started sending them TERM by default, which<br>
>> >> in<br>
>> >> theory should make things behave as before, but more often than not<br>
>> >> it doesn't.<br>
>> >><br>
>> >> The reason for this is meh to debug and altogether somewhat<br>
>> >> convoluted. So all that follows was partially inferred from<br>
>> >> numerous<br>
>> >> logging attempts.<br>
>> >> They all root in a simple fact: ksmserver is rubbish at its job and<br>
>> >> only terminates half the stuff in the session before handing over<br>
>> >> to<br>
>> >> the outside expecting the outside to deal with it.<br>
>> >><br>
>> >> I found two likely holdup scenarios caused by this:<br>
>> >><br>
>> >> a) procfoo is still running -> ksmserver hands over to systemd -><br>
>> >> systemd stops sddm -> xserver stops -> procfoo now crashes because<br>
>> >> it<br>
>> >> does x-things (pretty sure [1] is an instance of this) -> kcrash<br>
>> >> jumps in -> drkonqi -> gdb -> procfoo wont react to anything but<br>
>> >> KILL now><br>
>> > Hah, that's a nice one. It should indeed be fixed in kcrash.<br>
>> ><br>
>> >> b) procfoo is still running -> ksmserver hands over to systemd -><br>
>> >> procfoo survives without X (e.g. kio slave) -> procfoo crashes for<br>
>> >> (maybe unreleated) reasons such as qt bug because network is down<br>
>> >> -><br>
>> >> kcrash gets hung up on recursion crashes handling for kdeinit5 or<br>
>> >> some other nonesense<br>
>> ><br>
>> > It is not even clear that surviving processes need to be killed in<br>
>> > case of logout, which one also needs to consider. See below.<br>
>> ><br>
>> >> Long story short: if things crash, usually the TERM from systemd<br>
>> >> won't do anything.<br>
>> >><br>
>> >> The way I see it ksmserver needs to properly TERM everything to<br>
>> >> protect against a). Kcrash additionally ought to not do anything<br>
>> >> when<br>
>> >> its session is in shutdown to guard against both a) and b) AND<br>
>> >> allow<br>
>> >> core dumps to be collected instead so there actually can be a trace<br>
>> >> of something having gone wong.<br>
>> ><br>
>> > It is not really ksmserver's job to SIGTERM or even SIGKILL<br>
>> > applications. It implements XSMP which involves asking application<br>
>> > nicely to die. If they didn't, they were killed just fine until<br>
>> > systemd "improved" things.<br>
>> > Not everything participates in XSMP so ksmserver doesn't see all<br>
>> > processes in any case.<br>
>> > What systemd ought to do is:<br>
>> > - when shutting down, kill everything after a short timeout<br>
>> > - when logging out, don't kill anything (think of screen sessions<br>
>> > and<br>
>> ><br>
>> > such)<br>
>> ><br>
>> > This is a systemd problem. Before systemd it worked as described<br>
>> > above and it was good.<br>
>> ><br>
>> >> Thoughts?<br>
>> >><br>
>> >> I have no clue how we'd implement kcrash changes since that would<br>
>> >> have to somehow know if the session is active without doing<br>
>> >> business on the heap. For ksmserver we could probably lean on<br>
>> >> systemd to give a proc list of the session.<br>
>> ><br>
>> > So that would mean adding code on our side and integrating deeper<br>
>> > with systemd to unbreak systemd behavior. I think systemd should do<br>
>> > its job properly and get out of the way.<br>
>><br>
>> so no useful input then. ok.<br>
><br>
> The hell are you talking about? The action items are:<br>
> - Disable kcrash during logout<br>
> - File upstream bug in systemd to stop with its ill-advised behavior<br>
><br>
</div></div> whats the bug?<br>
</blockquote></div><br></div><div class="gmail_extra">Hi,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Thought i might add this small bit of info from the systemd 231 release notes [1]:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra"> * systemd will now log about all service processes it kills forcibly</div><div class="gmail_extra"> (using SIGKILL) because they remained after the clean shutdown phase</div><div class="gmail_extra"> of the service completed. This should help identifying services that</div><div class="gmail_extra"> shut down uncleanly. Moreover if KillUserProcesses= is enabled in</div><div class="gmail_extra"> systemd-logind's configuration a similar log message is generated for</div><div class="gmail_extra"> processes killed at the end of each session due to this setting.</div><div><br></div><div>It might help in figuring out some of this.</div><div><br></div><div>[1] <a href="https://lists.freedesktop.org/archives/systemd-devel/2016-July/037220.html">https://lists.freedesktop.org/archives/systemd-devel/2016-July/037220.html</a></div></div></div>