Skip to main content ↑ ↓
Topic: S6-log: warning: unable to rename /var/log/udevd/current (Read 2144 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: S6-log: warning: unable to rename /var/log/udevd/current

Reply #30 –
Hi there,

I have recently encountered the same race condition with a separate BTRFS subvolume fstab mounted to /var/log.

I found out unexpectedly my grub mounts the BTRFS rootfs in rw mode instead of ro. So at the early boot stages /var/log  appeared to be writable also, it's just an empty not mounted directory. S6 happily initializes log services there, bypassing /run/log. /var/log is mounted to BTRFS subvol after all (at mount-filesystems/up), burying all logs. As a result, I have neither the /var/log/udev directory, nor /run/log/udev, same for all other sv logs. This makes s6-log crazy, endless looping on reboot.

It is clear that several conditions have come together here, but not so rare imho. s6 still needs to be improved. In the meantime, just check your bootloader configuration to ensure classical ro / mounting.
 
  

Re: S6-log: warning: unable to rename /var/log/udevd/current

Reply #31 –
Aha, that explanation makes sense. If you have /var available at that point in time, then /var/log will be writeable. Unfortunately, I'm not really sure how one would distinguish between between /var/log really being available then vs needing to wait on another partition to mount. Maybe I need to give in and just make this a configurable option somehow.

Re: S6-log: warning: unable to rename /var/log/udevd/current

Reply #32 –
Sorry for the delay on this one but it just occurred to me, what if you change /etc/s6/sv/udevd-log/run to the following and then recompile the database? Does that solve it for people that have this problem?

Code: [Select]
#!/bin/execlineb -P
envfile /etc/s6/config/udevd.conf
importas -sCuD "n3 s2000000 T" DIRECTIVES DIRECTIVES
ifelse { test -w /var/log/old } {
	foreground { install -d -o s6log -g s6log /var/log/udevd }
	s6-setuidgid s6log exec -c s6-log -d3 -b -- ${DIRECTIVES} /var/log/udevd
}
foreground { install -d -o s6log -g s6log /run/log/udevd }
s6-setuidgid s6log exec -c s6-log -d3 -b -- ${DIRECTIVES} /run/log/udevd

Re: S6-log: warning: unable to rename /var/log/udevd/current

Reply #33 –
Hello!

error

10 minutes after turning on and loading the system, an endless loop begins on the first console ctrl+alt+F1:
s6-log: warning: enabled to rename /var/log/syslog-ng/current to /var/log/syslog-ng/previous: No such file or directory
Shutting down and rebooting is not possible. Only reset

Solution. It turned out like this:
Code: [Select]
#mkdir /var/log/syslog-ng
#touch /var/log/syslog-ng/current
#touch /var/log/syslog-ng/previous
#chown -R s6log:s6log /var/log/syslog-ng
Next, the /var/log/syslog-ng/previous file is changed by the system itself to /var/log/syslog-ng/
4000000065216bde27fa108a.s or something similar.
Reboot normally after a minute.

This helped on the following builds:
artix-lxqt-s6-20230814-x86_64.iso
artix-plasma-s6-20230814-x86_64.iso
artix-plasma-s6-20231002-x86_64.iso
The following system works fine initially, no error:
artix-mate-s6-20231002-x86_64.iso

Question: is this a good solution? Could something else be broken?

p.s. sorry for the translation...)))

Re: S6-log: warning: unable to rename /var/log/udevd/current

Reply #34 –
Hi there,

S6 and S6-rc packages appear to be updated, but unfortunately Skarnet hasn’t provided a changelog of work done. I’m keen that such annoying bug should be fixed, so has anybody tested it?

Would be grateful for your feedback.

Re: S6-log: warning: unable to rename /var/log/udevd/current

Reply #35 –
Just tried myself. Everything works as intended.

Thank you!

Re: S6-log: warning: unable to rename /var/log/udevd/current

Reply #36 –
Just had the same issue with /var/log on separate btrfs subvolume(Another disk even) on a fresh install. For me the solution seems to be ro mount at boot time.
 

Re: S6-log: warning: unable to rename /var/log/udevd/current

Reply #37 –
Quote from: PatVax – on
Just had the same issue with /var/log on separate btrfs subvolume(Another disk even) on a fresh install. For me the solution seems to be ro mount at boot time.

Would it be possible for you to test what I posted here? I don't have a system I can test so it would be helpful to know if that actually does the trick.