GNU bug report logs -
#73928
"who" should support wtmpdb
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 73928 in the body.
You can then email your comments to 73928 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 21 Oct 2024 11:17:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Vincent Lefevre <vincent <at> vinc17.net>:
New bug report received and forwarded. Copy sent to
bug-coreutils <at> gnu.org.
(Mon, 21 Oct 2024 11:17:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The "who" utility should support wtmpdb.
It no longer works when utmp support is disabled by systemd
(the /var/run/utmp file no longer exists).
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 21 Oct 2024 16:50:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
On 2024-10-21 04:15, Vincent Lefevre wrote:
> The "who" utility should support wtmpdb.
How would that be done?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Sun, 16 Feb 2025 18:06:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On 2025-02-16 18:55:54 +0100, Chris Hofstaedtler wrote:
> Control: retitle -1 coreutils: "who" needs to ask seat manager
>
> On Fri, Sep 20, 2024 at 05:24:11PM +0200, Vincent Lefevre wrote:
> > Control: retitle -1 coreutils: "who" should support wtmpdb (y2038)
>
> This is mistaken. wtmpdb is a history database. who(1) wants current
> sessions, and they are being tracked by logind.
It had been said that wtmpdb was meant to replace utmp, but perhaps
this was wrong.
> w(1) has a working implementation.
No, w(1) is broken (at least in sid). See the difference between
"who" and "w" with systemd 256.7-1, i.e. before the upgrade of
systemd that removed utmp support:
qaa:~> who
vinc17 tty7 2025-02-12 20:22 (:0)
vinc17 pts/0 2025-02-12 20:22 (:0)
vinc17 pts/3 2025-02-12 20:22 (:0)
vinc17 pts/2 2025-02-12 20:22 (:0)
vinc17 pts/1 2025-02-12 20:22 (:0)
vinc17 pts/5 2025-02-13 19:59 (155.133.131.76)
vinc17 pts/6 2025-02-14 03:44 (:0)
vinc17 pts/4 2025-02-12 20:22 (:0)
vinc17 pts/7 2025-02-12 20:22 (:0)
vinc17 pts/8 2025-02-12 20:22 (:0)
vinc17 pts/10 2025-02-12 20:35 (:0)
vinc17 pts/11 2025-02-12 20:35 (:0)
vinc17 pts/12 2025-02-13 01:40 (:0)
vinc17 pts/13 2025-02-13 02:31 (:0)
vinc17 pts/14 2025-02-16 18:57 (:pts/9:S.0)
vinc17 pts/15 2025-02-16 18:59 (:0)
vinc17 pts/16 2025-02-16 18:57 (:pts/9:S.1)
vinc17 pts/17 2025-02-15 02:10 (:0)
qaa:~> w
19:00:52 up 3 days, 22:39, 3 users, load average: 0.58, 0.76, 0.77
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
vinc17 155.133.131.76 Thu19 23:10m 0.00s 0.02s sshd-session: vinc17 [priv]
vinc17 - Wed20 23:10m 0.00s 0.01s lightdm --session-child 15 22
vinc17 - Wed20 23:10m 0.00s 0.20s /usr/lib/systemd/systemd --user
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Sun, 16 Feb 2025 18:18:04 GMT)
Full text and
rfc822 format available.
Message #14 received at 73928 <at> debbugs.gnu.org (full text, mbox):
Control: retitle -1 coreutils: "who" needs to ask seat manager
On Fri, Sep 20, 2024 at 05:24:11PM +0200, Vincent Lefevre wrote:
> Control: retitle -1 coreutils: "who" should support wtmpdb (y2038)
This is mistaken. wtmpdb is a history database. who(1) wants current
sessions, and they are being tracked by logind.
w(1) has a working implementation.
Chris
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Sun, 16 Feb 2025 18:30:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On 2025-02-16 19:05:13 +0100, Vincent Lefevre wrote:
> On 2025-02-16 18:55:54 +0100, Chris Hofstaedtler wrote:
> > Control: retitle -1 coreutils: "who" needs to ask seat manager
> >
> > On Fri, Sep 20, 2024 at 05:24:11PM +0200, Vincent Lefevre wrote:
> > > Control: retitle -1 coreutils: "who" should support wtmpdb (y2038)
> >
> > This is mistaken. wtmpdb is a history database. who(1) wants current
> > sessions, and they are being tracked by logind.
>
> It had been said that wtmpdb was meant to replace utmp, but perhaps
> this was wrong.
After some search, quoting you from
https://lists.debian.org/debian-release/2024/04/msg00493.html
| Subject: Y2038-safe replacements for utmp/wtmp and lastlog
| From: Chris Hofstaedtler
| Date: Fri, 26 Apr 2024 13:12:21 +0200
[...]
| you are probably aware of the time_t-64bit migration :-)
| However, this does not magically transition all data formats to 64bit
| times. One such instance is the set of utmp/wtmp and lastlog files.
|
| Thorsten Kukuk and others have been working on replacements for the
| existing file formats and interfaces [1]; these are called wtmpdb
| and lastlog2.
[...]
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Sun, 16 Feb 2025 21:46:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 16, 2025 at 07:05:13PM +0100, Vincent Lefevre wrote:
>No, w(1) is broken (at least in sid). See the difference between
>"who" and "w" with systemd 256.7-1, i.e. before the upgrade of
>systemd that removed utmp support:
That's because someone decided to suddenly remove an interface which has
been used for decades without any kind of transition plan or
replacement. This isn't a bug "who" can fix.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Sun, 16 Feb 2025 22:53:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 73928 <at> debbugs.gnu.org (full text, mbox):
At this point I confess I don't know what changes would be needed for
GNU 'who'. I see a difference of opinion as to whether 'w' works. There
seem to be multiple mechanisms in play (utmp, wtmp, wtmpdb, lastlog2,
logind, maybe others?) and I don't know when to use which, or even how
to use them except for the traditional utmp/wtmp files.
Perhaps whoever has changed the longstanding API (is that Thorsten
Kukuk, or someone else? anyway I'll cc Thorsten) can chime in with a
proposed patch to bleeding-edge GNU coreutils. This would probably mean
a patch to Gnulib's readutmp module, which already is supposed to work
with systemd's new utmp interfaces but I guess some people are reporting
problems with it? (This is unclear.)
For what it's worth, I briefly looked at
<https://build.opensuse.org/package/show/openSUSE%3AFactory/coreutils>
and didn't see a patch there. So perhaps the problem is already
addressed in bleeding-edge Coreutils?
Without some actionable advice from experts in this area, I don't see
this portability issue being fixed any time soon.
For now, I've merged the following GNU Coreutils bug reports as they all
seem to be the same topic.
https://bugs.gnu.org/73928
https://bugs.gnu.org/76346
https://bugs.gnu.org/76347
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Sun, 16 Feb 2025 23:29:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On 2025-02-16 23:56:43 +0100, Chris Hofstaedtler wrote:
> * Michael Stone <mstone <at> debian.org> [250216 22:45]:
> > On Sun, Feb 16, 2025 at 07:05:13PM +0100, Vincent Lefevre wrote:
> > > No, w(1) is broken (at least in sid). See the difference between
> > > "who" and "w" with systemd 256.7-1, i.e. before the upgrade of
> > > systemd that removed utmp support:
> >
> > That's because someone decided to suddenly remove an interface which has
> > been used for decades without any kind of transition plan or replacement.
>
> Clearly there is a replacement, because the data is there:
>
> % w
> 23:53:23 up 1 min, 2 users, load average: 0.06, 0.03, 0.00
> USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
> ch 192.168.64.1 23:53 1:24 0.00s 0.02s sshd-session: ch [priv]
> ch - 23:53 1:24 0.00s 0.04s /usr/lib/systemd/systemd --user
No data for xterm. Other terminals are affected too, such as
GNOME Terminal.
> % loginctl
> SESSION UID USER SEAT LEADER CLASS TTY IDLE SINCE
> 1 1000 ch - 601 user - no -
> 2 1000 ch - 606 manager - no -
>
> 2 sessions listed.
On my Debian/unstable machine, I do not even get the same number
of lines as with "w" when mosh is used. No such issue with "who"
and old systemd with utmp enabled.
> But who:
>
> % who
> %
>
> Chris
>
> PS: Lack of tty in the list is IIRC some problem with openssh not
> passing the TTY to PAM, but this is a separate thing.
But with old system versions (and/or old "w" versions), such as in
Debian/stable (bookworm), the tty is shown by "w":
joooj:~> w
00:17:55 up 8 days, 1:40, 4 users, load average: 0.02, 0.07, 0.04
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
vinc17 pts/0 2a02:8428:1b1d:4 Wed20 1.00s 4.22s 0.03s w
vinc17 pts/4 mosh- 17:29 6:48m 0.97s 0.97s -zsh
vinc17 pts/5 mosh- Tue19 5days 0.33s 0.33s -zsh
vinc17 pts/6 mosh- Fri23 2days 0.37s 16.97s mosh-server new
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 00:02:02 GMT)
Full text and
rfc822 format available.
Message #31 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 17, 2025 at 12:28:03AM +0100, Vincent Lefevre wrote:
>No data for xterm. Other terminals are affected too, such as
>GNOME Terminal.
Yes, much of the data from the old utmp is simply not there. A sane
transition would deprecate utmp in one release while adding a
replacement, then remove in the next--not just drop it and hope other
people figure out how to cobble together a solution.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 05:02:03 GMT)
Full text and
rfc822 format available.
Message #34 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On Sun, Feb 16, 2025 at 07:29:22PM +0100, Vincent Lefevre wrote:
> After some search, quoting you from
>
> https://lists.debian.org/debian-release/2024/04/msg00493.html
>
> | Subject: Y2038-safe replacements for utmp/wtmp and lastlog
> | From: Chris Hofstaedtler
> | Date: Fri, 26 Apr 2024 13:12:21 +0200
> [...]
> | you are probably aware of the time_t-64bit migration :-)
> | However, this does not magically transition all data formats to 64bit
> | times. One such instance is the set of utmp/wtmp and lastlog files.
> |
> | Thorsten Kukuk and others have been working on replacements for the
> | existing file formats and interfaces [1]; these are called wtmpdb
> | and lastlog2.
> [...]
Right, that was a bit unclear. The replacements for file-based data
are indeed wtmpdb and lastlog2, but both are optional. The current
state ("utmp") is inside logind.
Chris
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 05:02:03 GMT)
Full text and
rfc822 format available.
Message #37 received at 73928 <at> debbugs.gnu.org (full text, mbox):
* Michael Stone <mstone <at> debian.org> [250216 22:45]:
> On Sun, Feb 16, 2025 at 07:05:13PM +0100, Vincent Lefevre wrote:
> > No, w(1) is broken (at least in sid). See the difference between
> > "who" and "w" with systemd 256.7-1, i.e. before the upgrade of
> > systemd that removed utmp support:
>
> That's because someone decided to suddenly remove an interface which has
> been used for decades without any kind of transition plan or replacement.
Clearly there is a replacement, because the data is there:
% w
23:53:23 up 1 min, 2 users, load average: 0.06, 0.03, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
ch 192.168.64.1 23:53 1:24 0.00s 0.02s sshd-session: ch [priv]
ch - 23:53 1:24 0.00s 0.04s /usr/lib/systemd/systemd --user
% loginctl
SESSION UID USER SEAT LEADER CLASS TTY IDLE SINCE
1 1000 ch - 601 user - no -
2 1000 ch - 606 manager - no -
2 sessions listed.
But who:
% who
%
Chris
PS: Lack of tty in the list is IIRC some problem with openssh not
passing the TTY to PAM, but this is a separate thing.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 05:02:04 GMT)
Full text and
rfc822 format available.
Message #40 received at 73928 <at> debbugs.gnu.org (full text, mbox):
* Paul Eggert <eggert <at> cs.ucla.edu> [250216 23:52]:
> At this point I confess I don't know what changes would be needed for GNU
> 'who'. I see a difference of opinion as to whether 'w' works. There seem to
> be multiple mechanisms in play (utmp, wtmp, wtmpdb, lastlog2, logind, maybe
> others?) and I don't know when to use which, or even how to use them except
> for the traditional utmp/wtmp files.
>
> Perhaps whoever has changed the longstanding API (is that Thorsten Kukuk, or
> someone else? anyway I'll cc Thorsten) can chime in with a proposed patch to
> bleeding-edge GNU coreutils. This would probably mean a patch to Gnulib's
> readutmp module, which already is supposed to work with systemd's new utmp
> interfaces but I guess some people are reporting problems with it? (This is
> unclear.)
>
> For what it's worth, I briefly looked at
> <https://build.opensuse.org/package/show/openSUSE%3AFactory/coreutils> and
> didn't see a patch there. So perhaps the problem is already addressed in
> bleeding-edge Coreutils?
Looks like if Debian would build coreutils with --enable-systemd, it
would just work:
https://sources.debian.org/src/coreutils/9.5-1/lib/readutmp.c/?hl=678#L678
Chris
bug closed, send any further explanations to
76346 <at> debbugs.gnu.org and Chris Hofstaedtler <zeha <at> debian.org>
Request was from
Chris Hofstaedtler <zeha <at> debian.org>
to
control <at> debbugs.gnu.org.
(Mon, 17 Feb 2025 05:02:05 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 07:04:01 GMT)
Full text and
rfc822 format available.
Message #45 received at 73928 <at> debbugs.gnu.org (full text, mbox):
Hi,
Let me clarify some things.
On Sun, Feb 16, 2025 at 11:52 PM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>
> At this point I confess I don't know what changes would be needed for
> GNU 'who'. I see a difference of opinion as to whether 'w' works. There
> seem to be multiple mechanisms in play (utmp, wtmp, wtmpdb, lastlog2,
> logind, maybe others?) and I don't know when to use which, or even how
> to use them except for the traditional utmp/wtmp files.
Let's give a short summary:
lastlog from util-linux got replaced with lastlog2. There were very
few applications creating lastlog entries and using them to display
the last login message. This code can be removed, this is handled now
by pam_lastlog2.so, so that all applications have support for it. I'm
not aware of any utility outside of util-linux who reads the lastlog
file for different reasons.
wtmpdb replaces /var/log/wtmp. Applications, who just created wtmp
entries: this code can be disabled, we have now pam_wtmpdb.so to
create common, correct wtmp entries.
Applications who did read wtmp files for whatever reasons need to be
adjusted to use wtmpdb. But again, this don't really exist. Majority
of applications only create the login/logout entries, which is now
handled by the PAM module. The other two cases were runlevel
management of SysVinit and entries for synchronizing the local clock.
runlevel entries are not used by systemd and there is no tool left
which creates entries to synchronize the clock for at least two
decades.
If your application did not read wtmp entries in the past, there is
absolutely no reason to add wtmpdb support. Especially as wtmpdb is
not a replacement for utmp.
utmp: utmp got replaced by systemd-logind. Code which creates utmp
entries can be removed, this is now handled by systemd-logind.
Applications reading utmp need to be adjusted to use libsystemd. There
is no file based access for utmp anymore (ok, not fully correct,
systemd-logind stores the data on disk) and lastlog2 and wtmpdb are no
file based replacements for utmp as what was wrongly claimed in one of
the bug reports. So if your application was using utmp, it needs to
use systemd-logind today and not lastlog2 or wtmpdb.
Now to the bug reports, there are two different things:
1. Looks like w is compiled with libsystemd support, who is not.
Compiling who with libsystemd support should already solve most of the
problems as Chris Hofstaedtler already wrote.
2. fake utmp entries created by terminal applications don't work anymore.
Some terminal applications (e.g. xterm, konsole, ...) create fake utmp
entries for historic reasons: so that broadcast messages are shown in
every single terminal. Which for people, who only work with graphical
applications, but not terminals, is not from help, as they will never
see them.
This is for most users very annoying, that's why the other half does
not create such entries. GNOME e.g. did never create such fake utmp
entries, the claims of some people in that bug reports are wrong. Even
worse: the utmp entries created by GNOME are partly broken, that's why
wall does not work on most GNOME systems which use utmp and not
systemd-logind at all.
The fake utmp entries are no longer created with systemd-logind. For
the majority of people in the discussions and at conferences this was
a plus. KDE e.g. has a daemon, which listens to wall messages and
shows them exactly once in one window. So that even people not using a
terminal get them. But to be honest, I don't know what the state here
is. But at least on openSUSE nobody noticed that the fake utmp entries
are gone, and the majority of who noticed is happy that they are gone.
Future: glibc 2.42 will remove support for utmp and wtmp according to
the current plans. This is the only remaining open issue in openSUSE
with the switch away from utmp and wtmp. Latest with this all
applications should use systemd-logind and wtmpdb as replacement.
> Perhaps whoever has changed the longstanding API (is that Thorsten
> Kukuk, or someone else? anyway I'll cc Thorsten) can chime in with a
> proposed patch to bleeding-edge GNU coreutils. This would probably mean
> a patch to Gnulib's readutmp module, which already is supposed to work
> with systemd's new utmp interfaces but I guess some people are reporting
> problems with it? (This is unclear.)
>
> For what it's worth, I briefly looked at
> <https://build.opensuse.org/package/show/openSUSE%3AFactory/coreutils>
> and didn't see a patch there. So perhaps the problem is already
> addressed in bleeding-edge Coreutils?
The problems were already all solved with the first coreutils versions
having systemd-logind support. Even with all the bug reports I don't
see a need for changes in Coreutils, only in distributions not
enabling systemd-logind support in all packages. Having a mix of
applications using utmp or systemd-logind is not helpful, they all
need to use the same backend.
> Without some actionable advice from experts in this area, I don't see
> this portability issue being fixed any time soon.
>
> For now, I've merged the following GNU Coreutils bug reports as they all
> seem to be the same topic.
>
> https://bugs.gnu.org/73928
> https://bugs.gnu.org/76346
> https://bugs.gnu.org/76347
Yes, see above, all are based on the same two problems.
I hope this helped,
Thoresten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461
Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB
36809, AG Nürnberg)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 07:41:02 GMT)
Full text and
rfc822 format available.
Message #48 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On 2025-02-16 23:03, Thorsten Kukuk wrote:
> The problems were already all solved with the first coreutils versions
> having systemd-logind support. Even with all the bug reports I don't
> see a need for changes in Coreutils, only in distributions not
> enabling systemd-logind support in all packages.
Thanks for the summary. Unfortunately I'm not seeing all the problems
solved, at least not on current Fedora (41) and Ubuntu (24.10).
If I configure current (f2e323430193956709aacca33f6b4fcab4fb9d8b)
Coreutils with --enable-systemd on my Ubuntu 24.10 desktop, the output
gets worse:
$ ./who-no-systemd # Configured normally.
eggert seat0 2025-02-15 10:11 (login screen)
eggert tty2 2025-02-15 10:11 (tty2)
$ ./who-with-systemd # Configured with --enable-systemd.
eggert seat0 2025-02-15 10:11
eggert tty2 2025-02-15 10:11
Apparently for coreutils, /var/run/utmp (the traditional interface) has
more info than libsystemd's API. (For what it's worth, both versions of
"who" consult /var/run/utmp on Ubuntu 24.10, but the systemd version
also consults /run/systemd/sessions/*.)
Similarly, on a Fedora 41 desktop where I'm not currently logged in, I
get inferior results when Coreutils is configured with --enable-systemd:
$ ./who-no-systemd
eggert pts/3 2025-02-16 22:56 (47.147.225.25)
$ ./who-with-systemd
gdm seat0 2025-02-13 18:04
gdm tty1 2025-02-13 18:04
eggert sshd pts/3 2025-02-16 22:56 (47.147.225.25)
Here, though I'm logged in only via ssh, the libsystemd-using 'who'
incorrectly reports that a user named "gdm" is logged in in person.
My guess is that, once systemd was changed to continue to output via the
traditional /var/run/utmp and /var/log/wtmp files, people stopped
configuring coreutils with --enable-systemd and stopped worrying about
making sure that the more-modern systemd API works, which means that the
traditional files are still essential.
I'll add bug-gnulib to the cc list as this may be a Gnulib issue.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 08:13:01 GMT)
Full text and
rfc822 format available.
Message #51 received at 73928 <at> debbugs.gnu.org (full text, mbox):
Paul Eggert wrote:
> If I configure current (f2e323430193956709aacca33f6b4fcab4fb9d8b)
> Coreutils with --enable-systemd on my Ubuntu 24.10 desktop, the output
> gets worse:
>
> $ ./who-no-systemd # Configured normally.
> eggert seat0 2025-02-15 10:11 (login screen)
> eggert tty2 2025-02-15 10:11 (tty2)
> $ ./who-with-systemd # Configured with --enable-systemd.
> eggert seat0 2025-02-15 10:11
> eggert tty2 2025-02-15 10:11
>
> Apparently for coreutils, /var/run/utmp (the traditional interface) has
> more info than libsystemd's API.
Both outputs are equivalent; the second one is less redundant.
- The comment "(tty2)" is redundant because it's already the tty.
- The comment "(login screen)" is redundant because that's the
concept of a "seat".
> Similarly, on a Fedora 41 desktop where I'm not currently logged in, I
> get inferior results when Coreutils is configured with --enable-systemd:
>
> $ ./who-no-systemd
> eggert pts/3 2025-02-16 22:56 (47.147.225.25)
> $ ./who-with-systemd
> gdm seat0 2025-02-13 18:04
> gdm tty1 2025-02-13 18:04
> eggert sshd pts/3 2025-02-16 22:56 (47.147.225.25)
>
> Here, though I'm logged in only via ssh, the libsystemd-using 'who'
> incorrectly reports that a user named "gdm" is logged in in person.
'who' merely reports the info it got from systemd-logind, and systemd-logind
most probably got a notification from gdm.
I agree with you that this _looks_like_ as if a user named 'gdm' was logged
in, and thus is misleading. But I don't think this should be fixed in
coreutils. Rather, this is something to work out between systemd-logind
and gdm.
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 08:23:01 GMT)
Full text and
rfc822 format available.
Message #54 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 17, 2025 at 8:40 AM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
>
> On 2025-02-16 23:03, Thorsten Kukuk wrote:
> > The problems were already all solved with the first coreutils versions
> > having systemd-logind support. Even with all the bug reports I don't
> > see a need for changes in Coreutils, only in distributions not
> > enabling systemd-logind support in all packages.
>
> Thanks for the summary. Unfortunately I'm not seeing all the problems
> solved, at least not on current Fedora (41) and Ubuntu (24.10).
>
> If I configure current (f2e323430193956709aacca33f6b4fcab4fb9d8b)
> Coreutils with --enable-systemd on my Ubuntu 24.10 desktop, the output
> gets worse:
>
> $ ./who-no-systemd # Configured normally.
> eggert seat0 2025-02-15 10:11 (login screen)
> eggert tty2 2025-02-15 10:11 (tty2)
> $ ./who-with-systemd # Configured with --enable-systemd.
> eggert seat0 2025-02-15 10:11
> eggert tty2 2025-02-15 10:11
>
> Apparently for coreutils, /var/run/utmp (the traditional interface) has
> more info than libsystemd's API. (For what it's worth, both versions of
> "who" consult /var/run/utmp on Ubuntu 24.10, but the systemd version
> also consults /run/systemd/sessions/*.)
systemd-logind provides the same info as utmp does, I made sure that
this is the case and available:
https://github.com/thkukuk/utmpx/blob/main/utmp-to-logind.md
And who (with --enable-systemd with no /run/utmp on openSUSE Tumbleweed):
On a server:
kukuk pts/3 2025-02-12 11:20 (192.168.122.1)
kukuk pts/0 2025-02-11 12:00 (192.168.122.1)
kukuk pts/1 2025-02-11 14:26 (192.168.122.1)
On my local machine with KDE:
kukuk seat0 2025-02-11 15:58 (:0)
kukuk tty2 2025-02-11 15:58 (:0)
root pts/2 2025-02-15 18:32
No idea why this is not working for you. On openSUSE we have no
additional patches which are not upstream.
Maybe that systemd version is too old on that systems?
> Similarly, on a Fedora 41 desktop where I'm not currently logged in, I
> get inferior results when Coreutils is configured with --enable-systemd:
>
> $ ./who-no-systemd
> eggert pts/3 2025-02-16 22:56 (47.147.225.25)
> $ ./who-with-systemd
> gdm seat0 2025-02-13 18:04
> gdm tty1 2025-02-13 18:04
> eggert sshd pts/3 2025-02-16 22:56 (47.147.225.25)
>
> Here, though I'm logged in only via ssh, the libsystemd-using 'who'
> incorrectly reports that a user named "gdm" is logged in in person.
>
> My guess is that, once systemd was changed to continue to output via the
> traditional /var/run/utmp and /var/log/wtmp files, people stopped
> configuring coreutils with --enable-systemd and stopped worrying about
> making sure that the more-modern systemd API works, which means that the
> traditional files are still essential.
systemd only writes the boot time, nothing else.
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461
Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB
36809, AG Nürnberg)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 08:44:02 GMT)
Full text and
rfc822 format available.
Message #57 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On 2025-02-17 00:12, Bruno Haible wrote:
> Paul Eggert wrote:
>> $ ./who-no-systemd # Configured normally.
>> eggert seat0 2025-02-15 10:11 (login screen)
>> eggert tty2 2025-02-15 10:11 (tty2)
>> $ ./who-with-systemd # Configured with --enable-systemd.
>> eggert seat0 2025-02-15 10:11
>> eggert tty2 2025-02-15 10:11
>>
>> Apparently for coreutils, /var/run/utmp (the traditional interface) has
>> more info than libsystemd's API.
>
> Both outputs are equivalent; the second one is less redundant.
In that case, should we fix Gnulib and/or Coreutils so that the first
output is changed to match the second one?
>> $ ./who-no-systemd
>> eggert pts/3 2025-02-16 22:56 (47.147.225.25)
>> $ ./who-with-systemd
>> gdm seat0 2025-02-13 18:04
>> gdm tty1 2025-02-13 18:04
>> eggert sshd pts/3 2025-02-16 22:56 (47.147.225.25)
>>
>> Here, though I'm logged in only via ssh, the libsystemd-using 'who'
>> incorrectly reports that a user named "gdm" is logged in in person.
>
> 'who' merely reports the info it got from systemd-logind, and systemd-logind
> most probably got a notification from gdm.
>
> I agree with you that this _looks_like_ as if a user named 'gdm' was logged
> in, and thus is misleading. But I don't think this should be fixed in
> coreutils. Rather, this is something to work out between systemd-logind
> and gdm.
OK, but until that's worked out it appears to be better to not use
--enable-systemd on Fedora when configuring Coreutils. Likewise for
Ubuntu which has the same issue, and I assume Debian is like Ubuntu.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 09:09:02 GMT)
Full text and
rfc822 format available.
Message #60 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On 2025-02-17 00:22, Thorsten Kukuk wrote:
> Maybe that systemd version is too old on that systems?
The systemd versions are reasonably recent. Fedora 41 has systemd 256.11
(2025-01-08) and Ubuntu 24.10 has systemd 256.5 (2024-08-31). Here are
the details:
On Fedora 41, "systemctl --version" reports:
systemd 256 (256.11-1.fc41)
+PAM +AUDIT +SELINUX -APPARMOR +IMA +SMACK +SECCOMP -GCRYPT +GNUTLS
+OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN -IPTC +KMOD
+LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY
+P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK
+XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE
On Ubuntu 24.10, the same command reports:
systemd 256 (256.5-2ubuntu3.1)
+PAM +AUDIT +SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS
+OPENSSL +ACL +BLKID +CURL +ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD
+LIBCRYPTSETUP +LIBCRYPTSETUP_PLUGINS +LIBFDISK +PCRE2 +PWQUALITY
+P11KIT +QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD +BPF_FRAMEWORK
-XKBCOMMON +UTMP +SYSVINIT +LIBARCHIVE
> systemd only writes the boot time, nothing else.
Is it that simple? systemd/src/core/exec-invoke.c's exec_invoke seems to
do more than that if ENABLE_UTMP is defined.
Even if it's that simple, something is updating the traditional
/var/run/utmp and /var/log/wtmp files on Fedora and Ubuntu and at least
in some cases they work better than systemd does and this should be
fixed somehow.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 09:26:02 GMT)
Full text and
rfc822 format available.
Message #63 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On 2025-02-17 08:03:23 +0100, Thorsten Kukuk wrote:
> Some terminal applications (e.g. xterm, konsole, ...) create fake utmp
> entries for historic reasons: so that broadcast messages are shown in
> every single terminal. Which for people, who only work with graphical
> applications, but not terminals, is not from help, as they will never
> see them.
No, there may be other uses. For instance, "who -d" reports
information about dead terminal processes. Obviously, this is
not for broadcast messages (more for debugging purpose, IMHO).
However, for xterm at least, the output information is incorrect
(term & exit values are always 0).
"who -u" also reports useful information, such as the idle time
and the PID of the terminal process. The absence of utmp completely
breaks this feature.
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 09:29:02 GMT)
Full text and
rfc822 format available.
Message #66 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 17, 2025 at 10:08 AM Paul Eggert <eggert <at> cs.ucla.edu> wrote:
> Even if it's that simple, something is updating the traditional
> /var/run/utmp and /var/log/wtmp files on Fedora and Ubuntu and at least
> in some cases they work better than systemd does and this should be
> fixed somehow.
Applications are doing that via glibc. But this will go away with
glibc 2.42, when this functions don't do anything anymore.
And this will not happen if distributions don't create /run/utmp on
boot. glibc only writes to this files if they exist, it will not
create them.
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461
Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB
36809, AG Nürnberg)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 09:40:02 GMT)
Full text and
rfc822 format available.
Message #69 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On Mon, Feb 17, 2025 at 10:25 AM Vincent Lefevre <vincent <at> vinc17.net> wrote:
>
> On 2025-02-17 08:03:23 +0100, Thorsten Kukuk wrote:
> > Some terminal applications (e.g. xterm, konsole, ...) create fake utmp
> > entries for historic reasons: so that broadcast messages are shown in
> > every single terminal. Which for people, who only work with graphical
> > applications, but not terminals, is not from help, as they will never
> > see them.
>
> No, there may be other uses. For instance, "who -d" reports
> information about dead terminal processes. Obviously, this is
> not for broadcast messages (more for debugging purpose, IMHO).
> However, for xterm at least, the output information is incorrect
> (term & exit values are always 0).
"who -d" shows which login processes exit without removing the utmp
entry and where the init process cleaned up the utmp entry instead.
Since no terminal is controlled by an init process, you should never
see any terminal listed. So I have my doubts that you ever saw there
terminal processes. And if yes, something was terrible broken with
your init and login process.
And "who -d" will only show these entries if no other process was
quicker and recycled that entry already. I think you can implement
that with systemd, too, if a process quits without telling that
systemd-logind. And that would be even more exact, as it wouldn't be
overwritten by the next process. But nobody asked for that until now.
> "who -u" also reports useful information, such as the idle time
> and the PID of the terminal process. The absence of utmp completely
> breaks this feature.
Yes, and this feature never worked reliably if I look at all the old
bug reports for openSUSE.
This "feature" is very terminal centric and stopped already working
when people decided to use graphical applications and not terminals.
It's the old question: what does idle mean in this context?
Thorsten
--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461
Nuernberg, Germany
Managing Director: Ivo Totev, Andrew McDonald, Werner Knoblich (HRB
36809, AG Nürnberg)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 11:27:02 GMT)
Full text and
rfc822 format available.
Message #72 received at 73928 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Paul Eggert <eggert <at> cs.ucla.edu> writes:
>> 'who' merely reports the info it got from systemd-logind, and systemd-logind
>> most probably got a notification from gdm.
>> I agree with you that this _looks_like_ as if a user named 'gdm' was logged
>> in, and thus is misleading. But I don't think this should be fixed in
>> coreutils. Rather, this is something to work out between systemd-logind
>> and gdm.
>
> OK, but until that's worked out it appears to be better to not use
> --enable-systemd on Fedora when configuring Coreutils. Likewise for Ubuntu
> which has the same issue, and I assume Debian is like Ubuntu.
This is correct, though, there is a session for the user 'gdm', and
they're taking up tty1. If you walk up to that computer (you said you
were using SSH, so I assume you're remote), you'll see GDM running on
the screen (on one of the virtual TTYs).
--
Arsen Arsenović
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 11:51:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 73928 <at> debbugs.gnu.org (full text, mbox):
Arsen Arsenović wrote:
> >> I agree with you that this _looks_like_ as if a user named 'gdm' was logged
> >> in, and thus is misleading. But I don't think this should be fixed in
> >> coreutils. Rather, this is something to work out between systemd-logind
> >> and gdm.
> >
> > OK, but until that's worked out it appears to be better to not use
> > --enable-systemd on Fedora when configuring Coreutils. Likewise for Ubuntu
> > which has the same issue, and I assume Debian is like Ubuntu.
>
> This is correct, though, there is a session for the user 'gdm', and
> they're taking up tty1. If you walk up to that computer (you said you
> were using SSH, so I assume you're remote), you'll see GDM running on
> the screen (on one of the virtual TTYs).
If Giovanni De Micheli has an account on this computer, who's output
is ambiguous: you cannot tell whether the real user 'gdm' or the GNOME
display manager is occupying the "seat". I would suggest that, at least,
the GNOME display manager identifies itself as "(gdm)" instead of "gdm".
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Mon, 17 Feb 2025 12:10:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On 2025-02-17 10:39:09 +0100, Thorsten Kukuk wrote:
> "who -d" shows which login processes exit without removing the utmp
> entry and where the init process cleaned up the utmp entry instead.
> Since no terminal is controlled by an init process, you should never
> see any terminal listed. So I have my doubts that you ever saw there
> terminal processes. And if yes, something was terrible broken with
> your init and login process.
This is shown at least for xterm processes that have terminated
and for closed SSH sessions.
> > "who -u" also reports useful information, such as the idle time
> > and the PID of the terminal process. The absence of utmp completely
> > breaks this feature.
>
> Yes, and this feature never worked reliably if I look at all the old
> bug reports for openSUSE.
It seems to be reliable for xterm and SSH sessions (not for GNU Screen
unfortunately).
> This "feature" is very terminal centric and stopped already working
> when people decided to use graphical applications and not terminals.
But the goal is to use this for terminals only.
--
Vincent Lefèvre <vincent <at> vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Wed, 19 Feb 2025 11:27:02 GMT)
Full text and
rfc822 format available.
Message #81 received at 73928 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Bruno Haible <bruno <at> clisp.org> writes:
> Arsen Arsenović wrote:
>> This is correct, though, there is a session for the user 'gdm', and
>> they're taking up tty1. If you walk up to that computer (you said you
>> were using SSH, so I assume you're remote), you'll see GDM running on
>> the screen (on one of the virtual TTYs).
>
> If Giovanni De Micheli has an account on this computer, who's output
> is ambiguous: you cannot tell whether the real user 'gdm' or the GNOME
> display manager is occupying the "seat". I would suggest that, at least,
> the GNOME display manager identifies itself as "(gdm)" instead of "gdm".
Sure, but one cannot name two users on a Unix system 'gdm', and there is
a passwd entry for 'gdm', so that scenario is impossible (save for
administrative errors):
arsen <at> fedora:~$ grep gdm /etc/passwd
gdm:x:42:42:GNOME Display Manager:/var/lib/gdm:/usr/sbin/nologin
arsen <at> fedora:~$ useradd gdm
useradd: user 'gdm' already exists
Presumably Giovanni might pick 'giovannidm' or 'gdmicheli' or such
instead.
The case for or against there being a user called 'gdm' when one
installs a Fedora system is one best presented to the Fedora hackers,
though, as it does not impact the correctness of the result above.
--
Arsen Arsenović
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Wed, 19 Feb 2025 14:21:02 GMT)
Full text and
rfc822 format available.
Message #84 received at 73928 <at> debbugs.gnu.org (full text, mbox):
Arsen Arsenović wrote:
> Sure, but one cannot name two users on a Unix system 'gdm', and there is
> a passwd entry for 'gdm', so that scenario is impossible (save for
> administrative errors):
>
> arsen <at> fedora:~$ grep gdm /etc/passwd
> gdm:x:42:42:GNOME Display Manager:/var/lib/gdm:/usr/sbin/nologin
> arsen <at> fedora:~$ useradd gdm
> useradd: user 'gdm' already exists
>
> Presumably Giovanni might pick 'giovannidm' or 'gdmicheli' or such
> instead.
OK. I withdraw my assessment that who's output was misleading. Paul,
do you still have a problem with this?
$ ./who-with-systemd
gdm seat0 2025-02-13 18:04
gdm tty1 2025-02-13 18:04
eggert sshd pts/3 2025-02-16 22:56 (47.147.225.25)
Bruno
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Wed, 19 Feb 2025 17:15:01 GMT)
Full text and
rfc822 format available.
Message #87 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On 2025-02-19 03:26, Arsen Arsenović wrote:
> The case for or against there being a user called 'gdm' when one
> installs a Fedora system is one best presented to the Fedora hackers
It's not just Fedora, it's also Ubuntu. Both systems have pseudousers
named "gdm" that cannot log in (their login shell is /bin/false or
/sbin/nologin), but which "who" would report with systemd. I assume
other distros have similar problem.
A simple fix is for "who" to silently filter out anybody named "gdm".
(Sorry, Giovanni.)
Is there a better way to distinguish real logins from fake ones?
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Wed, 19 Feb 2025 17:42:01 GMT)
Full text and
rfc822 format available.
Message #90 received at 73928 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Paul Eggert <eggert <at> cs.ucla.edu> writes:
> On 2025-02-19 03:26, Arsen Arsenović wrote:
>> The case for or against there being a user called 'gdm' when one
>> installs a Fedora system is one best presented to the Fedora hackers
>
> It's not just Fedora, it's also Ubuntu. Both systems have pseudousers named
> "gdm" that cannot log in (their login shell is /bin/false or /sbin/nologin),
> but which "who" would report with systemd. I assume other distros have similar
> problem.
>
> A simple fix is for "who" to silently filter out anybody named "gdm". (Sorry,
> Giovanni.)
>
> Is there a better way to distinguish real logins from fake ones?
I see these as real: they (gdm) are a user and they have a session.
Adding additional filtration can only confuse admins who compare 'who'
and other tools.
--
Arsen Arsenović
[signature.asc (application/pgp-signature, inline)]
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Wed, 19 Feb 2025 20:48:02 GMT)
Full text and
rfc822 format available.
Message #93 received at 73928 <at> debbugs.gnu.org (full text, mbox):
On 2/19/25 09:41, Arsen Arsenović wrote:
> they (gdm) are a user and they have a session.
> Adding additional filtration can only confuse admins who compare 'who'
> and other tools.
It is exactly that confusion that I'm trying to prevent.
The man page for "who" says "who - show who is logged on", but gdm is
not logged on.
The POSIX spec for "who" says that "who" optionally reports the login
time, but there is no login time here because nobody has logged in. The
POSIX spec also says that "who -l" should list only lines where the
system is waiting for someone to login - which is what's happening with
the gdm display - and yet who with libsystemd doesn't do that.
It's a stretch to say that gdm is a "user" in the sense that most people
understand "who". By default, "who" is supposed to list users who have
logged in, not random UIDs like daemon or systemd-resolve or gdm that
cannot log in.
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Wed, 19 Feb 2025 21:42:02 GMT)
Full text and
rfc822 format available.
Message #96 received at 73928 <at> debbugs.gnu.org (full text, mbox):
* Paul Eggert <eggert <at> cs.ucla.edu> [250219 21:47]:
> On 2/19/25 09:41, Arsen Arsenović wrote:
> > they (gdm) are a user and they have a session.
> > Adding additional filtration can only confuse admins who compare 'who'
> > and other tools.
>
> It is exactly that confusion that I'm trying to prevent.
>
> The man page for "who" says "who - show who is logged on", but gdm is not
> logged on.
>
> The POSIX spec for "who" says that "who" optionally reports the login time,
> but there is no login time here because nobody has logged in. The POSIX spec
> also says that "who -l" should list only lines where the system is waiting
> for someone to login - which is what's happening with the gdm display - and
> yet who with libsystemd doesn't do that.
>
> It's a stretch to say that gdm is a "user" in the sense that most people
> understand "who". By default, "who" is supposed to list users who have
> logged in, not random UIDs like daemon or systemd-resolve or gdm that cannot
> log in.
I don't really know my way around the sd-logind API, but it looks
like filtering on the session class (returned by sd_session_get_class)
might be fruitful.
pam_systemd(8) has an explanation on the classes.
I would probably filter out these: greeter, lock-screen, manager,
manager-early. Looking at the "pam_issue" implementation, it only
counts sessions with a class matching user* as logged in users.
Chris
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Wed, 19 Feb 2025 21:53:02 GMT)
Full text and
rfc822 format available.
Message #99 received at 73928 <at> debbugs.gnu.org (full text, mbox):
* Chris Hofstaedtler <zeha <at> debian.org> [250219 22:41]:
> > The man page for "who" says "who - show who is logged on", but gdm is not
> > logged on.
[..]
> I don't really know my way around the sd-logind API, but it looks
> like filtering on the session class (returned by sd_session_get_class)
> might be fruitful.
This procps commit appears relevant:
https://github.com/warmchang/procps/commit/734930e4766860b7e57f0a3ae7d7f908f5d56153
Chris
Information forwarded
to
bug-coreutils <at> gnu.org:
bug#73928; Package
coreutils.
(Wed, 19 Feb 2025 22:53:02 GMT)
Full text and
rfc822 format available.
Message #102 received at 73928 <at> debbugs.gnu.org (full text, mbox):
Chris Hofstaedtler wrote:
> I don't really know my way around the sd-logind API, but it looks
> like filtering on the session class (returned by sd_session_get_class)
> might be fruitful.
>
> pam_systemd(8) has an explanation on the classes.
Thanks for the hint. Let me try this commit to gnulib. Paul, does it
work for you (after installing package 'systemd-devel' and rebuilding
coreutils with --enable-systemd)?
2025-02-19 Bruno Haible <bruno <at> clisp.org>
readutmp: Let callers distinguish LOGINs from USERs.
Reported by Paul Eggert in
<https://lists.gnu.org/archive/html/bug-gnulib/2025-02/msg00123.html>.
* lib/readutmp.h (LOGIN_PROCESS, UT_TYPE_LOGIN_PROCESS): New macros.
* lib/readutmp.c (read_utmp_from_systemd): Possibly use LOGIN_PROCESS
instead of USER_PROCESS, depending on the session's class.
diff --git a/lib/readutmp.c b/lib/readutmp.c
index c5b6b3655b..9366dfa5c2 100644
--- a/lib/readutmp.c
+++ b/lib/readutmp.c
@@ -877,8 +877,8 @@ read_utmp_from_systemd (idx_t *n_entries, STRUCT_UTMP **utmp_buf, int options)
}
}
- /* Create up to two USER_PROCESS entries: one for the seat,
- one for the tty. */
+ /* Create up to two USER_PROCESS or LOGIN_PROCESS entries:
+ one for the seat, one for the tty. */
if (seat != NULL || tty != NULL)
{
char *user;
@@ -889,6 +889,13 @@ read_utmp_from_systemd (idx_t *n_entries, STRUCT_UTMP **utmp_buf, int options)
if (sd_session_get_leader (session, &leader_pid) < 0)
leader_pid = 0;
+ char *clasz;
+ if (sd_session_get_class (session, &clasz) < 0)
+ clasz = missing;
+ short ctype =
+ (strncmp (clasz, "manager", 7) == 0 ? LOGIN_PROCESS :
+ USER_PROCESS);
+
char *host;
char *remote_host;
if (sd_session_get_remote_host (session, &remote_host) < 0)
@@ -932,7 +939,7 @@ read_utmp_from_systemd (idx_t *n_entries, STRUCT_UTMP **utmp_buf, int options)
seat, strlen (seat),
host, strlen (host),
leader_pid /* the best we have */,
- USER_PROCESS, start_ts, leader_pid, 0, 0);
+ ctype, start_ts, leader_pid, 0, 0);
if (tty != NULL)
a = add_utmp (a, options,
user, strlen (user),
@@ -940,10 +947,12 @@ read_utmp_from_systemd (idx_t *n_entries, STRUCT_UTMP **utmp_buf, int options)
tty, strlen (tty),
host, strlen (host),
leader_pid /* the best we have */,
- USER_PROCESS, start_ts, leader_pid, 0, 0);
+ ctype, start_ts, leader_pid, 0, 0);
if (host != missing)
free (host);
+ if (clasz != missing)
+ free (clasz);
if (user != missing)
free (user);
}
diff --git a/lib/readutmp.h b/lib/readutmp.h
index b5e8133c7c..60d63df959 100644
--- a/lib/readutmp.h
+++ b/lib/readutmp.h
@@ -45,7 +45,7 @@
# include <utmp.h>
#endif
-/* Needed for BOOT_TIME and USER_PROCESS. */
+/* Needed for BOOT_TIME, USER_PROCESS, LOGIN_PROCESS. */
#if HAVE_UTMPX_H
# if defined _THREAD_SAFE && defined UTMP_DATA_INIT
/* When including both utmp.h and utmpx.h on AIX 4.3, with _THREAD_SAFE
@@ -74,7 +74,8 @@ struct gl_utmp
struct timespec ut_ts; /* time */
pid_t ut_pid; /* process ID of ? */
pid_t ut_session; /* process ID of session leader */
- short ut_type; /* BOOT_TIME, USER_PROCESS, or other */
+ short ut_type; /* BOOT_TIME, USER_PROCESS, LOGIN_PROCESS,
+ or other */
struct { int e_termination; int e_exit; } ut_exit;
};
@@ -257,19 +258,21 @@ struct utmpx32
# define WTMP_FILE "/etc/wtmp"
#endif
-/* In early versions of Android, <utmp.h> did not define BOOT_TIME, only
- USER_PROCESS. We need to use the value that is defined in newer versions
- of Android. */
+/* In early versions of Android, <utmp.h> did not define BOOT_TIME or
+ LOGIN_PROCESS, only USER_PROCESS. We need to use the value that is defined
+ in newer versions of Android. */
#if defined __ANDROID__ && !defined BOOT_TIME
# define BOOT_TIME 2
+# define LOGIN_PROCESS 6
#endif
/* Some platforms, such as OpenBSD, don't have an ut_type field and don't have
- the BOOT_TIME and USER_PROCESS macros. But we want to support them in
- 'struct gl_utmp'. */
+ the BOOT_TIME, USER_PROCESS, and LOGIN_PROCESS macros. But we want to
+ support them in 'struct gl_utmp'. */
#if !(HAVE_UTMPX_H ? HAVE_STRUCT_UTMPX_UT_TYPE : HAVE_STRUCT_UTMP_UT_TYPE)
# define BOOT_TIME 2
# define USER_PROCESS 0
+# define LOGIN_PROCESS 6
#endif
/* Macros that test (UT)->ut_type. */
@@ -283,6 +286,11 @@ struct utmpx32
#else
# define UT_TYPE_USER_PROCESS(UT) 0
#endif
+#ifdef LOGIN_PROCESS
+# define UT_TYPE_LOGIN_PROCESS(UT) ((UT)->ut_type == LOGIN_PROCESS)
+#else
+# define UT_TYPE_LOGIN_PROCESS(UT) 0
+#endif
/* Determines whether an entry *UT corresponds to a user process. */
#define IS_USER_PROCESS(UT) \
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 20 Mar 2025 11:24:07 GMT)
Full text and
rfc822 format available.
This bug report was last modified 92 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.