[systemd-devel] umount NFS problem

[Mantas Mikulėnas]

On Fri, Apr 5, 2019 at 12:53 PM Harald Dunkel <harald.dunkel at aixigo.de>
wrote:

> Hi Lennart,
>
> On 4/5/19 10:28 AM, Lennart Poettering wrote:
> >
> > For some reason a number of X session processes stick around to the
> > very end and thus keep your /home busy.
> >
> > [82021.052357] systemd-shutdown[1]: Sending SIGKILL to remaining
> processes...
> > [82021.101976] systemd-shutdown[1]: Sending SIGKILL to PID 2513
> (gpg-agent).
> > [82021.130507] systemd-shutdown[1]: Sending SIGKILL to PID 2886
> (xstartup).
> > [82021.158510] systemd-shutdown[1]: Sending SIGKILL to PID 2896
> (xstartup).
> > [82021.186052] systemd-shutdown[1]: Sending SIGKILL to PID 2959 (xterm).
> > [82021.213129] systemd-shutdown[1]: Sending SIGKILL to PID 2960 (xterm).
> > [82021.239971] systemd-shutdown[1]: Sending SIGKILL to PID 2961 (xterm).
> > [82021.266285] systemd-shutdown[1]: Sending SIGKILL to PID 2966 (bash).
> > [82021.292234] systemd-shutdown[1]: Sending SIGKILL to PID 2967 (bash).
> > [82021.318061] systemd-shutdown[1]: Sending SIGKILL to PID 9146
> (utempter).
> > [82021.343331] systemd-shutdown[1]: Sending SIGKILL to PID 9147
> (utempter).
> >
> > The question is how though. How do you start your X session? gdm?
> > startx from the console?
> >
>
> This is a VNC session, started via crontab @reboot.
>

Well that's a pretty significant omission... If (which I'm guessing is the
case) the processes are started without going through regular PAM modules
like a user login would, then they won't be tracked *as* a user session –
they just remain as part of the 'cron' service, and systemd has no
knowledge about them needing to be killed before stopping NFS. This is the
problem if you see all the X11 processes in `systemctl status cron` but no
session entry in `loginctl`.

(While cron has its own PAM stack, due to being a non-interactive tool it
uses a different module configuration – IIRC it's also special-cased in
pam_systemd, but some distros don't even include pam_systemd in its config
to avoid other issues.)

So if your VNC server doesn't call pam_open_session() on startup, you
should write a wrapper that does; similar to how existing display managers
xdm/gdm/sddm work. (It doesn't need to call any of the auth/account
functions from PAM.)

Alternatively you could convert this into a system service that has User=
and PAMName= settings; I've seen people do that to automatically start Xorg
sessions and it should work all the same with VNC. (Generally, what's the
point of using @reboot if you can write a .service?)

You can also order the entire cron.service after remote-fs.target in order
to at least avoid the race.

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20190405/e5c68231/attachment-0001.html>