Help wanted to finalise wtmpdb init integration

[Andrew Bower]

Hi Mark and Lorenzo

Sorry, I'm back for more!

The current solution works fine but it does mean anyone who installed
the original iteration will have the wrong runlevel symlinks for the
integration to be effective and they will not get boot times recorded.

On Wed, Mar 05, 2025 at 05:35:17PM +0000, Andrew Bower wrote:
> Lorenzo was right about the runlevels to use, and because we are
> supplied with the current and previous runlevel when invoked by init, we
> can perform single shot services quite easily without (ironically)
> parsing utmp or handling guard files. Perhaps this shouldn't be a
> surprise as this isn't exactly the first ever one-shot init script!

There would not be an issue if I had gone with Mark's one-shot guard
file solution. However, I do like what I went with below because it (a)
leaves a smaller footprint on the system and (b) seems idiomatic: it is
the same approach used by, e.g.:

/etc/init.d/brltty:	if [ "$RUNLEVEL" = "S" -a "$PREVLEVEL" = "N" ]; then
/etc/init.d/eudev:  if [ "$RUNLEVEL" = "S" -a "$PREVLEVEL" = "N" ]; then
/etc/init.d/udev:  if [ "$RUNLEVEL" = "S" -a "$PREVLEVEL" = "N" ]; then

and I believe I've seen it in other scripts on another host (this one is
runit-init so may have fewer examples present).

> @@ -17,7 +19,7 @@ fi
>  # Required-Stop:     $remote_fs
>  # Should-Start:
>  # Should-Stop:
> -# Default-Start:     1 2 3 4 5
> +# Default-Start:     S
>  # Default-Stop:      0 6
>  # Short-Description: Write boot and shutdown times into wtmpdb
>  # Description:       Invokes wtmpdb to write boot and shutdown times
> @@ -29,9 +31,15 @@ DAEMON="none"
>  NAME="wtmpdb-update-boot"
>  
>  do_start_cmd_override() {
> -  /usr/bin/wtmpdb boot
> +  if [ "$RUNLEVEL" = "S" ] && [ "$PREVLEVEL" = "N" ]
> +  then
> +    /usr/bin/wtmpdb boot
> +  fi
>  }

For anyone with the original defaults, i.e.

# insserv -s | grep wtmp
K:01:0 6:wtmpdb-update-boot
S:02:1 2 3 4 5:wtmpdb-update-boot

the above edge detection will never succeed.

This is not fixed on upgrade:

# update-rc.d -f wtmpdb-update-boot defaults
insserv: warning: current start runlevel(s) (1 2 3 4 5) of script `wtmpdb-update-boot' overrides LSB defaults (S).

So my questions are:

1) is this important enough to fix - may affect anyone using sysvinit
from unstable/testing for the life of their installation. But the system
is doing what is intended: it warns the users and they can react
accordingly. To be nice to such users should we detect upgrade from any
affected version up to the one before where this detection occurs and
then forcibly reset the runlevels to default?

2) if we do this, should we also check that the current runlevels match
the previous defaults to check we aren't overriding user changes or is
that a bit excessive right now when none of this has hit stable and
there isn't actually a nice command we can rely on to check this and
already be guranteed to be installed?

3) if we do this, how should we effect the override? The only reliable
way I know of, short of using commands that might not be installed
(insserv) or perilously rolling our own, is relying on bug #680293,
running update-rc.d remove and then update-rc.d defaults.

I think the practical options are:

A: do nothing (not a bad one)

B: switch to Marks' one-shot method (I don't really want to switch the
whole method to overcome a transitionary glitch.)

C: forcibly switch to defaults if upgrading from a version >= 0.13.0-6
and << one where this transitionary fix appears.

Maybe this is a fuss over nothing in which case (A) is the default
behaviour purely by inaction!

Thanks,

Andrew

>  do_stop_cmd_override() {
> -  /usr/bin/wtmpdb shutdown
> +  if [ "$RUNLEVEL" = "0" ] || [ "$RUNLEVEL" = "6" ]
> +  then
> +    /usr/bin/wtmpdb shutdown
> +  fi
>  }
> -- 
> 2.47.2
>