Help wanted to finalise wtmpdb init integration

[Lorenzo]

Hi Andrew,

On Wed, 5 Mar 2025 09:33:26 +0000
Andrew Bower <andrew at bower.uk> wrote:

> Hi everyone,
> 
> I would appreciate some advice on getting the init integrations right
> for wtmpdb, please.
> 
> I have added and improved the support for running wtmpdb without
> systemd over the last three releases but there are still some issues
> that need ironing out as of 0.71.0+git20250228.4e4b54e-1, including:
> 
>  - dh_installinit --no-stop-on-upgrade is not effective, at least not
>    in the way I was expecting. As a result, the one-shot service gets
>    invoked on upgrade, resulting in spurious 's-reboot' entries.

the problem is that the init script should not "restart" on start
action;
this is usually done with a check on the pid with start-stop-daemon, but
wtmpdb is a oneshot so you cant do that.
Only (ugly) way that comes to my mind is to check the return code after
the call of wtmpdb start action and, if successful, touch a some file
under /run. In start action, before calling wtmpdb, you test for the
file and exit 0 if it's found..

But IMHO the script is wrong,
# Default-Start:     1 2 3 4 5
should be
# Default-Start:     S
the only requirement for this script is
# Required-Start:    $remote_fs
which, I think, are started in runlevel S too, so it should be possible
to get the boot order right..
then you could just check for runlevel in start action and exit 0
on anything that is not S.
I don't recall, what was the issue with this script started in runlevel
S?

Lorenzo

> 
>  - the script gets launched later in the boot sequence than I am
>    expected (in runlevel 2). (Perhaps that is accidentally for the
> best for users with /var on NFS.) A low priority issue.
> 
> My priority is getting the best experience for users upgrading from
> bookworm - I think that this essential consideration was not given
> enough priority when this package was introduced and the util-linux
> support for utmp-format files withdrawn.
> 
> Any help from init script experts appreciated - also any improvements
> beyond init considerations of course also welcome!
> 
> Thanks,
> 
> Andrew
>