In polipo ebuilds for versions 0.9.11 and 0.9.12 the init script failed to start polipo out of the box. I believe this was due to /var/run/polipo.pid not being created and chowned by the installation process. Whether or not that's the case, I see that 0.9.11 and 0.9.12 both have a configuration option that causes polipo to create its own configuration file. Perhaps that should be used instead of the start-stop-daemon --make-pidfile option. I'm not really sure.
Hmm... "Out of the box" for me signifies "with the default configuration untouched". Yes, polipo will fail to start if you muck with pidfile, but do you really find such a "feature" useful? What reason would you have to change the pidfile location?
I shouldn't have muddled things by mentioning the config file stuff at all. Sorry about that. When I emerged 0.9.11 and tried to start it without touching anything it failed to start. I upgraded to 0.9.12 when it was in portage, and it failed to start as well. I then created the pidfile, chowned it to polipo, and 0.9.12 started fine. Some bug wrangler changed the summary of this bug to "init script fails to create." It's probably that the ebuild didn't create the pidfile during installation.
That is strange. For me, polipo (any version) works out of the box with this config file (the one that gets installed): daemonise=false diskCacheRoot=/var/cache/polipo/ proxyAddress=127.0.0.1 proxyName=localhost serverSlots=4 serverMaxSlots=8 cacheIsShared=true allowedClients=127.0.0.1 The pid file is not created by polipo, but by start-stop-daemon and is owned by root (ssd runs as root): -rw-r--r-- 1 root root 6 2007-02-11 10:34 /var/run/polipo.pid Polipo can create its own pidfile, but the default value of pidFile option is "none". The init script assumes you are not using pidFile=/var/run/polipo.pid and neither daemonise=true, cases in which the init script obviously will fail.
When ssd creates pid files in conjunction with a chuid it does the chuid before the creation of the pid file. It therefore fails to create the pidfile since the user polipo doesn't have write permissions on /var/run The key to get around this limitation is that ssd doesn't delete pid files it creates. So long as /var/run/polipo.pid is there and writable by user polipo everything should work fine. The ebuild needs to create and chown the file, though. In your installation see if you can stop polipo, delete /var/run/polipo.pid, and then start polipo again. If I'm right polipo will not start successfully.
alin init.d # ls -l /var/run/polipo.pid ls: cannot access /var/run/polipo.pid: No such file or directory alin init.d # /etc/init.d/polipo start * Starting Polipo HTTP proxy ... [ ok ] alin init.d # ls -l /var/run/polipo.pid -rw-r--r-- 1 root root 6 2007-02-11 11:01 /var/run/polipo.pid alin init.d # /etc/init.d/polipo stop * Stopping Polipo HTTP proxy ... [ ok ] alin init.d # ls -l /var/run/polipo.pid ls: cannot access /var/run/polipo.pid: No such file or directory polipo isn't aware it has a pidfile, only ssd do whatever is necessary (create,write,read,delete).
Hm, nevermind it is inexplicably working for me now. ssd is occasionally flaky; I suppose this is just one of those times.
Closed as WORKSFORME. You'll be pleased to find that I've updated the init script in cvs. Now it verifies configuration parameters before service startup.
Fine, fine, but to be clear it wasn't a configuration parameters issue. I never touched the configuration file. For anyone else who runs across this bug trying to figure out why polipo won't start, here's how I magically fixed my issue: 1) As root touch /var/run/polipo.pid 2) chown polipo /var/run/polipo.pid 3) /etc/init.d/polipo start (should start, if not this is not the bug you're looking for) 4) /etc/init.d/polipo stop 5) Delete /var/run/polipo.pid if it still exists 6) start polipo as usual No, it doesn't make any sense but there it is.
