Privoxy won´t start

Installed privoxy and it works fine. However I cannot get it to auto-start. At first I went into the webinterface and put "/opt/sbin/privoxy /opt/etc/privoxy/config" in scripts. This works from the cmd-line. But it doesnt start.
So I created a script in /opt/etc/init.d which also works if I run it from the cli.

This doesnt work either. So I started messing around with screen. It seems it cant find the configfile. Youstart privoxy by
"/sbin/opt/privoxy /opt/etc/privoxy/config" and when I do "screen /sbin/opt/privoxy /opt/etc/privoxy/config" it says it cant find the file. Both files are there, I can run the command manually and /sbin/opt is not in the path. Not sure why that would matter since I write it manually.. butt...

Look very, very carefully at what $DAEMON gets expanded to, then compare that to what you said in this post:

You start privoxy by "/sbin/opt/privoxy /opt/etc/privoxy/config" and when I do "screen /sbin/opt/privoxy /opt/etc/privoxy/config" it says it cant find the file.

Click to expand...

So is it /sbin/opt/privoxy or is it /opt/sbin/privoxy? I think it's the latter (which would mean your sh script is probably fine), but the inconsistency could explain the problem if the binary is truly in /sbin/opt.

Furthermore, are you sure /opt is truly and immediately available after you reboot the router + init script stsart? I've found that /opt mounts are usually not available immediately (even if put in WAN Up section), especially if CIFS/SMB is in use. It takes some time (maybe 10-15 seconds, but it varies -- keep reading) before the system gets around to mounting it.

The problem may be that your /opt filesystem is not available by the time the script runs automatically (hence "file not found"), but is obviously available by the time you telnet/SSH in. There is no way to solve this problem sanely; people who recommend using sleep N are not thinking about this problem correctly (N is not going to work for everyone, given different models of routers, network configurations, use/disuse of VLANs, etc.).

I dealt with a very similar situation on FreeBSD not too long ago (daemons like ntpd and named coming up before the actual network usable -- ifconfig shows interface up but the ACTUAL NETWORK isn't working yet), and as such I wrote a very extensive and well-tested script to solve the problem which was committed to FreeBSD officially. It's called netwait.

Politely (no negative intentions, honest!): you gotta think about all these things when working on embedded systems.

You should try changing your script to this (honestly), reboot the router, then see what /tmp/output contains:

P.S. -- Do not, under any circumstance, bring GNU screen into the picture! privoxy starts as a daemon unless you run it with --no-daemon (here's the documentation) so there is literally no purpose to using GNU screen to "background the process". Furthermore, if you want to background a process on Linux, use the nohup command. On FreeBSD, use the daemon command (it behaves differently than nohup; rather not explain the difference, outside of the context of this thread).

P.P.S -- You should really be making use of the --pidfile argument (to write a pidfile to /var/run, e.g. /var/run/privoxy.pid) and use kill `cat /var/run/privoxy.pid` in your stop script, and avoid use of killall. Using killall as root can be deadly; it kills all processes on the system (not just one!), for all users, that match whatever substring you give it. killall is "convenient", but is a very bad utility to get in the habit of using. And on Solaris, killall kills ALL SYSTEM PROCESSES, including init (which then reboots the machine) -- it does not behave anywhere near Linux and BSD killall. So again, don't use killall; this is what pidfiles are for!

P.P.P.S. -- You have variables in your script which aren't double-quoted (such as $DAEMON). You should fix that. It matters if someone ever tries to use your script with a path that has spaces in the filename and is good practise.