Re: Bullseye - who and users return nothing
On Tue 25 Jan 2022, at 01:31, Gareth Evans <donotspam@fastmail.fm> wrote:
> On Mon 24 Jan 2022, at 12:45, Greg Wooledge <greg@wooledge.org> wrote:
>> On Mon, Jan 24, 2022 at 09:51:05AM +0000, Gareth Evans wrote:
>>> I've just noticed that:
>>>
>>> $ who
>>>
>>> and
>>>
>>> $ users
>>>
>>> both return nothing, with or without sudo.
>>
>>> Can anyone replicate this or suggest what may have happened? I'm fairly sure I've used who since upgrading from Buster.
>>
>> Definitely can't replicate. "who" gives me 28 lines of output for all
>> of my terminals.
>>
>> As far as suggesting a cause -- we'd need more info.
>
>> Which init system
>> are you using?
>
> systemd. But for root on ZFS per
>
> https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html
> (adjusted for Bullseye)
>
> it's standard Debian-mate amd64
>
>> How are you logging in?
>
> Logging into Mate with lightdm
>
>> Are you using any terminal
>> emulators, and if so, which one(s)?
>
> mate-terminal
>
>>
>> Is the /var file system full? (Or any mount underneath /var if you have
>> such.)
>
> $ sudo zfs list
> NAME USED AVAIL REFER MOUNTPOINT
> bpool 172M 660M 96K /boot
> bpool/BOOT 170M 660M 96K none
> bpool/BOOT/debian 170M 660M 170M /boot
> rpool 67.6G 45.7G 192K /
> rpool/ROOT 11.2G 45.7G 192K none
> rpool/ROOT/debian 11.2G 45.7G 11.2G /
> rpool/data 200K 45.7G 200K /data
> rpool/home 15.0G 45.7G 9.27G /home
> rpool/large 3.06G 45.7G 3.06G /large
> rpool/backup1 4.94G 45.7G 1.03G /backup1
> rpool/backup2 15.7G 45.7G 3.94G /backup2
> rpool/swap 8.50G 54.2G 108K -
> rpool/var 9.06G 45.7G 412K /var
> rpool/var/cache 192M 45.7G 192M /var/cache
> rpool/var/lib 6.29G 45.7G 720K /var/lib
> rpool/var/lib/docker 19.0M 45.7G 19.0M /var/lib/docker
> rpool/var/lib/libvirt 5.94G 45.7G 5.94G /var/lib/libvirt
> rpool/var/lib/mysql 335M 45.7G 246M /var/lib/mysql
> rpool/var/log 363M 45.7G 363M /var/log
> rpool/var/spool 103M 45.7G 103M /var/spool
> rpool/var/tmp 250M 45.7G 250M /var/tmp
> rpool/var/www 1.89G 45.7G 1.40G /var/www
>
>
>> Have you done anything unique or unusual to your system that would cause
>> it not to log sessions in /var/run/utmp?
>
> Not afaik
>
>>
>>> $ sudo strace who
>>> <snip>
>>> access("/var/run/utmpx", F_OK) = -1 ENOENT (No such file or directory)
>>> openat(AT_FDCWD, "/var/run/utmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>>> access("/var/run/utmpx", F_OK) = -1 ENOENT (No such file or directory)
>>> openat(AT_FDCWD, "/var/run/utmp", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
>>> close(1) = 0
>>> close(2) = 0
>>> exit_group(0) = ?
>>> +++ exited with 0 +++
>>
>> Your /var/run/utmp file is missing. That's definitely going to cause
>> a problem here.
>>
>> Here's what mine looks like:
>>
>> unicorn:~$ df /var/run
>> Filesystem 1K-blocks Used Available Use% Mounted on
>> tmpfs 1215580 1456 1214124 1% /run
>> unicorn:~$ ls -ld /var/run
>> lrwxrwxrwx 1 root root 4 Jan 11 2018 /var/run -> /run/
>> unicorn:~$ ls -l /var/run/utmp
>> -rw-rw-r-- 1 root utmp 12288 Jan 20 15:08 /var/run/utmp
>>
>> I don't know what happened to yours, but since /run is an in-memory
>> file system, all of the stuff inside it (including the utmp file) has
>> to be created at boot time, or at login time at the very latest.
>>
>
>> You could try creating the file with the correct user/group/perms and
>> see if that helps, but that probably won't survive the next reboot.
>
> /var/run$ sudo touch utmp
> /var/run$ sudo chown root:utmp utmp
> /var/run$ sudo chmod 664 utmp
> /var/run$ ls -l utmp
> -rw-rw-r-- 1 root utmp 0 Jan 25 00:08 utmp
> /var/run$ who
> /var/run$
> [logout, login]
> /var/run$ ls -l /var/run/utmp
> -rw-rw-r-- 1 root utmp 384 Jan 25 00:17 /var/run/utmp
> $ who
> user tty7 2022-01-25 00:17 (:0)
> $ sudo reboot
> ...
> $ ls -l /var/run/utmp
> ls: cannot access '/var/run/utmp': No such file or directory
>
>>
>> You could also try rebooting and see if it gets created correctly. If
>> it doesn't, then I guess you get to dive into the internals of your
>> init system to discover what's going wrong.
>>
>
> user@qwerty:~$ sudo service systemd-update-utmp status
> ● systemd-update-utmp.service - Update UTMP about System Boot/Shutdown
> Loaded: loaded (/lib/systemd/system/systemd-update-utmp.service;
> static)
> Active: active (exited) since Tue 2022-01-25 01:13:05 GMT; 1min
> 49s ago
> Docs: man:systemd-update-utmp.service(8)
> man:utmp(5)
> Process: 1375 ExecStart=/lib/systemd/systemd-update-utmp reboot
> (code=exited, status=0/SUCCESS)
> Main PID: 1375 (code=exited, status=0/SUCCESS)
> CPU: 9ms
>
> Jan 25 01:13:05 qwerty systemd[1]: Starting Update UTMP about System
> Boot/Shutdown...
> Jan 25 01:13:05 qwerty systemd[1]: Finished Update UTMP about System
> Boot/Shutdown.
>
> user@qwerty:~$ sudo grep -i utmp /var/log/daemon.log
> Jan 24 08:59:27 qwerty systemd[1]: Starting Update UTMP about System
> Boot/Shutdown...
> Jan 24 08:59:27 qwerty systemd[1]: Finished Update UTMP about System
> Boot/Shutdown.
> Jan 24 08:59:35 qwerty lightdm[2594]: Failed to write utmpx: No such
> file or directory
> Jan 24 08:59:36 qwerty systemd[1]: Starting Update UTMP about System
> Runlevel Changes...
> Jan 24 08:59:36 qwerty systemd[1]:
> systemd-update-utmp-runlevel.service: Succeeded.
> Jan 24 08:59:36 qwerty systemd[1]: Finished Update UTMP about System
> Runlevel Changes.
> Jan 24 09:32:17 qwerty systemd[1]: Starting Update UTMP about System
> Boot/Shutdown...
> Jan 24 09:32:17 qwerty systemd[1]: Finished Update UTMP about System
> Boot/Shutdown.
> Jan 24 09:32:27 qwerty lightdm[2561]: Failed to write utmpx: No such
> file or directory
> Jan 24 09:32:27 qwerty systemd[1]: Starting Update UTMP about System
> Runlevel Changes...
> Jan 24 09:32:27 qwerty systemd[1]:
> systemd-update-utmp-runlevel.service: Succeeded.
> Jan 24 09:32:27 qwerty systemd[1]: Finished Update UTMP about System
> Runlevel Changes.
> Jan 24 23:46:28 qwerty systemd[1]: Starting Update UTMP about System
> Boot/Shutdown...
> Jan 24 23:46:28 qwerty systemd[1]: Finished Update UTMP about System
> Boot/Shutdown.
> Jan 24 23:46:38 qwerty systemd[1]: Starting Update UTMP about System
> Runlevel Changes...
> Jan 24 23:46:38 qwerty systemd[1]:
> systemd-update-utmp-runlevel.service: Succeeded.
> Jan 24 23:46:38 qwerty systemd[1]: Finished Update UTMP about System
> Runlevel Changes.
> Jan 24 23:46:38 qwerty lightdm[2890]: Failed to write utmpx: No such
> file or directory
> Jan 25 00:15:24 qwerty systemd[1]: Starting Update UTMP about System
> Boot/Shutdown...
> Jan 25 00:15:24 qwerty systemd[1]: Finished Update UTMP about System
> Boot/Shutdown.
> Jan 25 00:15:32 qwerty lightdm[2642]: Failed to write utmpx: No such
> file or directory
> Jan 25 00:15:33 qwerty systemd[1]: Starting Update UTMP about System
> Runlevel Changes...
> Jan 25 00:15:33 qwerty systemd[1]:
> systemd-update-utmp-runlevel.service: Succeeded.
> Jan 25 00:15:33 qwerty systemd[1]: Finished Update UTMP about System
> Runlevel Changes.
> Jan 25 01:13:05 qwerty systemd[1]: Starting Update UTMP about System
> Boot/Shutdown...
> Jan 25 01:13:05 qwerty systemd[1]: Finished Update UTMP about System
> Boot/Shutdown.
> Jan 25 01:13:14 qwerty lightdm[2527]: Failed to write utmpx: No such
> file or directory
> Jan 25 01:13:15 qwerty systemd[1]: Starting Update UTMP about System
> Runlevel Changes...
> Jan 25 01:13:15 qwerty systemd[1]:
> systemd-update-utmp-runlevel.service: Succeeded.
> Jan 25 01:13:15 qwerty systemd[1]: Finished Update UTMP about System
> Runlevel Changes.
>
> Lightdm seems to be struggling with [I presume /var/run/]utmpx (which
> also doesn't exist)
>
> In a (new and un-updated VM of Deb 11.0 Mate):
>
> /# grep -ir utmp
> ...
> var/lib/plymouth/boot-duration:0.447:systemd-update-utmp.service
> ...
>
> but this doesn't appear on the host - is that significant?
>
>> Or... maybe you're just missing the /var/run symlink? Definitely check
>> that.
>
> /var$ ls -l
> lrwxrwxrwx 1 root root 4 Dec 8 2020 run -> /run
>
> Any further troubleshooting advice/instructions much appreciated -
> systemd.io and the Arch wiki don't seem to provide many pointers of
> where to begin for something like this.
>
> Thanks
> Gareth
Just realised I gave contradicting info earlier - I said both that I upgraded from Buster (which is literally true) and that
"But for root on ZFS per
https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html (adjusted for Bullseye) <<<<<<
..."
which isn't, because Bullseye arrived via dist-upgrade, rather than a fresh installation.
My mistake may have prompted Andrei's suggestion which I then explained away partly in relation to having upgraded - sorry.
G
Reply to: