<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Nov 6, 2020, 23:31 Phillip Susi <<a href="mailto:phill@thesusis.net">phill@thesusis.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Lennart Poettering writes:<br>
<br>
> Are you running systemd? If so, please get rid of "killproc". It will<br>
> interfere with systemd's service management.<br>
<br>
I see.. apparently Ubuntu still has it around.  How does systemd handle<br>
it?  For instance, if a user logged in and forked off a background<br>
process, how does systemd make sure it gets killed when isolating to<br>
rescue.target?  Does it decide that it is still connected to ssh.service<br>
and so won't kill it when isolating?  I'd like to make sure anything<br>
like that is killed and maybe restart sshd if needed.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">No, user processes are moved to their own cgroup and unit (usually session-XX.scope nested under user-UID.slice) as soon as sshd calls pam_systemd during login.</div><div dir="auto"><br></div><div dir="auto">(This includes also the sshd "worker" process which handles that connection, which is the one calling PAM.)</div><div dir="auto"><br></div><div dir="auto">You can see the "contents" of sshd.service in its `systemctl status`, and you can run `systemd-cgls` to get a tree of all cgroups and which processes they contain.</div><div dir="auto"><br></div><div dir="auto">I don't exactly know in which conditions the session scopes (or the whole user slice) are stopped. But in any case, stopping a unit should kill all processes with no "leftovers".</div></div>