Posted: Fri Nov 16, 2012 4:52 pm Post subject: How is /run supposed to be set up correctly?

I'm having problems with two different machines that I let the /run auto-migration thing happen on. Several services aren't starting up due to not having permission to write pidfiles. This started after a reboot and going from 3.5.x to 3.6.x.

I've tried giving /run a mode=1777 in fstab (which seems to be completely ignored), and doing the same with chmod, but that only seems to make more things break. I don't have these problems on my desktop, but that's running a different set of services.

I just noticed the same. I would prefer to have it has /var/run, since on my setup / is an SSD drive, and /var is a regular hard disk. It was silently done, wouldn't have noticed if I didn't read rc.log

Creating dirs in /run is a job for tmpfiles. Ideally it should be provided by the auditd package, but until that happens create the file yourself:

/usr/lib/tmpfiles.d/auditd.conf

Code:

d /run/lock/subsys 1777 root root -

Adjust permissions (the third parameter) and user/group if needed. tmpfiles is a systemd thingy, but OpenRC has a shell implementation of it. To learn more about it: http://0pointer.de/public/systemd-man/tmpfiles.d.html - the openrc implementation ignores the "age" parameter.

Creating dirs in /run is a job for tmpfiles. Ideally it should be provided by the auditd package, but until that happens create the file yourself:

/usr/lib/tmpfiles.d/auditd.conf

Code:

d /run/lock/subsys 1777 root root -

Adjust permissions (the third parameter) and user/group if needed. tmpfiles is a systemd thingy, but OpenRC has a shell implementation of it. To learn more about it: http://0pointer.de/public/systemd-man/tmpfiles.d.html - the openrc implementation ignores the "age" parameter.

The bad thing is I am running amd64 not ~amd64, simple bugs like this should have been squashed before hitting the stable tree._________________Who controls the past now, controls the future
Who controls the present now, controls the past.