Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#32246 - [privoxy] Doesn't work in systemd

Attached to Project: Community Packages
Opened by Natanji (Natanji) - Saturday, 27 October 2012, 11:22 GMT
Last edited by Lukas Fleischer (lfleischer) - Saturday, 10 November 2012, 01:04 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Lukas Fleischer (lfleischer)
Architecture x86_64
Severity Critical
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No


I just switched my system to systemd (alongside initscripts which I didn't yet uninstall). The systemd privoxy unit doesn't start privoxy; the command used in the unit file just exits with error status 1. There is no error message from privoxy itself, sadly, so I have no real idea what went wrong.

Privoxy is definitely configured correctly: via old initscript's "rc.d start privoxy", everything works fine!

Here is what systemd says about the service output:

$ systemctl status privoxy.service
privoxy.service - Privoxy Web Proxy With Advanced Filtering Capabilities
Loaded: loaded (/usr/lib/systemd/system/privoxy.service; disabled)
Active: failed (Result: exit-code) since Sat, 2012-10-27 13:02:09 CEST; 28s ago
Process: 2357 ExecStart=/usr/sbin/privoxy --pidfile /run/ --user privoxy.privoxy /etc/privoxy/config (code=exited, status=1/FAILURE)
CGroup: name=systemd:/system/privoxy.service

Additional info:
* package version(s): privoxy 3.0.19-6 (didn't test others)
* Privoxy log file is empty

Steps to reproduce:
# systemctl start privoxy
This task depends upon

Closed by  Lukas Fleischer (lfleischer)
Saturday, 10 November 2012, 01:04 GMT
Reason for closing:  Not a bug
Additional comments about closing:  "/var/log/" on a tmpfs isn't officially supported.
Comment by Lukas Fleischer (lfleischer) - Saturday, 03 November 2012, 08:03 GMT
Which systemd version do you use? Did you use some custom configuration options (user, group, config file, command line options) in "/etc/conf.d/" (which is no longer sourced when systemd is used)? Could you run `systemctl status privoxy.service` as root (or as a user that belongs to the adm group) and check if some journal lines are appended?
Comment by Natanji (Natanji) - Saturday, 03 November 2012, 09:39 GMT
I have never used /etc/conf.d/ and didn't even know that this directory is there (what does it belong to, if not systemd?); all my configuration was done in /etc/privoxy/config (I have removed the package, reinstalled it and restored only my old config file; no change to the problem).

Running "systemctl status privoxy.service" as root does not append a single journal line.
Comment by Natanji (Natanji) - Saturday, 03 November 2012, 09:56 GMT
Oh, I forgot: I am on the most recent systemd version, which is 195-2.
Comment by Lukas Fleischer (lfleischer) - Saturday, 03 November 2012, 17:02 GMT
Could you start Privoxy running `/usr/sbin/privoxy --no-daemon --pidfile /run/ --user privoxy.privoxy /etc/privoxy/config` (as root) and see if that reveals anything useful?
Comment by Natanji (Natanji) - Saturday, 03 November 2012, 18:16 GMT
That command works and prints normal privoxy startup messages. But without the --no-daemon, it simply exits without printing anything. The systemd service seems to start privoxy without --no-daemon and thus fails to start, I guess.
Comment by Lukas Fleischer (lfleischer) - Saturday, 03 November 2012, 18:26 GMT
Are you sure it really exits? Could you check if `pidof privoxy` or `pgrep privoxy` print any PID after the command is executed, please?
Comment by Natanji (Natanji) - Saturday, 03 November 2012, 18:29 GMT
Yea, I checked with pidof privoxy, pgrep privoxy and ps ax | grep privoxy. Nothing turns up. It definitely exits, I think even without trying to fork. Here is an strace:
Comment by Lukas Fleischer (lfleischer) - Saturday, 03 November 2012, 19:18 GMT
The strace doesn't reveal any useful information -- there is a clone() syscall in the last 10 lines of the log. Are there any log entries in "/var/log/privoxy/logfile"?
Comment by Natanji (Natanji) - Sunday, 04 November 2012, 08:45 GMT
Nope, neither the logfile nor even that log directory are created when the program is run with --no-daemon...
Comment by Natanji (Natanji) - Tuesday, 06 November 2012, 11:03 GMT
I might have found the problem: the privoxy service file merely calls privoxy, while the rc.d initscript first checks if the logfile/log directory exists and creates them if needed. If I first start privoxy with the rc.d script once, the systemd service will work afterwards. So I propose that the service file should also take care of creating the directory and logfile, just like the rc.d script.
Comment by Lukas Fleischer (lfleischer) - Thursday, 08 November 2012, 15:19 GMT
Well, "/var/log/privoxy/" is part of the privoxy package, so it would be interesting to trace back how it was deleted in the first place...
Comment by Natanji (Natanji) - Friday, 09 November 2012, 08:39 GMT
That's simple: /var/log is on tmpfs for me, so after a reboot, everything is gone. I thought the consensus was that /var/log directories could be on tmpfs and no package should depend on files in that directory being there.
Comment by Kyle Keen (keenerd) - Friday, 09 November 2012, 14:39 GMT
It would have been nice to hear that minor detail a little sooner. If I had to hazard a guess, we probably won't add support for your particular circumstance. Because it is rare (well, I have var on tmpfs too but folks like us are weird) and because it is easy to work around. After mounting var but before starting up any services, run

mkdir -p $(pacman -Qql | grep '^/var/log/.*/$')

I'm sure someone will say this is a very ugly hack (at the very least it needs a chmod or two) and will provide a better method.
Comment by Lukas Fleischer (lfleischer) - Saturday, 10 November 2012, 01:03 GMT
I'll close this as "Not a bug". Putting "/var/log/" on a tmpfs isn't officially supported -- you can use tmpfiles.d (or a script) to create the missing directories on every reboot.