Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1231277 > unrolled thread

Bug#1094921: sysvinit-core: does not write entries to wtmpdb

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1094921: sysvinit-core: does not write entries to wtmpdb Andrew Bower <andrew@bower.uk> - 2025-02-01 14:40 +0100
    Bug#1094921: sysvinit-core: does not write entries to wtmpdb Chris Hofstaedtler <zeha@debian.org> - 2025-02-01 18:00 +0100
      Bug#1094921: sysvinit-core: does not write entries to wtmpdb Mark Hindley <mark@hindley.org.uk> - 2025-02-01 21:30 +0100
        Bug#1094921: sysvinit-core: does not write entries to wtmpdb Mark Hindley <mark@hindley.org.uk> - 2025-02-01 21:40 +0100
          Bug#1094921: sysvinit-core: does not write entries to wtmpdb Andrew Bower <andrew@bower.uk> - 2025-02-01 21:50 +0100
          Bug#1094921: sysvinit-core: does not write entries to wtmpdb Andrew Bower <andrew@bower.uk> - 2025-02-02 17:30 +0100
            Bug#1094921: sysvinit-core: does not write entries to wtmpdb Andrew Bower <andrew@bower.uk> - 2025-02-02 20:30 +0100
              Bug#1094921: sysvinit-core: does not write entries to wtmpdb Lorenzo <plorenzo@disroot.org> - 2025-02-02 20:50 +0100
                Bug#1094921: sysvinit-core: does not write entries to wtmpdb Andrew Bower <andrew@bower.uk> - 2025-02-02 22:10 +0100
                  Bug#1094921: sysvinit-core: does not write entries to wtmpdb Lorenzo <plorenzo@disroot.org> - 2025-02-02 23:10 +0100
                    Bug#1094921: sysvinit-core: does not write entries to wtmpdb Andrew Bower <andrew@bower.uk> - 2025-02-02 23:30 +0100
                      Bug#1094921: sysvinit-core: does not write entries to wtmpdb Lorenzo <plorenzo@disroot.org> - 2025-02-03 00:00 +0100
                        Bug#1094921: sysvinit-core: does not write entries to wtmpdb Andrew Bower <andrew@bower.uk> - 2025-02-08 00:40 +0100
                          Bug#1094921: sysvinit-core: does not write entries to wtmpdb Lorenzo <plorenzo@disroot.org> - 2025-02-08 01:40 +0100
            Bug#1094921: sysvinit-core: does not write entries to wtmpdb Mark Hindley <mark@hindley.org.uk> - 2025-02-03 10:10 +0100
              Bug#1094921: sysvinit-core: does not write entries to wtmpdb Andrew Bower <andrew@bower.uk> - 2025-02-03 10:30 +0100
        Bug#1094921: sysvinit-core: does not write entries to wtmpdb Andrew Bower <andrew@bower.uk> - 2025-02-01 23:20 +0100
        Bug#1094921: sysvinit-core: does not write entries to wtmpdb Chris Hofstaedtler <zeha@debian.org> - 2025-02-02 02:30 +0100
          Bug#1094921: sysvinit-core: does not write entries to wtmpdb Mark Hindley <mark@hindley.org.uk> - 2025-02-03 10:10 +0100

#1231277 — Bug#1094921: sysvinit-core: does not write entries to wtmpdb

Package: sysvinit-core
Version: 3.13-1
Severity: normal

sysvinit-core does not write entries to the new wtmpdb.

I fully understand how deeply unattractive the idea would be of any of
the following approaches to doing this:

 - linking with libwtmpdb
 - spawning wtmpdb
 - doing anything more direct with the wtmpdb sqlite database

But the user experience is obviously not going to be ideal as things
stand. I don't think there's even a decoder tool left in the archive
although old ones still work of course.

runit manages this by spawning wtmpdb asymmetrically: on boot through
stage 1 scripts and on shutdown in the shutdown command.

So I thought it would be best to have a bug to stash considerations
around this from a sysvinit-centric perspective. I did a while back
browse the old threads where wtmpdb was introduced but I can't remember
any input from non-systemd users and rather than go back to the thread I
think we should focus on what we can do from where we are now.

Any thoughts on:

 - install an initscript with wtmpdb that imports the missing real wtmp
   entries into wtmpdb at boot.
 - install an initscript with wtmpdb independently to record startup and
   shutdown, but less reliably than init itself would.
 - reinstate a classic wtmp toolset and compat for wtmpdb?

Thanks,

Andrew

[toc] | [next] | [standalone]

#1231305

On Sat, Feb 01, 2025 at 01:27:15PM +0000, Andrew Bower wrote:
> Any thoughts on:
> 
>  - install an initscript with wtmpdb that imports the missing real wtmp
>    entries into wtmpdb at boot.
>  - install an initscript with wtmpdb independently to record startup and
>    shutdown, but less reliably than init itself would.

Shipping initscripts is IMO the right answer. If they should be in
orphan-sysvinit-scripts or elsewhere, no idea.

I'd avoid linking against libwtmpdb.

>  - reinstate a classic wtmp toolset and compat for wtmpdb?

That doesn't seem like a forward-looking strategy to me.

Best,
Chris

[toc] | [prev] | [next] | [standalone]

#1231330

Andrew,

I suppose adding something in initscripts might be possible.

Chris,

Thanks for your input as well.

I notice that wtmpdb is orphaned[1] and you have preemptively declined to comment
on the reason, which I respect. Is it reasonable to infer the wtmpdb is not
going to have longevity as a solution here?

Mark

[1]  https://bugs.debian.org/1092022

[toc] | [prev] | [next] | [standalone]

#1231332

On Sat, Feb 01, 2025 at 08:23:51PM +0000, Mark Hindley wrote:
> Andrew,
> 
> I suppose adding something in initscripts might be possible.

Actually, is there a reason why this or something similar should be included in
wtmpdb itself?

Mark

#! /bin/sh
# Generated by /home/mark/src/debian/unit-translator/utrans from:
#  6e6aacdeddf878a01b260abbda787373e176cce440d786d535d6cf7a465c25cd  ./tmp.iH71YBzenr/usr/lib/systemd/system/wtmpdb-update-boot.service

# kFreeBSD does not accept scripts as interpreters, using #!/bin/sh and sourcing.
if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
   set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi
### BEGIN INIT INFO
# Provides: wtmpdb-update-boot
# Required-Start: $remote_fs
# Required-Stop: $remote_fs
# Should-Start: dbus systemd-remount-fs systemd-tmpfiles-setup
# Should-Stop: dbus systemd-remount-fs systemd-tmpfiles-setup
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Description: Write boot and shutdown times into wtmpdb
### END INIT INFO
DESC="Write boot and shutdown times into wtmpdb"
DAEMON="none"
NAME="wtmpdb-update-boot"
do_start_cmd_override() {
  /usr/bin/wtmpdb boot
}
do_stop_cmd_override() {
  /usr/bin/wtmpdb shutdown
}

[toc] | [prev] | [next] | [standalone]

#1231334

Hi Mark,

On Sat, Feb 01, 2025 at 08:32:28PM +0000, Mark Hindley wrote:
> On Sat, Feb 01, 2025 at 08:23:51PM +0000, Mark Hindley wrote:
> > Andrew,
> > 
> > I suppose adding something in initscripts might be possible.
> 
> Actually, is there a reason why this or something similar should be included in
> wtmpdb itself?

I suspect that would be the sensible thing to do. It scales across
potential alternative providers of login database (or none). Puts
everything where the requirements are defined and can be updated in
tandem with the unit. A neat solution!

Thanks.

[toc] | [prev] | [next] | [standalone]

#1231440

Mark,

On Sat, Feb 01, 2025 at 08:32:28PM +0000, Mark Hindley wrote:
> On Sat, Feb 01, 2025 at 08:23:51PM +0000, Mark Hindley wrote:
> > Andrew,
> > 
> > I suppose adding something in initscripts might be possible.
> 
> Actually, is there a reason why this or something similar should be included in
> wtmpdb itself?

Your initscript works nicely, thanks! Validation for your translator?

Any reason to think anything is missing? I haven't written these sort of
non-daemon initscripts myself.

With commit 32a4d9da9cbeb846c1a6f380fec736eb0b51ab61:

https://salsa.debian.org/abower/wtmpdb/-/commits/sysvinit-booting

  $ last -10
  andy     tty7         :0               Sun Feb  2 15:21 - still logged in
  lightdm  tty7         :0               Sun Feb  2 15:20 - 15:21  (00:00)
  reboot   system boot  6.12.10-amd64    Sun Feb  2 15:20 - still running
  andy     tty7         :0               Sun Feb  2 15:19 - 15:19  (00:00)
  lightdm  tty7         :0               Sun Feb  2 15:19 - 15:19  (00:00)
  reboot   system boot  6.12.10-amd64    Sun Feb  2 15:18 - 15:19  (00:00)
  s-reboot system boot  6.12.10-amd64    Sun Feb  2 15:17 - 15:18  (00:00)
  andy     pts/13                        Sun Feb  2 14:00 - 14:00  (00:00)
  root     pts/13                        Sun Feb  2 14:00 - 14:00  (00:00)
  nobody                                 Sun Feb  2 07:48 - 07:48  (00:00)

  /var/lib/wtmpdb/wtmp.db begins Sun Feb  2 07:48:24 2025

Shall we go with this?

Thank you both for your suggestions for this bug,

Andrew

[toc] | [prev] | [next] | [standalone]

#1231466

Mark,

On Sun, Feb 02, 2025 at 04:16:29PM +0000, Andrew Bower wrote:
> On Sat, Feb 01, 2025 at 08:32:28PM +0000, Mark Hindley wrote:
> > On Sat, Feb 01, 2025 at 08:23:51PM +0000, Mark Hindley wrote:
> > > Andrew,
> > > 
> > > I suppose adding something in initscripts might be possible.
> > 
> > Actually, is there a reason why this or something similar should be included in
> > wtmpdb itself?
> 
> Your initscript works nicely, thanks! Validation for your translator?

Actually, I see no reason to rely on most of these dependencies or wait
until runlevel 2.

The dbus dependency is only for systemd to tell us about a "soft
reboot", which is obviously not a thing in this case.

How about this change? Seems to work ok.

diff --git a/debian/wtmpdb.wtmpdb-update-boot.init b/debian/wtmpdb.wtmpdb-update-boot.init
index d9213fc..4022d0f 100644
--- a/debian/wtmpdb.wtmpdb-update-boot.init
+++ b/debian/wtmpdb.wtmpdb-update-boot.init
@@ -15,10 +15,10 @@ fi
 # Provides:          wtmpdb-update-boot
 # Required-Start:    $remote_fs
 # Required-Stop:     $remote_fs
-# Should-Start:      dbus systemd-remount-fs systemd-tmpfiles-setup
-# Should-Stop:       dbus systemd-remount-fs systemd-tmpfiles-setup
-# Default-Start:     2 3 4 5
-# Default-Stop:      0 1 6
+# Should-Start:
+# Should-Stop:
+# Default-Start:     1 2 3 4 5
+# Default-Stop:      0 6
 # Short-Description: Write boot and shutdown times into wtmpdb
 # Description:       Invokes wtmpdb to write boot and shutdown times
 #                    into the wtmpdb login database.

[toc] | [prev] | [next] | [standalone]

#1231470

Hi all,

On Sun, 2 Feb 2025 19:24:45 +0000
Andrew Bower <andrew@bower.uk> wrote:

> 
> Actually, I see no reason to rely on most of these dependencies or
> wait until runlevel 2.
> 
> The dbus dependency is only for systemd to tell us about a "soft
> reboot", which is obviously not a thing in this case.

+ 1

> 
> How about this change? Seems to work ok.
> 
> diff --git a/debian/wtmpdb.wtmpdb-update-boot.init
> b/debian/wtmpdb.wtmpdb-update-boot.init index d9213fc..4022d0f 100644
> --- a/debian/wtmpdb.wtmpdb-update-boot.init
> +++ b/debian/wtmpdb.wtmpdb-update-boot.init
> @@ -15,10 +15,10 @@ fi
>  # Provides:          wtmpdb-update-boot
>  # Required-Start:    $remote_fs
>  # Required-Stop:     $remote_fs
> -# Should-Start:      dbus systemd-remount-fs systemd-tmpfiles-setup
> -# Should-Stop:       dbus systemd-remount-fs systemd-tmpfiles-setup
> -# Default-Start:     2 3 4 5
> -# Default-Stop:      0 1 6
> +# Should-Start:
> +# Should-Stop:
> +# Default-Start:     1 2 3 4 5

if $remote_fs insserv facility is mountnfs initscript, then
Default-start can be runlevel S (it make sense to write the boot
wtmp entry during boot runlevel, right?)

Cheers,
Lorenzo

> +# Default-Stop:      0 6
>  # Short-Description: Write boot and shutdown times into wtmpdb
>  # Description:       Invokes wtmpdb to write boot and shutdown times
>  #                    into the wtmpdb login database.
> 

[toc] | [prev] | [next] | [standalone]

#1231476

On Sun, Feb 02, 2025 at 08:45:25PM +0100, Lorenzo wrote:
> On Sun, 2 Feb 2025 19:24:45 +0000
> Andrew Bower <andrew@bower.uk> wrote:
> > diff --git a/debian/wtmpdb.wtmpdb-update-boot.init
> > b/debian/wtmpdb.wtmpdb-update-boot.init index d9213fc..4022d0f 100644
> > --- a/debian/wtmpdb.wtmpdb-update-boot.init
> > +++ b/debian/wtmpdb.wtmpdb-update-boot.init
> > @@ -15,10 +15,10 @@ fi
> >  # Provides:          wtmpdb-update-boot
> >  # Required-Start:    $remote_fs
> >  # Required-Stop:     $remote_fs
> > -# Should-Start:      dbus systemd-remount-fs systemd-tmpfiles-setup
> > -# Should-Stop:       dbus systemd-remount-fs systemd-tmpfiles-setup
> > -# Default-Start:     2 3 4 5
> > -# Default-Stop:      0 1 6
> > +# Should-Start:
> > +# Should-Stop:
> > +# Default-Start:     1 2 3 4 5
> 
> if $remote_fs insserv facility is mountnfs initscript, then
> Default-start can be runlevel S (it make sense to write the boot
> wtmp entry during boot runlevel, right?)

Thanks Lorenzo!

This is what I thought but it still doesn't get done in single user mode
until continuing boot. But I get a backtrace from plymouth in that case
anyway so that could be confounding the test. I'm planning to raise a
bug on plymouth and then de-install it then I can try again.

When this is done do you have an obvious method to mask out the
initscript for runit users?

Cheers,

Andrew

[toc] | [prev] | [next] | [standalone]

#1231484

On Sun, 2 Feb 2025 21:00:41 +0000
Andrew Bower <andrew@bower.uk> wrote:

> 
> When this is done do you have an obvious method to mask out the
> initscript for runit users?

not really, there is no runit service for this, and since it's a
oneshot there's not going to be one to mask the sysv script.
For the boot entry I can just remove the wtmpdb call in stage 1; for the
shutdown entry in runit, is implemented as "halt -w[1]" in shutdown.c
that is called by umountnfs.sh in runlevel 0 or 6, and it's not obvious
to me how to prevent a double shutdown entry here.
maybe the sysv script can be a no-op when runit is init?

[ -f  /run/runit.stopit ] && exit 0

better ideas are welcome; when I added the code to runit I didn't think
a sysv script was going to be accepted in the wtmpdb package.

[1] by the way, what's the plan for 'halt -w' in SysV 's shutdown
implementation?

Lorenzo

> 
> Cheers,
> 
> Andrew

[toc] | [prev] | [next] | [standalone]

#1231487

On Sun, Feb 02, 2025 at 11:00:46PM +0100, Lorenzo wrote:
> On Sun, 2 Feb 2025 21:00:41 +0000
> Andrew Bower <andrew@bower.uk> wrote:
> 
> For the boot entry I can just remove the wtmpdb call in stage 1; for the
> shutdown entry in runit, is implemented as "halt -w[1]" in shutdown.c
> that is called by umountnfs.sh in runlevel 0 or 6, and it's not obvious
> to me how to prevent a double shutdown entry here.
> maybe the sysv script can be a no-op when runit is init?
> 
> [ -f  /run/runit.stopit ] && exit 0
> 
> better ideas are welcome; when I added the code to runit I didn't think
> a sysv script was going to be accepted in the wtmpdb package.

What about /etc/runit/override-sysv.d?

> [1] by the way, what's the plan for 'halt -w' in SysV 's shutdown
> implementation?

No idea, hoping the experts on this mailing list will chime in! :-)

However, since umountnfs.sh is an initscript that won't be used from
systemd, it seems to me that this would be the place to call wtmpdb,
instead of going via the halt command. That then makes this a
co-ordination question between this initscript and the wtmpdb one? We
might find out that the call is redundant from umountnfs.sh if we have
the wtmpdb initscript.

But in the case of sysvinit, it still records classic wtmp. It could
simply continue to do so. That might be useful in an ultra low footprint
scenario where some minimal audit capability is required - the use case
where my proposed sysvinit-utmp-utils subpackage would be useful.

By the way, killing plymouth lets this script start in S runlevel in
single user mode, but it also means double entries for every boot. I
don't know why. I think perhaps we could start with runlevel 1+ and then
iterate the initscript if we find we can improve on this?

[toc] | [prev] | [next] | [standalone]

#1231495

On Sun, 2 Feb 2025 22:25:43 +0000
Andrew Bower <andrew@bower.uk> wrote:

> On Sun, Feb 02, 2025 at 11:00:46PM +0100, Lorenzo wrote:
> > On Sun, 2 Feb 2025 21:00:41 +0000
> > Andrew Bower <andrew@bower.uk> wrote:
> > 
> > For the boot entry I can just remove the wtmpdb call in stage 1;
> > for the shutdown entry in runit, is implemented as "halt -w[1]" in
> > shutdown.c that is called by umountnfs.sh in runlevel 0 or 6, and
> > it's not obvious to me how to prevent a double shutdown entry here.
> > maybe the sysv script can be a no-op when runit is init?
> > 
> > [ -f  /run/runit.stopit ] && exit 0
> > 
> > better ideas are welcome; when I added the code to runit I didn't
> > think a sysv script was going to be accepted in the wtmpdb package.
> 
> What about /etc/runit/override-sysv.d?

yes, that would work too, I can ship the file with runit-init package.

[toc] | [prev] | [next] | [standalone]

#1232206

[Multipart message — attachments visible in raw view] — view raw

Hi Lorenzo,

On Sun, Feb 02, 2025 at 11:52:25PM +0100, Lorenzo wrote:
> On Sun, 2 Feb 2025 22:25:43 +0000
> Andrew Bower <andrew@bower.uk> wrote:
> 
> > On Sun, Feb 02, 2025 at 11:00:46PM +0100, Lorenzo wrote:
> > > On Sun, 2 Feb 2025 21:00:41 +0000
> > > Andrew Bower <andrew@bower.uk> wrote:
> > > 
> > > For the boot entry I can just remove the wtmpdb call in stage 1;
> > > for the shutdown entry in runit, is implemented as "halt -w[1]" in
> > > shutdown.c that is called by umountnfs.sh in runlevel 0 or 6, and
> > > it's not obvious to me how to prevent a double shutdown entry here.
> > > maybe the sysv script can be a no-op when runit is init?
> > > 
> > > [ -f  /run/runit.stopit ] && exit 0
> > > 
> > > better ideas are welcome; when I added the code to runit I didn't
> > > think a sysv script was going to be accepted in the wtmpdb package.
> > 
> > What about /etc/runit/override-sysv.d?
> 
> yes, that would work too, I can ship the file with runit-init package.

Like this? Trivial patch here works for me, although I put it in the
wrong package!

I thought a .pkgblock file as described in the README would be ideal but
there is actually no logic to handle such a file - did you intend to add
it? Do you want me to raise a bug about that?

Thanks,

Andrew

[toc] | [prev] | [next] | [standalone]

#1232211

Hi,

On Fri, 7 Feb 2025 23:34:28 +0000
Andrew Bower <andrew@bower.uk> wrote:

> > > What about /etc/runit/override-sysv.d?
> > 
> > yes, that would work too, I can ship the file with runit-init
> > package.
> 
> Like this? Trivial patch here works for me, although I put it in the
> wrong package!
> 
> I thought a .pkgblock file as described in the README would be ideal
> but there is actually no logic to handle such a file - did you intend
> to add it? Do you want me to raise a bug about that?

I've added this (both the .pkgblock file and the fix in
stage1/3 and run_sysv_scripts) to my TODO list for 2.2 release.

thanks :)
Lorenzo

> 
> Thanks,
> 
> Andrew

[toc] | [prev] | [next] | [standalone]

#1231539

control: reassign -1 wtmpdb

Andrew,

This seems to be resolvable in wtmpdb, so I am reassigning.

Best wishes

Mark

[toc] | [prev] | [next] | [standalone]

#1231542

Control: tags -1 + patch

On Mon, Feb 03, 2025 at 09:05:59AM +0000, Mark Hindley wrote:
> control: reassign -1 wtmpdb
> 
> Andrew,
> 
> This seems to be resolvable in wtmpdb, so I am reassigning.

https://salsa.debian.org/abower/wtmpdb/-/commit/bfcc651ba54f2edec3cb502968db21556d0cb47e
https://salsa.debian.org/abower/wtmpdb/-/commits/sysvinit-booting?ref_type=heads

Thanks for your help!

[toc] | [prev] | [next] | [standalone]

#1231358

On Sat, Feb 01, 2025 at 08:23:51PM +0000, Mark Hindley wrote:
[to Chris]
> Is it reasonable to infer the wtmpdb is not
> going to have longevity as a solution here?

With the upstream effort focussed on a long-running daemon to solve a
file-locking problem, I suspect we need to look after v0.13 for a while
and prioritise a good experience for users upgrading from bookworm.

[toc] | [prev] | [next] | [standalone]

#1231374

On Sat, Feb 01, 2025 at 08:23:51PM +0000, Mark Hindley wrote:
> Chris,
> 
> Thanks for your input as well.
> 
> I notice that wtmpdb is orphaned[1] and you have preemptively declined to comment
> on the reason, which I respect. Is it reasonable to infer the wtmpdb is not
> going to have longevity as a solution here?

That is to be seen. I think libwtmpdb does not at this point provide
a stable ABI, so I'd avoid linking against it.

I got the feeling RH might come up with something else, or maybe
wtmpdb will be good enough for everyone after all.

Providing initscripts would IMO be sensible; for systemd wmptdb
provides two .service files as integration. OTOH maybe recording
boots is not such an important feature. 

Chris

[toc] | [prev] | [next] | [standalone]

#1231541

On Sun, Feb 02, 2025 at 02:26:20AM +0100, Chris Hofstaedtler wrote:
> Providing initscripts would IMO be sensible; for systemd wmptdb
> provides two .service files as integration.

Yes, unit-translator converts wtmpdb-rotate to:

# Generated by /home/mark/src/debian/unit-translator/utrans from:
#  e9c8cbb4c61b786779a85eddb3ca93fa0d2315216e45d2cbc729c2b5db344411  ./tmp.iH71YBzenr/usr/lib/systemd/system/wtmpdb-rotate.timer
#  2e6646662d8856d9048eab093e8f59d9399a8d0835b8fa789945d4d0efd8bfbb  ./tmp.iH71YBzenr/usr/lib/systemd/system/wtmpdb-rotate.service

# m h dom mon dow user command

0 0 1 * * root [ -d /run/systemd/system ] || { /usr/bin/wtmpdb rotate; }
# Alternatively, if your system is running openrc you could use
# 0 0 1 * * root rc-service wtmpdb-rotate start


Obviously it can be cleaned up a bit manually, but it is a reasonable starting
point.

Mark

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web