On Mon, Oct 12, 2020 at 8:16 PM Thomas HUMMEL <thomas.hum...@pasteur.fr> wrote:
> Thanks for your answer. Still I'm quite confused. > > On 12/10/2020 18:21, Mantas Mikulėnas wrote: > > > > It's a worker process which calls pam_open_session() and > > pam_close_session() on behalf of the user@<uid>.service unit. > > Well I may be misunderstanding but this user@<uid>.service seems like a > top level (for this user) placeholder for various other services units > and/or scope, among which the init.scope corresponding to the sd-pam and > systemd --user processes). > Yes, but it is *not* a top level for *all* of the user's processes – just for those that are managed through systemctl --user. > > So you mean that any service in this placeholder can and do use the > sd-pam helper to call pam_open_session() and pam_close_session instead > of doing it themselves, passing it the relevant PAMName ? > No, I'm talking about system (global) services. user@<uid>.service, itself, is a system service. > > > > So when you see sd-pam under user@<uid>.service, that means it's > > handling the "systemd-user" PAM service. > > I'm not sure I understood in which cases this PAM service name is used > It's used in only one case: when starting the "user@<uid>.service" unit. > > > > They're different but related. Systemd user sessions are always managed > > through PAM (the pam_systemd module), so whenever cron calls > > pam_open_session() it indirectly starts a systemd session as well. > > You mean crond running as the user who has his own crontab does call > pam_open_session() which is defined in the pam_systemd module ? > If this is correct, this has indeed nothing to do with the sd-pam > pam_open_seesion() mentionned above or does it ? > > Yes, they're completely separate PAM instances. > > > > > - what does the first error message refers to and why does the > > systemd-user pam service name get passed ? and by which systemd > (system > > or user) ? > > > > > > Your systemd --user instance is run as a service > > Yes I understood that. But again I'm not really sure what services or > other units it is supposed to run if I didn't defined user custom > Well, that doesn't mean it shouldn't be started at all – for a few reasons: 1) pam_systemd doesn't know that you don't have any custom units. 2) Even if you don't have any units in ~/.config/systemd, there might be package-installed ones in /usr/lib/systemd/user (such as gpg-agent.socket). 3) systemd --user can also be used for transient units via `systemd-run`. Though, it's true that most of those things are about interactive logins. Actually I kind of wish that pam_systemd would have an option to *only* create the user-<uid>.slice cgroup but without starting user@.service... (Arch Linux's /etc/pam.d/crond does not list pam_systemd at all, and it hasn't really created any issues so far.) > services. Is it responsible to run things like the user's UI termnials > for instance ? > Generally no. Even though your login processes belong to a "user session", they are not managed by user@<uid>.service in any way. > > > > Because of that, the service needs to have its own PAM service name and > > makes its own PAM calls independently from crond or anything else. > > Ok so it's this service (systemd --user) which uses the systemd-user PAM > service name ? Passed to the generic sd-pam worker ? Correct ? > Yes. > > > > > - what is the failing systemd job the second message refers to ? Does > > this mean that the crond "session" gets created by the systemd --user > > instance (as some gnome apps in other contexts for instance) ? > > > > > > No, it's mostly the opposite – the starting of user@<uid>.service is > > triggered by crond opening its PAM session. > > Sorry I don't get it : what service exactly is started ? crond opening > its PAM session does not cause a systemd --user to be instanciated or > It does *if* your distro's /etc/pam.d/cron[d] includes the pam_systemd module. (So on Debian it does, on Arch it doesn't.) > does it ? I thought the only way to have a systemd --user was through > the creation via pam_systemd notifying systemd-logind at a user fist > login (and/or to linger the user) > Yes but that's exactly what happens in cron as well. When crond calls PAM, it does exactly the same thing as when a user logs in interactively – it calls PAM open_session in pretty much the same way as e.g. sshd or console login would. The only difference is the PAM service name (and therefore a different /etc/pam.d config file). -- Mantas Mikulėnas
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
