/var/run symlink replaced by directory after reboot

Question

Hi guys!
I have installed Arch on my home server a few days ago using the latest (2012.06) iso available (not the net install).
My boot, root and swap partitions are all mdadm raid 1 and i use syslinux to boot which works fine.
After setting up my machine for a while i noticed the "filesystem" package was not properly installed by pacstrap (even though it's already pretty old and should be included in the latest iso). Don't get me wrong it WAS installed, but only the /var/lock directory was symlinked. As most of you know this package update should replace /var/run and /var/lock with symlinks.
So i just tried to "reinstall" this package with 'pacman -S filesystem --force' (as described in the news post).
At first it looked great - symlinks were there and i could start several services with systemctl (which didn't work for a lot of services before), but get this:
After every reboot or simply after some time the symlink (just of /var/run , not lock) was GONE and a file (not directory) "run" gets created with the following permissions - -rw------- root root. What happens is that at every reboot systemd-logind dbus and therfor most other stuff won't get started properly. For example after boot i had only just the terminal at F1, all other screens were just black and after some time i get the message that systemd-logind.service failed.
When i manually remove the file and replace it by the symlink i can manually start/restart all services and from that time on everything works great.
What i was interested in was WHAT exactly removed my symlink after some time or at boot time, so i used audit to monitor the symlink for  a while.
Here's what i got when the symlink was removed and then a file "run" was "touched": http://pastebin.com/BYsRHWbC
Unfortunately the ppid ( i guess "parent process id") was not running anymore so i still don't have any idea what's going on exactly.
I'd appreciate ANY information or tip you have. My guess is that systemd is involved somehow.
As a sidenote: Before i found out the symlink was missing i installed initscripts once to see of systemd was just still buggy. I removed it shortly after though.
Looking forward to input and I'm happy to answer your questions.
Last edited by Guybrush (2012-10-25 17:19:49)

Answer 1

Isn't Shorewall is just a collection of scripts that load iptables rules? Even the Shorewall binary is just a shell script, so you can easily `grep` through it and the config/helper files that make up Shorewall to see what it's up to.
Looks like the only time it messes with `touch` is here:
root@antec /etc/shorewall# grep -R touch /usr/share/shorewall/*
/usr/share/shorewall/prog.footer: touch $STARTUP_LOG
/usr/share/shorewall/prog.footer: [ -n "$SUBSYSLOCK" ] && touch $SUBSYSLOCK
/usr/share/shorewall/prog.footer: [ $status -eq 0 ] && touch $SUBSYSLOCK || rm -f $SUBSYSLOCK
/usr/share/shorewall/prog.footer: [ $status -eq 0 ] && touch $SUBSYSLOCK || rm -f $SUBSYSLOCK
So.. maybe your shorewall.conf file has set SUBSYSLOCK to something invalid, like /var/run, and it's wiping it out each time when it checks for the PID lock file?
I was able to get Shorewall to run and put its PID file in SUBSYSLOCK=/var/lock/shorewall
It didn't mess with /run or /var/run at all.
Had to change the systemd 'shorewall.service' file quite a bit though. It's not correct at all.