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. 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. > 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. > 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. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel