[systemd-devel] Crond session, pam_access and pam_systemd

[Simon McVittie]

On Tue, 13 Oct 2020 at 13:09:43 +0200, Thomas HUMMEL wrote:
> Ok, so for instance, on my debian, when I see:
> 
> > user at 1000.service
> │   │ ├─gvfs-goa-volume-monitor.service
> │   │ │ └─1480 /usr/lib/gvfs/gvfs-goa-volume-monitor
> │   │ ├─gvfs-daemon.service
> │   │ │ ├─1323 /usr/lib/gvfs/gvfsd
> │   │ │ ├─1328 /usr/lib/gvfs/gvfsd-fuse /run/user/1000/gvfs -f -o big_writes
> │   │ │ └─1488 /usr/lib/gvfs/gvfsd-trash --spawner :1.19
> /org/gtk/gvfs/exec_spaw
> │   │ ├─gvfs-udisks2-volume-monitor.service
> │   │ │ └─1453 /usr/lib/gvfs/gvfs-udisks2-volume-monitor
> │   │ ├─xfce4-notifyd.service
> │   │ │ └─1355 /usr/lib/x86_64-linux-gnu/xfce4/notifyd/xfce4-notifyd
> 
> those services jobs are started by the systemd --user in this user init
> scope, correct  ?

Yes. In many cases they're started on-demand (for example because
something talks to them over D-Bus) rather than being started "eagerly".

> My understanding now after your explanation is that crond, in the case of a
> user crontab and pam_systemd in the crond stack, will create a session and
> thus instanciate a systemd --user if not already present (like in the
> lingered case)

Yes. If uid 1000 is already logged in or is flagged for lingering,
and a cron job for uid 1000 starts, the cron job will reuse their
pre-existing systemd --user. If uid 1000 does not already have a
systemd --user, crond's PAM stack will result in a systemd --user being
started before the cron job, and stopped after the cron job.

> Do you confirm that, in the case of crond this systemd --user is useless ?

It might be useful, it might be useless. It depends what's in your
cron jobs.

For example, if you have a cron job that uses GLib to act on SMB shares or
trashed files or anything like that, then it will need gvfs-daemon.service
(just like the fragment of a process tree you quoted above) to be able
to access smb:// or trash:// locations.

    smcv