[systemd-devel] How soon after login can I rely on systemd --user having reached sockets.target?

[Lennart Poettering]

On Thu, 23.10.14 13:47, Damien Robert (damien.olivier.robert at gmail.com) wrote:

> >From Lennart Poettering, Thu 23 Oct 2014 at 11:49:27 (+0200) :
> > On Thu, 23.10.14 08:09, Damien Robert (damien.olivier.robert+gmane at gmail.com) wrote:
> > > But isn't using default.target more flexible than basic.target? When
> > > basic.target is activated I expect at least socket.target, timers.target
> > > and path.target to get activated too; whereas I could imagine an user
> > > wanting a completly empty user session [*], which could be done with an empty
> > > default.target [#].
> 
> > basic.target includes sockets.target, busnames.target, timers.target
> > and paths.target as well as sysinit.target.
> 
> No, that's the system wide basic.target. The user basic.target only has
> sockets, timers and paths.

Oh indeed, there is not sysinit.target. It sounded so wron in a user
context... I figure if people want to stick something in there they
can just as well use basic.target here...

> But I was arguing that basic.target has a well defined meaning (basic
> system wide/user wide system initialisation), and we may want to allow
> default.target (in a user session) to be different from basic.target, even
> if they should be the same for most user cases.

sure, that sounds like something to support. i'd still say though that
pam_systemd should only wait for basic.target, since that's where all
the "listening" bits should be established, and everything else can be
started later.

> > Yes, all user code really should go through PAM, so that security
> > labels and resource limits can be set up properly.
> 
> Yeah but do they need to go through pam_systemd.so also?

Yes. All user code should go through pam_systemd.so too, so that it
gets moved into the user's slice.

Lennart

-- 
Lennart Poettering, Red Hat