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

Mantas Mikulėnas grawity at gmail.com
Thu Oct 23 07:52:16 PDT 2014


On Oct 23, 2014 5:48 PM, "Lennart Poettering" <lennart at poettering.net>
wrote:
>
> On Thu, 23.10.14 16:06, Damien Robert (damien.olivier.robert at gmail.com)
wrote:
>
> > >From Lennart Poettering, Thu 23 Oct 2014 at 14:01:22 (+0200) :
> > > 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 but maybe the user wants something even more minimal than
basic.target.
> > For instance if I run under a cron, maybe I don't want my timers to be
> > launched. I was thinking of using a default.target with
> > DefaultDependencies=false, so it does not even pull basic.target; not
> > something that launch more things than basic.target.
>
> Hmm, maybe you do have a point here and default.target should be what
> we sync on after all. It would by default point to basic.target, but
> if people really want to redfine things they could do so.

But wouldn't that also redefine the services one wants to start
automatically? How would one choose the unit to start separately from the
unit to sync to?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20141023/a3a0f88d/attachment.html>


More information about the systemd-devel mailing list