As per $summary, I run tor, stable version; from my shell: amd64box ~ # /etc/init.d/tor status * status: stopped # Now is stopped amd64box ~ # rm -fr /var/log/tor/ # I remove log direcotry amd64box ~ # /etc/init.d/tor start tor | * Tor configuration (/etc/tor/torrc) is valid. tor | * Starting Tor ... [ !! [34m] tor | * ERROR: tor failed to start #I try to start and fails amd64box ~ # mkdir /var/log/tor # I create a directory bu won't start because it should have tor:tor permissions amd64box ~ # /etc/init.d/tor start tor | * Tor configuration (/etc/tor/torrc) is valid. tor | * Starting Tor ... [ !! ] tor | * ERROR: tor failed to start amd64box ~ # chown tor:tor /var/log/tor/ #change permission amd64box ~ # /etc/init.d/tor start tor | * Tor configuration (/etc/tor/torrc) is valid. tor | * Starting Tor ... [ ok ] #Now it works
I've been talking with WilliamH and others, and we're not sure about whether the init scripts should be responsible for creating /var/log. My gut reaction is that, if a file or directory is installed by the ebuild and the user deletes it, then expect breakage. I know some people mount /var/log as a tmpfs system, but I think this is done at one's own risk. I'm cc-ing the base-system herd to see what the general consensus is. I'm not sure if there's a POSIX standard here.
POSIX says nothing of filesystem layout. we're not talking about /var/log/ here, but /var/log/tor/. i wonder why tor is even writing to logs itself. it should be using syslog like any sane daemon.
(In reply to comment #2) > POSIX says nothing of filesystem layout. we're not talking about /var/log/ > here, but /var/log/tor/. > > i wonder why tor is even writing to logs itself. it should be using syslog > like any sane daemon. It can log via syslog. The choice is there to log to file or syslog, probably because of windows. You're right though, we should switch to using syslog, not just for this bug, but for other reasons. I'll get that into a future rev bump.
so let's default to sysloging, and if the user wants to modify their config to log elsewhere, it's now their problem to make sure the relevant dirs exist :)
Okay, I just committed tor-0.2.2.32-r1 and tor-0.2.3.2_alpha-r3. Both of these use syslog for logging and don't even try to create /var/log/tor. Also, to avoid the same problem with /var/run/tor, I added checkvarrun() to the init script. The ebuild still creates /var/run/tor and gives it the correct ownership/perms, but in case it gets deleted (eg /var/run is tmpfs) the init scripts will recreate it. Please test, especially since upstream just bumped their stable from 0.2.1 to 0.2.2 branch. This means tor-0.2.2.32-r1 is the next candidate for stabilization in 30 days. Lots of stuff changing here, so I'd like it well tested before I submit a stablereq. (Luckily there's not CVE against current stable so there's no rush, unlike in the past.)
The bug stills with metalog, with its default configuration, so probably it should be changed from default?
no idea what you're talking about wrt metalog
Ok, tor starts and runs well, but there isn't /var/log/tor
(In reply to comment #8) > Ok, tor starts and runs well, but there isn't /var/log/tor Correct. It logs to syslog. For metalog, look in /var/log/everything/current. Also, I switched from my own home grown check for /var/run/tor to openrc's checkpath. Can you test the next two version bumps as well? Thanks.
FIXED (In reply to comment #9) > Can you test the next two version bumps as well? Thanks. Will be done ;)
