On Tue 25 Jan 2022, at 01:31, Gareth Evans <donots...@fastmail.fm> wrote: > On Mon 24 Jan 2022, at 12:45, Greg Wooledge <g...@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? Sorry, yes it does. > >> 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
