On Tue 25 Jan 2022, at 04:10, Polyna-Maude Racicot-Summerside <deb...@polynamaude.com> wrote: > On 2022-01-24 23:03, Gareth Evans wrote: >> On Tue 25 Jan 2022, at 03:28, Greg Wooledge <g...@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 <donots...@fastmail.fm> wrote: >>>>> On Tue 25 Jan 2022, at 02:54, Greg Wooledge <g...@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