Tor fails to start if the /var/run/tor folder is missing or not chowned to tor:tor (like, for instance, when it's mounted by tmpfs on boot). Tor's initscript should check the folder and create it if missing. sys-apps/dbus initscript already does this, so I think it should be valid and easy to accomplish. Something like this under start() should do the job: # We need to test if /var/run/tor exists, since script will fail if it does not [ ! -e /var/run/tor ] && mkdir /var/run/tor && chown tor:tor /var/run/tor
Oh, and maybe it would a good idea to check the user/group tor runs with first in the config file and chown according to that.
(In reply to comment #0) > Tor fails to start if the /var/run/tor folder is missing or not chowned to > tor:tor (like, for instance, when it's mounted by tmpfs on boot). Does not make any sense to add this to various packages, tmpfs on /var/run breaks lot of other stuff. If anything, saving and restoring the volatile tmpfs structure of /var/run should be done in openrc (already does something similar for /tmp in /etc/init.d/bootmisc)
For an illustration of why tmpfs on /var/run is a bad idea on Gentoo ATM, see this (that's on a pretty minimal desktop): # qfile $(ls -d $(find /var/run/* -maxdepth 1 -type d)) net-print/cups (/var/run/cups) net-print/cups (/var/run/cups/certs) sys-apps/hal (/var/run/hald) sys-apps/hal (/var/run/hald/hald-local) sys-apps/hal (/var/run/hald/hald-runner) sys-apps/dbus (/var/run/dbus) net-misc/radvd (/var/run/radvd) sys-libs/pam (/var/run/sepermit) app-misc/lirc (/var/run/lirc) app-misc/screen (/var/run/screen)
You've got a point there. However, dbus already does such a check. For the sake of uniformity, shouldn't either all init scripts check if their needed dirs are present or none?
(In reply to comment #2) > (In reply to comment #0) > > Tor fails to start if the /var/run/tor folder is missing or not chowned to > > tor:tor (like, for instance, when it's mounted by tmpfs on boot). > > Does not make any sense to add this to various packages, tmpfs on /var/run > breaks lot of other stuff. If anything, saving and restoring the volatile tmpfs > structure of /var/run should be done in openrc (already does something similar > for /tmp in /etc/init.d/bootmisc) No it should not. /var/run is hosed between boots. Exceptions are made for OS (not application) specific files and pid files for already running programs. I use /var/run as tmpfs on my laptop.
Created attachment 219983 [details] /etc/init.d/varrun-tarball (In reply to comment #5) > > No it should not. /var/run is hosed between boots. Yeah indeed, which is why this bug was filed. :P Anyway, attached is an initscript which do the job for you. Stick it to /etc/init.d directory and do echo 'rc_varrun_tarball="YES"' > /etc/conf.d/varrun rc-update add varrun-tarball boot You can exclude dirs from being added to the tarball like this in /etc/conf.d/varrun: rc_varrun_exclude="foo bar" (all subdirs will be automagically excluded as well). HTH :)
Created attachment 219985 [details] /etc/init.d/varrun-tarball Eh, left a stray commented out line there... :D
http://www.mail-archive.com/debian-devel@lists.debian.org/msg271051.html https://bugzilla.redhat.com/show_bug.cgi?id=432818 See above for some context with other distros. Frankly, the trouble is not worth this, the contents gets wiped by /etc/init.d/bootmisc in a saner way that just dumping the entire structure of /var/run, it's leaving the dirs there safely alone and only wiping what it should. tmpfs on /var/run might my useful from some embedded stuff running on flash which you want to keep readonly or whatever, don't see any benefit for normal users.
Well, the changes for proftpd to automatically create the missing /var/run dir were committed yesterday. I say let's just add the check and be done with it. It won't hurt now, will it? Besides, you don't have to use an embedded platform to use flash disks. SSDs are all the rage these days, and every write cycle you can avoid benefits its lifetime.
As already noted on the Debian debate, going this way you end up adding stupid initscripts to stuff that doesn't need any initscript at all. Such as pol(icy)kit. If someone uses things like SELinux, mkdir -p doesn't really do the proper job either. Etc. Shrug. Just waste of time IMHO.
I would vote against against a modified initscript, but i will leave it up to the maintainers.
(In reply to comment #11) > I would vote against against a modified initscript, but i will leave it up to > the maintainers. > chiiph and I just inherited tor. I'm in agreement with Thomas, leave the initscript unmodified for the reasons stated above. The only argument in favor of fixing ownership in the init script is if /var/run is tmpfs. But then we would have problems with other packages as per Comment #3. If there is a global movement in Gentoo towards a tmpfs on /var/run, then sure. But for now, leave it.
Okay closing this bug.
