On Thu, Oct 23, 2014 at 04:59:45PM +0200, Lennart Poettering wrote: > On Thu, 23.10.14 17:52, Mantas Mikulėnas (graw...@gmail.com) wrote: > > > On Oct 23, 2014 5:48 PM, "Lennart Poettering" <lenn...@poettering.net> > > wrote: > > > > > > On Thu, 23.10.14 16:06, Damien Robert (damien.olivier.rob...@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? > > order it after basic.target (which things are by default anyway)... > > My proposal now, (which is the same Damien's as I understood him): > > 1. pam_systemd should sync on default.target > 2. by default default.target should just be an alias to basic.target. > > That way we have two things: > > a) as basic.target pulls in all sockets and busnames we know that > everything that needs to be listened on is listened on by the time > PAM succeeds > > b) if people really want they can change the default.target symlink to > something else and thus add additional services into this, that may > run after the sockets/busnames, but before PAM succeeds. > > Makes sense? Not to me. It still potentially delays user login a lot, because it conflates things which should be started by default with things which should be started before login completes.
If I want to start a bunch of daemons whenever my systemd instance is running, I want to add them to default.target, that's what it is there for. I see a strong parallel with the system default.target: it specifies what should be launched on boot, but user logins are allowed much earlier. Maybe this should be made explicit and PAM should wait for a new user-login.target, which by default will simply have Wants=basic.target, but the user is free to add additional dependencies if they want to have more stuff running before they are allowed to log in. Zbyszek _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
