On Thu, 10.03.11 13:58, Andrey Borzenkov (arvidj...@gmail.com) wrote: > > On Wed, Mar 2, 2011 at 12:35 AM, Lennart Poettering > <lenn...@poettering.net> wrote: > > On Wed, 02.03.11 00:07, Andrey Borzenkov (arvidj...@gmail.com) wrote: > > > >> Have you actually read what I wrote? > >> > >> "Now, I do not care much about rc-sysinit itself. But I do care that > >> services that we want to be started late are *really* started late." > >> > >> Currently I have impression that rc-local is used as synchronization > >> point by explicitly ordering some service after it. My point is > >> exactly that this is wrong and if these service need to be started > >> late (and I really think some of them need to be started late) some > >> other mechanism is required. > > > > Well, which services are those you believe should be started late? > > it is not so much about "being started late" as "being executed at > specific event before execution continues". > > Trivial example is fedora-sysinit-(un)hack. On initial startup it > creates /etc/.in_sysinit, which is expected to be removed after > basic.target is reached (which loosely corresponds to /etc/rc.sysinit > in the past). The problem is, we do want file to be removed after > everything that basic.target wanted has finished but before anything > ordered after basic.target is started. There is no easy way to do it > now.
It's a bad example. As the name of this units suggest, it's a hack. This should really go away. And in the meantime it might be good enough to move it between sysinit.target and basic.target. > or I was just yesterday asked how to start something "after startup is > finished". Of course you can add unit ordered After default.target ... > except that for him it was broken NFS/autofs mount and he could not > login until NFS was restarted. Again - in this case such action would > need to hook after - or rather just before - > systemd-user-sessions.service, but after everything else that is > ordered before is finished. But this is a work-around, not a fix... (not sure I follow the problem entirely though). All use cases I see for this are to make hacks and work-arounds work. But that doesn't make it particularly attractive to me to add broken hooks for this... > > getty? prefdm? I think it is sufficient to order them against rc-local, > > since neither service actually needs to be started that late really. I > > see no problem with allowing early logins. > > Well, I just found that if completion of default.target job is delayed > (because some service takes too much time e.g.) logins done before > systemd-update-utmp-runlevel has been executed are not entered in wmp. > Apparently system never expected that login was possible before > run-level had been reached. Hmm, interesting. Can you elaborate on that? I don't see why any login process should care about the runlevel. Which client is this? > > In fact I think it is a feature even. > > Even if it is, the above is indication that it may be unexpected and > break things in subtle ways. Well as I see this we should figure out what is going on with this login process before we come to conclusions... ;-) Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
