[systemd-devel] [PATCH] correctly mark system reboot

[Lennart Poettering]

On Thu, 03.03.11 09:14, Andrey Borzenkov (arvidjaar at gmail.com) wrote:

> 
> On Thu, Mar 3, 2011 at 7:51 AM, Andrey Borzenkov <arvidjaar at gmail.com> wrote:
> > On Thu, Mar 3, 2011 at 12:31 AM, Lennart Poettering
> > <lennart at poettering.net> wrote:
> >> On Wed, 02.03.11 11:41, Andrey Borzenkov (arvidjaar at 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.