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? Normally systemd-update-utmp-runlevel.service is run after systemd-tmpfiles-setup.service, but maybe this doesn't work on your system? Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
