Unfortunately it's taken me until now to get back around to this.
After the changes it works as expected with everything written on the right device, but a couple of things still propped up.
On line 6 in /etc/s6/sv/lvm2-pvscan/up there's a typo:
if -n -t { test -d /var/log/lvm2-pvscan } install -d -m 0755 -o s6log -g s6log /run/log/lvm2-pvscan
Test for /var/log should be /run/log instead. Similar line in lvm2-monitor/up (also on line 6) has it correctly, however I feel these tests could be omitted altogether and have install run unconditionally in both cases, since the script was working correctly either way if slightly accidentally, and install will essentially perform a no-operation if the directory did happen to already exist under /run/log for some reason.
A much more troublesome issue exists in /etc/s6/log-service-reload.sh on line 19 with the cat command, where it moves over logs from /run/log/<foo>/current into /var/log/<foo>/current. if the destination file doesn't exist already (e.g. after a fresh install) it's created with owner set to root:root and not s6log:s6log as it should be. The end result is an unending stream of these on the console for every service that fell victim to it: "s6-log: fatal: unable to finish current .u for logdir /var/log/<foo>: Operation not permitted".
A couple of possible fix suggestions for it.
Either add a test before line 19 so the file is ensured to exist before cat'ing to it:
test ! -f /var/log/"${dir}"/current && install -m 0744 -o s6log -g s6log /dev/null /var/log/"${dir}"/current
Or in a more verbose manner by replacing the line with an if-else:
if [ -f /var/log/"${dir}"/current ]; then
cat /run/log/"${dir}"/current >> /var/log/"${dir}"/current
else
install -m 0744 -o s6log -g s6log /run/log/"${dir}"/current /var/log/"${dir}"/current
fi
The user executable bit on the new file must also be set on these so s6-log will use it instead of moving it over to a .u file and proceeding to open a new current file. (This had me confused for a while why s6-log insisted on clearing the log upon restart even with correct ownership.) Personally I'm probably partial to the latter way since it makes it very clear what is happening and why.
There's a chance of someone having this broken on their setup going unnoticed so it's probably worth either notifying users to take action manually or possibly by adding a post-install pacman hook to fix the log files in the vein of something like the following:
for cur in /var/log/*/current; do
test ! -f "$cur" && continue
if [ "`stat -c "%U" "$cur"`" != "s6log" ]; then
chmod 744 "$cur"
chown s6log:s6log "$cur"
fi
done
I haven't messed with pacman scripts so that code is largely untested in that context and thus just a rough idea.
Easy enough to test:
$ sudo dd if=/dev/zero of=/swap.file bs=1M count=100; sudo chmod 600 /swap.file; sudo mkswap /swap.file
100+0 records in
100+0 records out
104857600 bytes (105 MB, 100 MiB) copied, 0.101121 s, 1.0 GB/s
Setting up swapspace version 1, size = 100 MiB (104853504 bytes)
no label, UUID=8f7c4ee6-04f5-4800-802a-5388206faf77
$ swapon
$ sudo mount -o remount,ro /
$ sudo swapon /swap.file
swapon: /swap.file: swapon failed: Read-only file system
$ swapon
$ sudo mount -o remount,rw /
$ sudo swapon /swap.file
$ swapon
NAME TYPE SIZE USED PRIO
/swap.file file 100M 0B -2
Also a test with the root partition actually set to read-only in Grub's config:
s6-rc: info: service swap: starting
s6-rc: info: service remount-root: starting
swapon: /swap.file: swapon failed: Read-only file system
s6-rc: warning: unable to start service swap: command exited 128
s6-rc: info: service remount-root successfully started
So it certainly does (or can, since I believe there's a race condition that might not trigger always) fail under these conditions. After switching the swap service's dependencies from mount-filesystems to remount-root it works without a hitch. The change only bumps up the service startup moment by a notch so I don't foresee it causing any issues either.
Topic: [SOLVED] Daemon logging broken with /var on a separate encrypted device (Read 1139 times)
previous topic - next topic