Hello,
thanks for your answer. It's getting clearer.
Still : why would the user crond runs on behalf of needs to be allowed
in access.conf to access the systemd-user service ?
My understanding is that the user@<uid>.service creation needs this
service type (or just the systemd --user creation ?) such a rule in
access.conf is not needed for let's say a ssh login first session ?
Thanks for your help
--
Thomas HUMMEL
On 13/10/2020 20:05, Simon McVittie wrote:
On Tue, 13 Oct 2020 at 13:09:43 +0200, Thomas HUMMEL wrote:
Ok, so for instance, on my debian, when I see:
user@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
_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
