Re: Bullseye - who and users return nothing
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
Reply to: