Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #244499 > unrolled thread

Bullseye - who and users return nothing

Back to article view | Back to linux.debian.user

Contents

  Bullseye - who and users return nothing "Gareth Evans" <donotspam@fastmail.fm> - 2022-01-24 11:00 +0100
    Re: Bullseye - who and users return nothing Greg Wooledge <greg@wooledge.org> - 2022-01-24 13:50 +0100
      Re: Bullseye - who and users return nothing "Gareth Evans" <donotspam@fastmail.fm> - 2022-01-25 02:40 +0100
      Re: Bullseye - who and users return nothing "Gareth Evans" <donotspam@fastmail.fm> - 2022-01-25 02:40 +0100
        Re: Bullseye - who and users return nothing Greg Wooledge <greg@wooledge.org> - 2022-01-25 04:00 +0100
          Re: Bullseye - who and users return nothing "Gareth Evans" <donotspam@fastmail.fm> - 2022-01-25 04:10 +0100
            Re: Bullseye - who and users return nothing "Gareth Evans" <donotspam@fastmail.fm> - 2022-01-25 04:10 +0100
              Re: Bullseye - who and users return nothing Greg Wooledge <greg@wooledge.org> - 2022-01-25 04:30 +0100
                Re: Bullseye - who and users return nothing "Gareth Evans" <donotspam@fastmail.fm> - 2022-01-25 05:10 +0100
                  Re: Bullseye - who and users return nothing Polyna-Maude Racicot-Summerside <debian@polynamaude.com> - 2022-01-25 05:20 +0100
                    Re: Bullseye - who and users return nothing "Gareth Evans" <donotspam@fastmail.fm> - 2022-01-25 05:30 +0100
                      Re: Bullseye - who and users return nothing David Wright <deblis@lionunicorn.co.uk> - 2022-01-25 06:00 +0100
                        Re: Bullseye - who and users return nothing "Gareth Evans" <donotspam@fastmail.fm> - 2022-01-25 06:40 +0100
                  Re: Bullseye - who and users return nothing Andrei POPESCU <andreimpopescu@gmail.com> - 2022-01-25 11:50 +0100
                    Re: Bullseye - who and users return nothing "Gareth Evans" <donotspam@fastmail.fm> - 2022-01-25 13:20 +0100
        Re: Bullseye - who and users return nothing "Gareth Evans" <donotspam@fastmail.fm> - 2022-01-25 14:10 +0100
          Re: Bullseye - who and users return nothing local10 <local10@tutanota.com> - 2022-01-25 14:20 +0100
          Re: Bullseye - who and users return nothing Greg Wooledge <greg@wooledge.org> - 2022-01-25 14:20 +0100
            Re: Bullseye - who and users return nothing "Gareth Evans" <donotspam@fastmail.fm> - 2022-01-25 16:00 +0100

#244499 — Bullseye - who and users return nothing

Hello,

I've just noticed that: 

$ who

and

$ users

both return nothing, with or without sudo.

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

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=000017277
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

[toc] | [next] | [standalone]

#244520

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

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.

[toc] | [prev] | [next] | [standalone]

#244551

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?

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

[toc] | [prev] | [next] | [standalone]

#244552

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

[toc] | [prev] | [next] | [standalone]

#244555

On Tue, Jan 25, 2022 at 01:31:35AM +0000, 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 <https://bugs.archlinux.org/task/47749>
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?

[toc] | [prev] | [next] | [standalone]

#244556

On Tue 25 Jan 2022, at 02:54, Greg Wooledge <greg@wooledge.org> wrote:
> On Tue, Jan 25, 2022 at 01:31:35AM +0000, 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 <https://bugs.archlinux.org/task/47749>
> 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 -

[toc] | [prev] | [next] | [standalone]

#244557

On Tue 25 Jan 2022, at 03:02, Gareth Evans <donotspam@fastmail.fm> wrote:
> On Tue 25 Jan 2022, at 02:54, Greg Wooledge <greg@wooledge.org> wrote:
>> On Tue, Jan 25, 2022 at 01:31:35AM +0000, 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 <https://bugs.archlinux.org/task/47749>
>> 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 --

[toc] | [prev] | [next] | [standalone]

#244560

On Tue, Jan 25, 2022 at 03:06:00AM +0000, Gareth Evans wrote:
> On Tue 25 Jan 2022, at 03:02, Gareth Evans <donotspam@fastmail.fm> wrote:
> > On Tue 25 Jan 2022, at 02:54, Greg Wooledge <greg@wooledge.org> wrote:
> >> A google search led me to <https://bugs.archlinux.org/task/47749>
> >> 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.

[toc] | [prev] | [next] | [standalone]

#244562

On Tue 25 Jan 2022, at 03:28, Greg Wooledge <greg@wooledge.org> wrote:
> On Tue, Jan 25, 2022 at 03:06:00AM +0000, Gareth Evans wrote:
>> On Tue 25 Jan 2022, at 03:02, Gareth Evans <donotspam@fastmail.fm> wrote:
>> > On Tue 25 Jan 2022, at 02:54, Greg Wooledge <greg@wooledge.org> wrote:
>> >> A google search led me to <https://bugs.archlinux.org/task/47749>
>> >> 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.

[toc] | [prev] | [next] | [standalone]

#244563

[Multipart message — attachments visible in raw view] — view raw

On 2022-01-24 23:03, Gareth Evans wrote:
> On Tue 25 Jan 2022, at 03:28, Greg Wooledge <greg@wooledge.org> wrote:
>> On Tue, Jan 25, 2022 at 03:06:00AM +0000, Gareth Evans wrote:
>>> On Tue 25 Jan 2022, at 03:02, Gareth Evans <donotspam@fastmail.fm> wrote:
>>>> On Tue 25 Jan 2022, at 02:54, Greg Wooledge <greg@wooledge.org> wrote:
>>>>> A google search led me to <https://bugs.archlinux.org/task/47749>
>>>>> 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

[toc] | [prev] | [next] | [standalone]

#244564

On Tue 25 Jan 2022, at 04:10, Polyna-Maude Racicot-Summerside <debian@polynamaude.com> wrote:
> On 2022-01-24 23:03, Gareth Evans wrote:
>> On Tue 25 Jan 2022, at 03:28, Greg Wooledge <greg@wooledge.org> wrote:
>>> On Tue, Jan 25, 2022 at 03:06:00AM +0000, Gareth Evans wrote:
>>>> On Tue 25 Jan 2022, at 03:02, Gareth Evans <donotspam@fastmail.fm> wrote:
>>>>> On Tue 25 Jan 2022, at 02:54, Greg Wooledge <greg@wooledge.org> wrote:
>>>>>> A google search led me to <https://bugs.archlinux.org/task/47749>
>>>>>> 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 development
>
> Attachments:
> * OpenPGP_signature

[toc] | [prev] | [next] | [standalone]

#244566

On Tue 25 Jan 2022 at 04:22:39 (+0000), Gareth Evans wrote:
> On Tue 25 Jan 2022, at 04:10, Polyna-Maude Racicot-Summerside <debian@polynamaude.com> 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.

[toc] | [prev] | [next] | [standalone]

#244567

On Tue 25 Jan 2022, at 04:50, David Wright <deblis@lionunicorn.co.uk> wrote:
> On Tue 25 Jan 2022 at 04:22:39 (+0000), Gareth Evans wrote:
>> On Tue 25 Jan 2022, at 04:10, Polyna-Maude Racicot-Summerside <debian@polynamaude.com> 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.

[toc] | [prev] | [next] | [standalone]

#244579

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#244583

On Tue 25 Jan 2022, at 10:47, Andrei POPESCU <andreimpopescu@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#244586

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

[toc] | [prev] | [next] | [standalone]

#244588

Jan 25, 2022, 13:06 by donotspam@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,

[toc] | [prev] | [next] | [standalone]

#244589

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

[toc] | [prev] | [next] | [standalone]

#244595

On Tue 25 Jan 2022, at 13:11, Greg Wooledge <greg@wooledge.org> wrote:
> On Tue, Jan 25, 2022 at 01:06:42PM +0000, 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.)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web