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

[Andrey Borzenkov]

On Thu, Mar 3, 2011 at 6:20 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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?
>

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 :)