Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 13:11, Greg Wooledge  wrote:
> On Tue, Jan 25, 2022 at 01:06:42PM +, Gareth Evans wrote:
>> 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.
>
> I don't know anything about ZFS.  That said, it's *conceivable* that
> your / ownership has been broken this entire time, and you never noticed
> until now.  Either because you never ran "who", or because 

> systemd in
> buster didn't check the parent directory ownerships, but the one in
> bullseye does.

That's interesting.

FWIW, trying to get a timeframe...

My email re bullseye upgrade hiccups back in August

https://lists.debian.org/debian-user/2021/08/msg00979.html

indicates that I upgraded to Bullseye on 17th Aug 2021.  There were at most a 
few days of experimenting with restoring Buster snapshots and re-upgrading, but 
that was certainly done with by October, when QEMU logs show VM usage.   

I've never had to 

modprobe tun 

to start a VM before today, and Bash history shows who usage on 22/12/21.  
Given this info and that the / ownership fix fixed both problems, I think that 
suggests a recent(ish) event as the cause.

>
> Food for thought.
>
> (It's not clear to me how setting up ZFS on / would involve your
> unprivileged username, though.  Sounds more like a "boot from rescue
> media and do everything in a root shell" sort of job.  

It is, but...

"5. Create a user account:

username=YOUR_USERNAME
zfs create rpool/home/$username
adduser $username
cp -a /etc/skel/. /home/$username
chown -R $username:$username /home/$username
..."

https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/Debian%20Buster%20Root%20on%20ZFS.html

:)


> So I'm more
> inclined to think the damage was done by some sort of backup/recovery
> gone wrong, as previously speculated.)

Re: Bullseye - who and users return nothing

[local10]

Jan 25, 2022, 13:06 by donots...@fastmail.fm:

> 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.


Also upgraded from Buster but can't reproduce the issue. Both "who" and "users" 
return proper output (ran it without sudo).

Regards,

Re: Bullseye - who and users return nothing

[Greg Wooledge]

On Tue, Jan 25, 2022 at 01:06:42PM +, Gareth Evans wrote:
> 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.

I don't know anything about ZFS.  That said, it's *conceivable* that
your / ownership has been broken this entire time, and you never noticed
until now.  Either because you never ran "who", or because systemd in
buster didn't check the parent directory ownerships, but the one in
bullseye does.

Food for thought.

(It's not clear to me how setting up ZFS on / would involve your
unprivileged username, though.  Sounds more like a "boot from rescue
media and do everything in a root shell" sort of job.  So I'm more
inclined to think the damage was done by some sort of backup/recovery
gone wrong, as previously speculated.)

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 01:31, Gareth Evans  wrote:
> On Mon 24 Jan 2022, at 12:45, Greg Wooledge  wrote:
>> On Mon, Jan 24, 2022 at 09:51:05AM +, 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
> NAMEUSED  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/large3.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
>>> 
>>> 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
>> tmpfs1215580  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)
>  

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 10:47, Andrei POPESCU  wrote:
> On Ma, 25 ian 22, 04:03:17, Gareth Evans wrote:
>> 
>> Googling "Detected unsafe path transition during canonicalization" led me to 
>> 
>> https://bbs.archlinux.org/viewtopic.php?id=260924
>> 
>> where a user sees this error because / is owned by the user rather than root.
>> 
>> Lo and behold
>> 
>> $ stat /
>> 
>> shows this is what has somehow happened.
>> 
>> $ sudo chown root:root /
>> 
>> solves the disappearing /var/run/utmp problem (and fixes who/users) 
>> 
>> There is nothing in bash history to suggest I did this - can/should it 
>> happen any other way?
>

> Occam's Razor would suggest this was done when setting up your / on ZFS.

Hi Andrei,

chown root:root / 

fixed both this issue and my need (today, as discussed in my other email) to 

modprobe tun

to be able to run VMs with virt-manager.

That was a new problem I only noticed today when setting up a VM to find/grep 
relevant strings/filenames that would exist in a new installation.  I use VMs 
more often than who/users but have certainly done both without issue since 
setting up / on ZFS.

But worth bearing in mind :)

Thanks
Gareth


>
>
> Kind regards,
> Andrei
> -- 
> http://wiki.debian.org/FAQsFromDebianUser
>
> Attachments:
> * signature.asc

Re: Bullseye - who and users return nothing

[Andrei POPESCU]

On Ma, 25 ian 22, 04:03:17, Gareth Evans wrote:
> 
> Googling "Detected unsafe path transition during canonicalization" led me to 
> 
> https://bbs.archlinux.org/viewtopic.php?id=260924
> 
> where a user sees this error because / is owned by the user rather than root.
> 
> Lo and behold
> 
> $ stat /
> 
> shows this is what has somehow happened.
> 
> $ sudo chown root:root /
> 
> solves the disappearing /var/run/utmp problem (and fixes who/users) 
> 
> There is nothing in bash history to suggest I did this - can/should it happen 
> any other way?

Occam's Razor would suggest this was done when setting up your / on ZFS.


Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser


signature.asc
Description: PGP signature

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 04:50, David Wright  wrote:
> On Tue 25 Jan 2022 at 04:22:39 (+), Gareth Evans wrote:
>> On Tue 25 Jan 2022, at 04:10, Polyna-Maude Racicot-Summerside 
>>  wrote:
>> > On 2022-01-24 23:03, Gareth Evans wrote:
>> >> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> >> transition / → /var during canonicalization of 
>> >> /var/log/journal/7f684579096949909ba2bfac31e8423e/sy>
>> >> Jan 25 01:46:52 qwerty systemd[1]: Finished Create Volatile Files and 
>> >> Directories.
>> >> 
>> >> Googling "Detected unsafe path transition during canonicalization" led me 
>> >> to 
>> >> 
>> >> https://bbs.archlinux.org/viewtopic.php?id=260924
>> >> 
>> >> where a user sees this error because / is owned by the user rather than 
>> >> root.
>> >> 
>> >> Lo and behold
>> >> 
>> >> $ stat /
>> >> 
>> >> shows this is what has somehow happened.
>> >> 
>> >> $ sudo chown root:root /
>> >> 
>> >> solves the disappearing /var/run/utmp problem (and fixes who/users) 
>> >> 
>> >> There is nothing in bash history to suggest I did this - can/should it 
>> >> happen any other way?
>> 
>> > No one other than you know the whole story behind what happened with
>> > your computer.
>> >
>> > Is it a new clean install
>> > How did you partition the hard drive
>> > etc..
>> 
>> The last clean installation was of Buster and it's since been upgraded to 
>> Bullseye.
>> 
>> An unfinished and accidentally-executed 
>> 
>> sudo chown /[some/file] 
>> 
>> doesn't seem impossible, but the lack of any such thing in bash history 
>> seems curious.  Perhaps a leading space crept in too, which would exclude 
>> the command from the history.
>> 
>> I was just wondering about other ways that could happen, if any.
>
> A frequent way, sometimes narrated in Operator Horror Stories from
> years ago, was untarring an archive. Gnu tar does its best to protect
> you, but can be overridden.
>

> But my Q1 is always "What were the ownerships and permissions before
> you reverted them?" That's often the best clue. 

As of now:

$ ls -ld /
drwxr-xr-x 23 root root 33 Jan 21 14:48 /

The only difference was my username in the owner position.

There is nothing in my [timestamped] bash history at 14:48 on 21 Jan.  Just 
before that time I had used engrampa from the command line. Use of other 
scripts around the time suggests the archive concerned may have been a file in 
/var/www/html - I do sometimes have to change permissions and ownership there, 
so perhaps (cough mumble mumble).

Thanks all.
G






> Eg, from just yesterday:
> https://lists.debian.org/debian-user/2022/01/msg00874.html
> caused by restoring backups from amanda.
>
> Cheers,
> David.

Re: Bullseye - who and users return nothing

[David Wright]

On Tue 25 Jan 2022 at 04:22:39 (+), Gareth Evans wrote:
> On Tue 25 Jan 2022, at 04:10, Polyna-Maude Racicot-Summerside 
>  wrote:
> > On 2022-01-24 23:03, Gareth Evans wrote:
> >> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
> >> transition / → /var during canonicalization of 
> >> /var/log/journal/7f684579096949909ba2bfac31e8423e/sy>
> >> Jan 25 01:46:52 qwerty systemd[1]: Finished Create Volatile Files and 
> >> Directories.
> >> 
> >> Googling "Detected unsafe path transition during canonicalization" led me 
> >> to 
> >> 
> >> https://bbs.archlinux.org/viewtopic.php?id=260924
> >> 
> >> where a user sees this error because / is owned by the user rather than 
> >> root.
> >> 
> >> Lo and behold
> >> 
> >> $ stat /
> >> 
> >> shows this is what has somehow happened.
> >> 
> >> $ sudo chown root:root /
> >> 
> >> solves the disappearing /var/run/utmp problem (and fixes who/users) 
> >> 
> >> There is nothing in bash history to suggest I did this - can/should it 
> >> happen any other way?
> 
> > No one other than you know the whole story behind what happened with
> > your computer.
> >
> > Is it a new clean install
> > How did you partition the hard drive
> > etc..
> 
> The last clean installation was of Buster and it's since been upgraded to 
> Bullseye.
> 
> An unfinished and accidentally-executed 
> 
> sudo chown /[some/file] 
> 
> doesn't seem impossible, but the lack of any such thing in bash history seems 
> curious.  Perhaps a leading space crept in too, which would exclude the 
> command from the history.
> 
> I was just wondering about other ways that could happen, if any.

A frequent way, sometimes narrated in Operator Horror Stories from
years ago, was untarring an archive. Gnu tar does its best to protect
you, but can be overridden.

But my Q1 is always "What were the ownerships and permissions before
you reverted them?" That's often the best clue. Eg, from just yesterday:
https://lists.debian.org/debian-user/2022/01/msg00874.html
caused by restoring backups from amanda.

Cheers,
David.

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 04:10, Polyna-Maude Racicot-Summerside 
 wrote:
> On 2022-01-24 23:03, Gareth Evans wrote:
>> On Tue 25 Jan 2022, at 03:28, Greg Wooledge  wrote:
>>> On Tue, Jan 25, 2022 at 03:06:00AM +, Gareth Evans wrote:
 On Tue 25 Jan 2022, at 03:02, Gareth Evans  wrote:
> On Tue 25 Jan 2022, at 02:54, Greg Wooledge  wrote:
>> A google search led me to 
>> which says that the /run/utmp file is supposed to be created by
>> "tmpfiles", specifically by the instructions in the configuration
>> file /usr/lib/tmpfiles.d/systemd.conf .
>>
>
>> On my system, /usr/lib/tmpfiles.d/systemd.conf contains this line:
>>
>> F! /run/utmp 0664 root utmp -
>>

>> Does your system have this file, and if so, does it contain that line?
>
> Thanks, yes:
>
> $ sudo cat /usr/lib/tmpfiles.d/systemd.conf | grep utmp
> F! /run/utmp 0664 root utmp -

 And fwiw (from a comment in the link you provided)

 $ sudo journalctl -b _COMM=systemd-tmpfiles
 -- Journal begins at Sat 2021-08-21 14:27:06 BST, ends at Tue 2022-01-25 
 03:04:>
 -- No entries --
>>>
>>> Next thing to check seems to be:
>>>
>>> systemctl status systemd-tmpfiles-setup.service
>> 
>> Aha...
>> 
>> systemd-tmpfiles-setup.service - Create Volatile Files and Directories
>>  Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; 
>> static)
>>  Active: active (exited) since Tue 2022-01-25 01:46:52 GMT; 1h 53min ago
>>Docs: man:tmpfiles.d(5)
>>  man:systemd-tmpfiles(8)
>> Process: 1340 ExecStart=systemd-tmpfiles --create --remove --boot 
>> --exclude-prefix=/dev (code=exited, status=73)
>>Main PID: 1340 (code=exited, status=73)
>> CPU: 20ms
>> 
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /var during canonicalization of /var/log/journal.
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /var during canonicalization of /var/log/journal.
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /var during canonicalization of 
>> /var/log/journal/7f684579096949909ba2bfac31e8423e.
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /var during canonicalization of 
>> /var/log/journal/7f684579096949909ba2bfac31e8423e.
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /var during canonicalization of 
>> /var/log/journal/7f684579096949909ba2bfac31e8423e.
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /run during canonicalization of /run/log/journal.
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /run during canonicalization of /run/log/journal.
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /var during canonicalization of 
>> /var/log/journal/7f684579096949909ba2bfac31e8423e/sy>
>> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
>> transition / → /var during canonicalization of 
>> /var/log/journal/7f684579096949909ba2bfac31e8423e/sy>
>> Jan 25 01:46:52 qwerty systemd[1]: Finished Create Volatile Files and 
>> Directories.
>> 
>> Googling "Detected unsafe path transition during canonicalization" led me to 
>> 
>> https://bbs.archlinux.org/viewtopic.php?id=260924
>> 
>> where a user sees this error because / is owned by the user rather than root.
>> 
>> Lo and behold
>> 
>> $ stat /
>> 
>> shows this is what has somehow happened.
>> 
>> $ sudo chown root:root /
>> 
>> solves the disappearing /var/run/utmp problem (and fixes who/users) 
>> 
>> There is nothing in bash history to suggest I did this - can/should it 
>> happen any other way?

> No one other than you know the whole story behind what happened with
> your computer.
>
> Is it a new clean install
> How did you partition the hard drive
> etc..

Hi,

The last clean installation was of Buster and it's since been upgraded to 
Bullseye.

An unfinished and accidentally-executed 

sudo chown /[some/file] 

doesn't seem impossible, but the lack of any such thing in bash history seems 
curious.  Perhaps a leading space crept in too, which would exclude the command 
from the history.

I was just wondering about other ways that could happen, if any.

Best wishes,
Gareth



>> 
>> Thanks very much for your help Greg.
>> 
>> Gareth
>> 
>> 
>>>
>>> Make sure it hasn't been disabled or masked, I suppose.  The unit file
>>> contains this command:
>>>
>>> ExecStart=systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
>>>
>>> So, I guess make sure yours has that too.  But hopefully you'll discover
>>> that it's been disabled or something silly like that, and then you can
>>> just enable it.
>> 
>
> -- 
> Polyna-Maude R.-Summerside
> -Be smart, Be wise, Support opensource 

Re: Bullseye - who and users return nothing

[Polyna-Maude Racicot-Summerside]

On 2022-01-24 23:03, Gareth Evans wrote:
> On Tue 25 Jan 2022, at 03:28, Greg Wooledge  wrote:
>> On Tue, Jan 25, 2022 at 03:06:00AM +, Gareth Evans wrote:
>>> On Tue 25 Jan 2022, at 03:02, Gareth Evans  wrote:
 On Tue 25 Jan 2022, at 02:54, Greg Wooledge  wrote:
> A google search led me to 
> which says that the /run/utmp file is supposed to be created by
> "tmpfiles", specifically by the instructions in the configuration
> file /usr/lib/tmpfiles.d/systemd.conf .
>

> On my system, /usr/lib/tmpfiles.d/systemd.conf contains this line:
>
> F! /run/utmp 0664 root utmp -
>
>>>
> Does your system have this file, and if so, does it contain that line?

 Thanks, yes:

 $ sudo cat /usr/lib/tmpfiles.d/systemd.conf | grep utmp
 F! /run/utmp 0664 root utmp -
>>>
>>> And fwiw (from a comment in the link you provided)
>>>
>>> $ sudo journalctl -b _COMM=systemd-tmpfiles
>>> -- Journal begins at Sat 2021-08-21 14:27:06 BST, ends at Tue 2022-01-25 
>>> 03:04:>
>>> -- No entries --
>>
>> Next thing to check seems to be:
>>
>> systemctl status systemd-tmpfiles-setup.service
> 
> Aha...
> 
> systemd-tmpfiles-setup.service - Create Volatile Files and Directories
>  Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; 
> static)
>  Active: active (exited) since Tue 2022-01-25 01:46:52 GMT; 1h 53min ago
>Docs: man:tmpfiles.d(5)
>  man:systemd-tmpfiles(8)
> Process: 1340 ExecStart=systemd-tmpfiles --create --remove --boot 
> --exclude-prefix=/dev (code=exited, status=73)
>Main PID: 1340 (code=exited, status=73)
> CPU: 20ms
> 
> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
> transition / → /var during canonicalization of /var/log/journal.
> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
> transition / → /var during canonicalization of /var/log/journal.
> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
> transition / → /var during canonicalization of 
> /var/log/journal/7f684579096949909ba2bfac31e8423e.
> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
> transition / → /var during canonicalization of 
> /var/log/journal/7f684579096949909ba2bfac31e8423e.
> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
> transition / → /var during canonicalization of 
> /var/log/journal/7f684579096949909ba2bfac31e8423e.
> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
> transition / → /run during canonicalization of /run/log/journal.
> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
> transition / → /run during canonicalization of /run/log/journal.
> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
> transition / → /var during canonicalization of 
> /var/log/journal/7f684579096949909ba2bfac31e8423e/sy>
> Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path 
> transition / → /var during canonicalization of 
> /var/log/journal/7f684579096949909ba2bfac31e8423e/sy>
> Jan 25 01:46:52 qwerty systemd[1]: Finished Create Volatile Files and 
> Directories.
> 
> Googling "Detected unsafe path transition during canonicalization" led me to 
> 
> https://bbs.archlinux.org/viewtopic.php?id=260924
> 
> where a user sees this error because / is owned by the user rather than root.
> 
> Lo and behold
> 
> $ stat /
> 
> shows this is what has somehow happened.
> 
> $ sudo chown root:root /
> 
> solves the disappearing /var/run/utmp problem (and fixes who/users) 
> 
> There is nothing in bash history to suggest I did this - can/should it happen 
> any other way?
No one other than you know the whole story behind what happened with
your computer.

Is it a new clean install
How did you partition the hard drive
etc..
> 
> Thanks very much for your help Greg.
> 
> Gareth
> 
> 
>>
>> Make sure it hasn't been disabled or masked, I suppose.  The unit file
>> contains this command:
>>
>> ExecStart=systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
>>
>> So, I guess make sure yours has that too.  But hopefully you'll discover
>> that it's been disabled or something silly like that, and then you can
>> just enable it.
> 

-- 
Polyna-Maude R.-Summerside
-Be smart, Be wise, Support opensource development


OpenPGP_signature
Description: OpenPGP digital signature

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 03:28, Greg Wooledge  wrote:
> On Tue, Jan 25, 2022 at 03:06:00AM +, Gareth Evans wrote:
>> On Tue 25 Jan 2022, at 03:02, Gareth Evans  wrote:
>> > On Tue 25 Jan 2022, at 02:54, Greg Wooledge  wrote:
>> >> A google search led me to 
>> >> which says that the /run/utmp file is supposed to be created by
>> >> "tmpfiles", specifically by the instructions in the configuration
>> >> file /usr/lib/tmpfiles.d/systemd.conf .
>> >>
>> >
>> >> On my system, /usr/lib/tmpfiles.d/systemd.conf contains this line:
>> >>
>> >> F! /run/utmp 0664 root utmp -
>> >>
>> 
>> >> Does your system have this file, and if so, does it contain that line?
>> >
>> > Thanks, yes:
>> >
>> > $ sudo cat /usr/lib/tmpfiles.d/systemd.conf | grep utmp
>> > F! /run/utmp 0664 root utmp -
>> 
>> And fwiw (from a comment in the link you provided)
>> 
>> $ sudo journalctl -b _COMM=systemd-tmpfiles
>> -- Journal begins at Sat 2021-08-21 14:27:06 BST, ends at Tue 2022-01-25 
>> 03:04:>
>> -- No entries --
>
> Next thing to check seems to be:
>
> systemctl status systemd-tmpfiles-setup.service

Aha...

systemd-tmpfiles-setup.service - Create Volatile Files and Directories
 Loaded: loaded (/lib/systemd/system/systemd-tmpfiles-setup.service; static)
 Active: active (exited) since Tue 2022-01-25 01:46:52 GMT; 1h 53min ago
   Docs: man:tmpfiles.d(5)
 man:systemd-tmpfiles(8)
Process: 1340 ExecStart=systemd-tmpfiles --create --remove --boot 
--exclude-prefix=/dev (code=exited, status=73)
   Main PID: 1340 (code=exited, status=73)
CPU: 20ms

Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /var during canonicalization of /var/log/journal.
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /var during canonicalization of /var/log/journal.
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /var during canonicalization of 
/var/log/journal/7f684579096949909ba2bfac31e8423e.
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /var during canonicalization of 
/var/log/journal/7f684579096949909ba2bfac31e8423e.
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /var during canonicalization of 
/var/log/journal/7f684579096949909ba2bfac31e8423e.
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /run during canonicalization of /run/log/journal.
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /run during canonicalization of /run/log/journal.
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /var during canonicalization of 
/var/log/journal/7f684579096949909ba2bfac31e8423e/sy>
Jan 25 01:46:52 qwerty systemd-tmpfiles[1340]: Detected unsafe path transition 
/ → /var during canonicalization of 
/var/log/journal/7f684579096949909ba2bfac31e8423e/sy>
Jan 25 01:46:52 qwerty systemd[1]: Finished Create Volatile Files and 
Directories.

Googling "Detected unsafe path transition during canonicalization" led me to 

https://bbs.archlinux.org/viewtopic.php?id=260924

where a user sees this error because / is owned by the user rather than root.

Lo and behold

$ stat /

shows this is what has somehow happened.

$ sudo chown root:root /

solves the disappearing /var/run/utmp problem (and fixes who/users) 

There is nothing in bash history to suggest I did this - can/should it happen 
any other way?

Thanks very much for your help Greg.

Gareth


>
> Make sure it hasn't been disabled or masked, I suppose.  The unit file
> contains this command:
>
> ExecStart=systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev
>
> So, I guess make sure yours has that too.  But hopefully you'll discover
> that it's been disabled or something silly like that, and then you can
> just enable it.

Re: Bullseye - who and users return nothing

[Greg Wooledge]

On Tue, Jan 25, 2022 at 03:06:00AM +, Gareth Evans wrote:
> On Tue 25 Jan 2022, at 03:02, Gareth Evans  wrote:
> > On Tue 25 Jan 2022, at 02:54, Greg Wooledge  wrote:
> >> A google search led me to 
> >> which says that the /run/utmp file is supposed to be created by
> >> "tmpfiles", specifically by the instructions in the configuration
> >> file /usr/lib/tmpfiles.d/systemd.conf .
> >>
> >
> >> On my system, /usr/lib/tmpfiles.d/systemd.conf contains this line:
> >>
> >> F! /run/utmp 0664 root utmp -
> >>
> 
> >> Does your system have this file, and if so, does it contain that line?
> >
> > Thanks, yes:
> >
> > $ sudo cat /usr/lib/tmpfiles.d/systemd.conf | grep utmp
> > F! /run/utmp 0664 root utmp -
> 
> And fwiw (from a comment in the link you provided)
> 
> $ sudo journalctl -b _COMM=systemd-tmpfiles
> -- Journal begins at Sat 2021-08-21 14:27:06 BST, ends at Tue 2022-01-25 
> 03:04:>
> -- No entries --

Next thing to check seems to be:

systemctl status systemd-tmpfiles-setup.service

Make sure it hasn't been disabled or masked, I suppose.  The unit file
contains this command:

ExecStart=systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev

So, I guess make sure yours has that too.  But hopefully you'll discover
that it's been disabled or something silly like that, and then you can
just enable it.

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 03:02, Gareth Evans  wrote:
> On Tue 25 Jan 2022, at 02:54, Greg Wooledge  wrote:
>> On Tue, Jan 25, 2022 at 01:31:35AM +, Gareth Evans wrote:
>>> /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
>>
>> A google search led me to 
>> which says that the /run/utmp file is supposed to be created by
>> "tmpfiles", specifically by the instructions in the configuration
>> file /usr/lib/tmpfiles.d/systemd.conf .
>>
>
>> On my system, /usr/lib/tmpfiles.d/systemd.conf contains this line:
>>
>> F! /run/utmp 0664 root utmp -
>>

>> Does your system have this file, and if so, does it contain that line?
>
> Thanks, yes:
>
> $ sudo cat /usr/lib/tmpfiles.d/systemd.conf | grep utmp
> F! /run/utmp 0664 root utmp -

And fwiw (from a comment in the link you provided)

$ sudo journalctl -b _COMM=systemd-tmpfiles
-- Journal begins at Sat 2021-08-21 14:27:06 BST, ends at Tue 2022-01-25 03:04:>
-- No entries --

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 02:54, Greg Wooledge  wrote:
> On Tue, Jan 25, 2022 at 01:31:35AM +, Gareth Evans wrote:
>> /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
>
> A google search led me to 
> which says that the /run/utmp file is supposed to be created by
> "tmpfiles", specifically by the instructions in the configuration
> file /usr/lib/tmpfiles.d/systemd.conf .
>

> On my system, /usr/lib/tmpfiles.d/systemd.conf contains this line:
>
> F! /run/utmp 0664 root utmp -
>
> Does your system have this file, and if so, does it contain that line?

Thanks, yes:

$ sudo cat /usr/lib/tmpfiles.d/systemd.conf | grep utmp
F! /run/utmp 0664 root utmp -

Re: Bullseye - who and users return nothing

[Greg Wooledge]

On Tue, Jan 25, 2022 at 01:31:35AM +, Gareth Evans wrote:
> /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

A google search led me to 
which says that the /run/utmp file is supposed to be created by
"tmpfiles", specifically by the instructions in the configuration
file /usr/lib/tmpfiles.d/systemd.conf .

On my system, /usr/lib/tmpfiles.d/systemd.conf contains this line:

F! /run/utmp 0664 root utmp -

Does your system have this file, and if so, does it contain that line?

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Tue 25 Jan 2022, at 01:31, Gareth Evans  wrote:
> On Mon 24 Jan 2022, at 12:45, Greg Wooledge  wrote:
>> On Mon, Jan 24, 2022 at 09:51:05AM +, 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
> NAMEUSED  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/large3.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
>>> 
>>> 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
>> tmpfs1215580  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)
>  

Re: Bullseye - who and users return nothing

[Gareth Evans]

On Mon 24 Jan 2022, at 12:45, Greg Wooledge  wrote:
> On Mon, Jan 24, 2022 at 09:51:05AM +, 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
NAMEUSED  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/large3.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
>> 
>> 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
> tmpfs1215580  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 

Re: Bullseye - who and users return nothing

[Greg Wooledge]

On Mon, Jan 24, 2022 at 09:51:05AM +, 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?  How are you logging in?  Are you using any terminal
emulators, and if so, which one(s)?

Is the /var file system full?  (Or any mount underneath /var if you have
such.)

Have you done anything unique or unusual to your system that would cause
it not to log sessions in /var/run/utmp?

> $ sudo strace who
> 
> 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
tmpfs1215580  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.

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.

Or... maybe you're just missing the /var/run symlink?  Definitely check
that.

Bullseye - who and users return nothing

[Gareth Evans]

Hello,

I've just noticed that: 

$ who

and

$ users

both return nothing, with or without sudo.

$ sudo strace who

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 +++

I found these which look at least semi-relevant for other distros;  the redhat 
link seems to suggest a failure at or before login.

https://www.suse.com/support/kb/doc/?id=17277
https://bugzilla.redhat.com/show_bug.cgi?id=1396065

- but nothing for Debian - so any advice on how to proceed would be appreciated.

Can anyone replicate this or suggest what may have happened?  I'm fairly sure 
I've used who since upgrading from Buster.

Would try creating the files but I'm not sure of Debian's ownership/permissions 
requirements.

$ cat /etc/debian_version
11.2

Thanks,
Gareth