`users` and `who`: need to check the user's login shell is alive

[jtracey]

While debugging tests for a pinky PR (#3155), I saw some inconsistent behavior between GNU's users and who utils vs. ours. The PR adds a fake entry to the system's utmp file, since the GitHub CI runner doesn't log in to any accounts, so pinky wasn't displaying anything during testing and letting bugs slip through. Once that was working, our versions of users and who started displaying the runner from the fake entry, but GNU's still does not. I ran strace on them on my local system, and noticed that the GNU versions call kill($PID, 0), where $PID is the PID of the login shell associated with that user. I suspect that the GNU versions aren't taking utmp at its word, and are checking the return value of this kill() call to double check that the user from the login entry is still running a login shell. The fake entry added in #3155 gives a fake, very high (and therefore unlikely to be used in the span of a GH CI run) PID, so the check fails for GNU, but looks fine to ours.

To fix this, we need to:

• make users check the login PID is still running
• make who check the login PID is still running
• re-enable any disabled tests from pinky: fix off-by-one in GECOS parsing #3155
• add an additional fake utmp entry with PID 1 (i.e., a PID that should always exist)

The last step, adding the additional utmp entry, is necessary because without it, users and who are suffering from the same problem pinky was (no command output = behavior is mostly untested), but we can't just change the existing one lest this bug return.

[pawelngei]

Could we resolve this category of testing bugs by running both GNU tests and Rust tests in a Docker container fully specified by us? The CI runner could build the image (with caching) and run it within the action.

[original-birdman]

FWIW, Ubuntu no longer has a utmp file at all.

It went away at 25.04. e.g. for "who -b" GNU who looks at the timestamp on /var/lib/systemd/random-seed after it fails to find /var/run/utmp.

So GNU who gives:

[gmllaptop]: gnuwho -b
         system boot  2025-11-16 21:54
[gmllaptop]: 

whereas uutils who gives:

[gmllaptop]: who -b
[gmllaptop]: 

[ChrisDryden]

I know it's a 4 year old bug but @jtracey i was hoping I could get your take on whether this PR #9442 fully resolves the issues you are describing.

[jtracey]

@original-birdman: Since this issue is about these commands returning values they shouldn't, and that bug is about not returning values they should, I'd say it should be filed as a new bug.

[original-birdman]

@original-birdman: Since this issue is about these commands returning values they shouldn't, and that bug is about not returning values they should, I'd say it should be filed as a new bug.

The discussion of this issue seems to start with the concept of adding a fake entry to the utmp file.
Hence my comment that on Ubuntu systems this year (and hence the next LTS) there is no utmp file, so that's not really a solution.

But yes, the entire concept of using the utmp file needs to raised as a separate issue. procps seems to have a few solutions.