privoxy: launched too early

[lagrave+bugs+macosforge.org@…]

​https://sourceforge.net/p/ijbswa/support-requests/1661/ is a bugreport that apparantly should be reported here rather than to Privoxy.

"Privoxy fails to startup since it tries to launch before my machine has an IP. Not sure if this is a bug or user error but maybe it should be in the FAQ?

2014-07-08 08:42:26.960 00000110 Fatal error: can't bind to 192.168.1.2:8118: Can't assign requested address

This is Privoxy from MacPorts."

'Thanks for the report, but "Privoxy from MacPorts" likely is launched with an OS-X-specific mechanism (launchd?), in which case the problem should be reported to the MacPorts people. In general Privoxy shouldn't be started before the addresses it's supposed to listen on (in your case 192.168.1.2) are available.

Changing the listen-address to "0.0.0.0:8118" may be a workaround, but whether it'll allows clients to reach Privoxy at addresses that weren't available (yet) when Privoxy was started depends on the operating system and you may want to use ACLs to control which clients are served by Privoxy.'

[ryandesign (Ryan Carsten Schmidt)]

There may be a key that could be added to the launchd plist to ensure the network is up first. However, I would be surprised if MacPorts doesn't do that already (since we have lots of other network daemon ports using these launchd plists and I haven't heard any other complaints), and if it doesn't, MacPorts doesn't yet offer a mechanism for ports to add arbitrary keys (see #13807).

[lagrave+bugs+macosforge.org@…]

The slightly unusual with my situation is that I have the daemon/privoxy to answer on 192.168.1.2 rather than 127.0.0.1, the latter which I guess becomes available much earlier in the boot sequence. Could that explain why this is "underreported"?