Devuan bug report logs - #900
procps: w does not query elogind for sessions

Reply or subscribe to this bug.

Toggle useless messages

---

Message #5 received at submit@bugs.devuan.org (full text, mbox, reply):

Package: procps
Version: 2:4.0.4-8devuan1
Severity: grave

Dear Maintainer,

Running 'w' returns only sessions that are lucky enough still to be recorded in
utmp, and not any sessions that only elogind knows about.

Unfortunately with so many components removing utmp support (prematurely, in my
opinion), this makes the tool next to useless in Excalibur. This includes
virtual console logins recorded by 'login'.

I have reported a related issue against Debian at
https://bugs.debian.org/1108549 which relates to elogind not being queried if
sd_booted() returns false, despite sd_get_sessions() being capable of returning
the results needed (coreutils 'who' does this) but have seen no interest in the
bug since I raised it a month ago.

Things may be different in the Devuan fork because I see it is not linked with
libsystemd - which means it would _never_ report such sessions successfully.

Thanks!


-- System Information:
Distributor ID:	Devuan
Description:	Devuan GNU/Linux 6 (excalibur/ceres)
Release:	6
Codename:	excalibur ceres
Architecture: x86_64

Kernel: Linux 6.12.37+deb13-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en
Shell: /bin/sh linked to /usr/bin/dash
Init: runit (via /run/runit.stopit)
LSM: AppArmor: enabled

Versions of packages procps depends on:
ii  init-system-helpers  1.68devuan1
ii  libc6                2.41-9
ii  libncursesw6         6.5+20250216-2
ii  libproc2-0           2:4.0.4-8devuan1
ii  libtinfo6            6.5+20250216-2

Versions of packages procps recommends:
ii  linux-sysctl-defaults  4.12
ii  psmisc                 23.7-2

procps suggests no packages.

-- no debconf information

---

Message #8 received at 900@bugs.devuan.org (full text, mbox, reply):

Andrew,

Thanks for this. You have been folowwing this area more closely than me. 

I believe the original impetus to remove libsystemd linkage from procps 
was to reduce libsystemd infiltration into 'core' utilities. 

Devuan systems without elogind are viable (I use sway/seatd as my daily 
driver) so just adding elogind support to procps isn't a universal 
solution.

Do you have a suggestion or idea as to a way forward?

Mark

---

Message #13 received at 900@bugs.devuan.org (full text, mbox, reply):

Hi Mark,

On Mon, Jul 28, 2025 at 11:42:19AM +0100, Mark Hindley wrote:
> Thanks for this. You have been folowwing this area more closely than me. 

Unfortunately I haven't been on top of the utmp or lastlog side of this
transition even though I did adopt wtmpdb with a view to mitigating user
experiences with that change.

> I believe the original impetus to remove libsystemd linkage from procps 
> was to reduce libsystemd infiltration into 'core' utilities. 

I am all in favour of that ambition. I don't think the key
building-block packages should depend on libsystemd, hence my
disappointment when coreutils recently gained the dependency (should we
be forking that?)

> Devuan systems without elogind are viable (I use sway/seatd as my daily 
> driver) so just adding elogind support to procps isn't a universal 
> solution.

Does sway/seatd write to utmp? Does it do anything else?

> Do you have a suggestion or idea as to a way forward?

I see we have forked util-linux, so one thing we could do is to fix the
build of login(1) to restore writing to utmp, for virtual console
logins. That assumes that this is what has actually been broken - I
haven't checked yet.

I think that still leaves session manager entries missing (I seem to get
one for Debian/lightdm but not Devuan/slim). openssh seems to behave
well with regard to utmp.

If we are going to make continued use of utmp we should really try to
sort out any packages that don't realise struct utmp now has unsigned
seconds (converts the y1901/y2038 problem into a y1969/y2160 problem),
but that's not immediately practical. (IMO that would have been a better
use of Debian development time than excising "legacy" usage, which could
have waited another release cycle while the replacements proved and
improved themselves...)

Now, is there anything we can do with elogind-captured sessions without
linking with libsystemd0? Well, maybe... I'm thinking about options! But
to be honest, probably not in time for Excalibur.

Andrew

---

Message #18 received at 900@bugs.devuan.org (full text, mbox, reply):

Andrew,

On Mon, Jul 28, 2025 at 09:06:10PM +0100, Andrew Bower wrote:
> > I believe the original impetus to remove libsystemd linkage from procps 
> > was to reduce libsystemd infiltration into 'core' utilities. 
> 
> I am all in favour of that ambition. I don't think the key
> building-block packages should depend on libsystemd, hence my
> disappointment when coreutils recently gained the dependency (should we
> be forking that?)

Hmmm, yes, conceivably.

> > Devuan systems without elogind are viable (I use sway/seatd as my daily 
> > driver) so just adding elogind support to procps isn't a universal 
> > solution.
> 
> Does sway/seatd write to utmp? Does it do anything else?

I think not: I run it from the console, so it relies on login(1).

> > Do you have a suggestion or idea as to a way forward?
> 
> I see we have forked util-linux, so one thing we could do is to fix the
> build of login(1) to restore writing to utmp, for virtual console
> logins. That assumes that this is what has actually been broken - I
> haven't checked yet.

That seems sane. I'll see if I can find the commit.

Thanks

Mark

---

Message #23 received at 900@bugs.devuan.org (full text, mbox, reply):

On Tue, Jul 29, 2025 at 11:10:45AM +0100, Mark Hindley wrote:
 > > Devuan systems without elogind are viable (I use sway/seatd as my daily 
> > > driver) so just adding elogind support to procps isn't a universal 
> > > solution.
> > 
> > Does sway/seatd write to utmp? Does it do anything else?
> 
> I think not: I run it from the console, so it relies on login(1).

I take it from this that you currently don't get any login entries,
then?

> > > Do you have a suggestion or idea as to a way forward?
> > 
> > I see we have forked util-linux, so one thing we could do is to fix the
> > build of login(1) to restore writing to utmp, for virtual console
> > logins. That assumes that this is what has actually been broken - I
> > haven't checked yet.
> 
> That seems sane. I'll see if I can find the commit.

Looking at the following, utmp writing had already been turned off in
src:shadow before util-linux took the command over.

https://salsa.debian.org/debian/util-linux/-/commit/0fa51ed784e19e58f8e04e43aabc3f324d4135f7#4c5d3c697d7b8f925a7d3b18f168f4c51cbdb43f

I haven't found the point in the old package where it was turned off,
unless it was implicit with the --enable-logind flag:

https://salsa.debian.org/debian/shadow/-/commit/1526e6cde87c48e0691c9e8cd2ca9755adcfd4b6

I haven't investigated very thoroughly.

---

Message #28 received at 900@bugs.devuan.org (full text, mbox, reply):

On Tue, Jul 29, 2025 at 09:26:52PM +0100, Andrew Bower wrote:
> > I think not: I run it from the console, so it relies on login(1).
> 
> I take it from this that you currently don't get any login entries,
> then?

I haven't upgraded to excalibur yet.

I have just updated procps in ceres to 2%4.0.4-9devuan1 which includes your fix
for Debian#1108549.

Once that is in the mirrors, perhaps you can see what does and doesn't work?

Thanks

Mark

---

Message #33 received at 900@bugs.devuan.org (full text, mbox, reply):

On Thu, Jul 31, 2025 at 05:27:57PM +0100, Mark Hindley wrote:
> On Tue, Jul 29, 2025 at 09:26:52PM +0100, Andrew Bower wrote:
> > > I think not: I run it from the console, so it relies on login(1).
> > 
> > I take it from this that you currently don't get any login entries,
> > then?
> 
> I haven't upgraded to excalibur yet.
> 
> I have just updated procps in ceres to 2%4.0.4-9devuan1 which includes your fix
> for Debian#1108549.

Thanks for merging that!

> Once that is in the mirrors, perhaps you can see what does and doesn't work?

Unfortunately it doesn't make any difference on Devuan because the fixes
are in bits that are compiled out without libsystemd!

I think the locus of the work for Devuan (if we want to avoid libsystemd
in core tools, which is reasonable but has consequences) is that we need
to restore utmp-writing in other packages. That won't be fun or
comprehensive.

But it feels like we have lost some basic functionality expected by
Linux users the way things are.

Sorry I don't have a testbed or capacity to check a seatd environment
right now!

---

Message #38 received at 900@bugs.devuan.org (full text, mbox, reply):

On Thu, Jul 31, 2025 at 11:38:20PM +0100, Andrew Bower wrote:
> But it feels like we have lost some basic functionality expected by
> Linux users the way things are.

Assuming we don't have time to do anything about this, I wonder if it's
a candidate for release notes or known issues? Is there a WIP set of
release notes for Excalibur?

(P.S. Sorry about the red herring on insserv earlier on the Debian BTS!)

---

Message #43 received at 900@bugs.devuan.org (full text, mbox, reply):

Hi Mark,

On Thu, Jul 31, 2025 at 11:38:20PM +0100, Andrew Bower wrote:
> On Thu, Jul 31, 2025 at 05:27:57PM +0100, Mark Hindley wrote:
> > On Tue, Jul 29, 2025 at 09:26:52PM +0100, Andrew Bower wrote:
> > > > I think not: I run it from the console, so it relies on login(1).
> > > 
> > > I take it from this that you currently don't get any login entries,
> > > then?
> > 
> > I haven't upgraded to excalibur yet.
> > 
> > I have just updated procps in ceres to 2%4.0.4-9devuan1 which includes your fix
> > for Debian#1108549.
> 
> Thanks for merging that!
> 
> > Once that is in the mirrors, perhaps you can see what does and doesn't work?
> 
> Unfortunately it doesn't make any difference on Devuan because the fixes
> are in bits that are compiled out without libsystemd!
> 
> I think the locus of the work for Devuan (if we want to avoid libsystemd
> in core tools, which is reasonable but has consequences) is that we need
> to restore utmp-writing in other packages. That won't be fun or
> comprehensive.

Here is a patch that restores utmp writing to uses of login(1), which
fixes the reporting of virtual console sessions in 'w' on Devuan.

https://git.devuan.org/abower/util-linux/pulls/1

ajb85@arden:~/git/util-linux$ w
 22:50:08 up  1:09,  2 users,  load average: 0.36, 0.85, 1.19
USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU  WHAT
ajb85    tty2     -                22:45    4:46   0.06s  0.06s -bash
ajb85@arden:~/git/util-linux$ finger
Login     Name           Tty      Idle  Login Time   Office     Office Phone
ajb85     Andrew Bower  *:0.0           Aug  8 21:40 (:0.0)
ajb85     Andrew Bower  *tty2        4  Aug  8 22:45

Andrew

---

Message #48 received at 900@bugs.devuan.org (full text, mbox, reply):

Hi Mark,

On Fri, Aug 08, 2025 at 10:56:34PM +0100, Andrew Bower wrote:
> Here is a patch that restores utmp writing to uses of login(1), which
> fixes the reporting of virtual console sessions in 'w' on Devuan.
> 
> https://git.devuan.org/abower/util-linux/pulls/1

Sorry, I'm not familiar with gitea and ended up raising the PR on my
own fork! Here's a proper one:

https://git.devuan.org/devuan/util-linux/pulls/1

I am not cognisant of the workflow for contributing to Devuan packages
so let me know if there's anything else I can do to help!

Thanks,

Andrew

---

Message #53 received at 900@bugs.devuan.org (full text, mbox, reply):

On Fri, Aug 08, 2025 at 11:06:30PM +0100, Andrew Bower wrote:
> https://git.devuan.org/devuan/util-linux/pulls/1

Thanks

Isn't

-	log_utmp(&cxt);
+	log_utmp(&cxt);

no-op?

Do we need to restore the lastlog and btmp entries as well?

Perhaps we just drop the whole patch?

Mark

---

Message #58 received at 900@bugs.devuan.org (full text, mbox, reply):

Hi Mark,

On Sat, Aug 09, 2025 at 04:44:19PM +0100, Mark Hindley wrote:
> On Fri, Aug 08, 2025 at 11:06:30PM +0100, Andrew Bower wrote:
> > https://git.devuan.org/devuan/util-linux/pulls/1
> 
> Thanks
> 
> Isn't
> 
> -	log_utmp(&cxt);
> +	log_utmp(&cxt);
> 
> no-op?

Yes! My patch is a crude edit of Chris's patch to neutralise this
removal but it is valid and works.

I think in retrospect that it might be clearer to have another quilt
patch layered on top of his patch.

> Do we need to restore the lastlog and btmp entries as well?
> 
> Perhaps we just drop the whole patch?

Lastlog was already written by pam_lastlog.so before trixie and the
replacement is pam_lastlog2. The tooling to read btmp was removed by
util-linux.

So I'm not sure there would be any benefit from reversing the rest of
the patch to be worth the increased delta from Debian. Bear in mind that
the patch wasn't just about dropping utmp, it was also about taking over
login from another source package.

An alternative approach I considered was to include code to read the
systemd-style login records directly in 'w' but that seemed like too
much for a patch and it would certainly take more time!

Andrew

---

Message #63 received at 900@bugs.devuan.org (full text, mbox, reply):

On Sat, Aug 09, 2025 at 08:46:28PM +0100, Andrew Bower wrote:
> On Sat, Aug 09, 2025 at 04:44:19PM +0100, Mark Hindley wrote:
> > On Fri, Aug 08, 2025 at 11:06:30PM +0100, Andrew Bower wrote:
> > > https://git.devuan.org/devuan/util-linux/pulls/1
> > 
> > Thanks
> > 
> > Isn't
> > 
> > -	log_utmp(&cxt);
> > +	log_utmp(&cxt);
> > 
> > no-op?
> 
> Yes! My patch is a crude edit of Chris's patch to neutralise this
> removal but it is valid and works.
> 
> I think in retrospect that it might be clearer to have another quilt
> patch layered on top of his patch.

I've reworked https://git.devuan.org/devuan/util-linux/pulls/1 to create
a patch that explicitly restores the utmp writing rather than editing a
debian patch. I think this is clearer now what has happened, if you read
the series:

debian/login-turn-off-btmp-utmp-lastlog-writing.patch
..
devuan/restore-utmp-writing.patch

> > Do we need to restore the lastlog and btmp entries as well?
> > 
> > Perhaps we just drop the whole patch?
> 
> Lastlog was already written by pam_lastlog.so before trixie and the
> replacement is pam_lastlog2. The tooling to read btmp was removed by
> util-linux.
> 
> So I'm not sure there would be any benefit from reversing the rest of
> the patch to be worth the increased delta from Debian. Bear in mind that
> the patch wasn't just about dropping utmp, it was also about taking over
> login from another source package.
> 
> An alternative approach I considered was to include code to read the
> systemd-style login records directly in 'w' but that seemed like too
> much for a patch and it would certainly take more time!

---

Message #68 received at 900-done@bugs.devuan.org (full text, mbox, reply):

Version: 2.41-5devuan2

Source package util-linux (2.41-5devuan2) added to Devuan suite unstable.

This closes bug report 900.

Thanks

DAK managing the Devuan archive

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Format: 1.8
Date: Sun, 10 Aug 2025 09:55:59 +0100
Source: util-linux
Architecture: source
Version: 2.41-5devuan2
Distribution: unstable
Urgency: medium
Maintainer: Devuan Developers <devuan-dev@lists.dyne.org>
Changed-By: Mark Hindley <mark@hindley.org.uk>
Closes: 900
Changes:
 util-linux (2.41-5devuan2) unstable; urgency=medium
 .
   [ Andrew Bower ]
   * Patch to restore login writing to utmp. (Closes: #900)
Checksums-Sha1:
 3da89a847b257bd03e34c6cd79ad138c7895000c 4661 util-linux_2.41-5devuan2.dsc
 ae3ed10120cd2bbda606ac74c7024ae32aa7c6dd 129908 util-linux_2.41-5devuan2.debian.tar.xz
 a985d2eaf3f3470afa694580d4379ab2bf531574 5620 util-linux_2.41-5devuan2_source.buildinfo
Checksums-Sha256:
 fe854366ba440ae19b02c93e3673262f827510cebf53f3dcb87c5830d7201b1d 4661 util-linux_2.41-5devuan2.dsc
 71b5c0c74cb45705a61c6245a3ce29c7350324dfe27f7dc226f85b1ad7654f54 129908 util-linux_2.41-5devuan2.debian.tar.xz
 c0a6552bffa3bedf97741a81e83f175513f2e0b0ec20b8ced3bb21b1253d5569 5620 util-linux_2.41-5devuan2_source.buildinfo
Files:
 3baf52e7c0cf7421342dd4cff943d32f 4661 utils required util-linux_2.41-5devuan2.dsc
 69418f1a917d62f12d3bfbcb1e20b0ee 129908 utils required util-linux_2.41-5devuan2.debian.tar.xz
 5f37ca9e997ac3e5afd14a99a6aabf6d 5620 utils required util-linux_2.41-5devuan2_source.buildinfo

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEEcuPLdzMV36LkZHQ9lFMhJFQZIvsFAmiYXzUACgkQlFMhJFQZ
IvuOpAf9Eq1UZWdHJ8hI1d5IMiKXTK0zQFi0g8ceyS0T42FRiGpaQr3gdkzFQUvl
XKPdUyOyUvtcbkHbY5c10dCTFJrSNfvDs6v6ZjlFb71ForkZ3LFjUwh0L8kPyov5
/TT9cjsavwhKUEAAuY1RMp7PicOktPKoQghxHeBXTaBsnbogDaYhQ2OEVo/1yGn7
RmvwqL6qdJsOPUTABpIGOtv8ZXlnHkcPE0o53JAIkb1f3a+KSeUgIdjzfZriYcue
Sw+iKR+LK18c/HjoM6jyzFhN49161L2xOrGKXVY4lyJRUZQg2ec+RvpE8Uw4i3Z8
I3nh7cabdlFmkrmsFdpeguKbsAT7rg==
=arcK
-----END PGP SIGNATURE-----

---

Send a report that this bug log contains spam.

---