On Thu, Mar 3, 2011 at 6:20 PM, Lennart Poettering <lenn...@poettering.net> wrote: > On Thu, 03.03.11 09:14, Andrey Borzenkov (arvidj...@gmail.com) wrote: > >> >> On Thu, Mar 3, 2011 at 7:51 AM, Andrey Borzenkov <arvidj...@gmail.com> wrote: >> > On Thu, Mar 3, 2011 at 12:31 AM, Lennart Poettering >> > <lenn...@poettering.net> wrote: >> >> On Wed, 02.03.11 11:41, Andrey Borzenkov (arvidj...@gmail.com) wrote: >> >> >> >>> It is expected that system will put "reboot" in wtmp to mark >> >>> when it starts coming up. This is looked for by "who -b" and is >> >>> used by "last" to calculate correct time spent by various programs. >> >>> Add systemd-update-utmp-reboot.service which is started as soon >> >>> as possible after local-fs.target to mark reboot. >> >> >> >> Hmm, systemd-update-utmp-runlevel.service should normally do that >> >> implicitly. When /lib/systemd/systemd-update-utmp is called with the >> >> "runlevel" argument then it will add the "reboot" entry if necessary >> >> automatically, followed by the "runlevel" entry. >> >> >> >> Are you suggesting that this automatic logic isn't working correctly? >> >> >> > >> > On my notebook "reboot" line is never added. What is funny, it appears >> > that on my test VM which has stripped down installation "reboot" does >> > actually appear. Which suggests some race condition or uninitialized >> > variable somewhere. >> > >> >> Well, the problem is, on my notebook it *does* find previous runlevel >> entry and so never triggers on_reboot: >> >> Mar 3 09:00:47 cooker systemd-update-utmp[2481]: After utmpxname >> Mar 3 09:00:47 cooker systemd-update-utmp[2481]: Found runlevel/previouos: >> 0/0 >> Mar 3 09:00:47 cooker systemd-update-utmp[2481]: Previous runlevel: 0 >> Mar 3 09:00:47 cooker systemd-update-utmp[2481]: Current runlevel: 53 >> Mar 3 09:00:47 cooker systemd-update-utmp[2481]: After utmpxname >> Mar 3 09:00:47 cooker systemd-update-utmp[2481]: Found runlevel/previouos: >> 0/0 >> >> Because it works on stripped down installation, it appears that some >> package puts this entry there on startup. >> >> I really do not know how to find who is messing up with utmp; it may >> be anything. So it looks like one of >> >> - use explicit unit for "reboot" (and remove current magic from on_runlevel). >> >> - call on_reboot() if previous run-level found was 0. >> >> Personally I find explicit unit to be better understandable and easier >> to debug than hiding some magic inside binary that no one is aware of. > > Hmm, here's a guess: the code relies that utmp is emptied? Maybe this > doesn't happen on your system? >
Fixed in patch I am about to send. > Normally systemd-update-utmp-runlevel.service is run after > systemd-tmpfiles-setup.service, but maybe this doesn't work on your system? > it does. I still believe that "one unit - one task" is better for understanding and easier for debugging :) _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
