(In reply to comment #0)
> I believe this is because Privoxy starts before the network (lo) is brought up

I find this unlikely because the loopback interface is brought up by systemd itself during a very early phase of boot.

> The message in the log "Fatal error: can't bind to 127.0.0.1:8118: The hostname
> is not resolvable" is I believe a red herring as localhost is listed in
> /etc/hosts (as is the FQDN for the local machine).

To rule out the possibility, see if installing the nss-myhostname package fixes it.

> Steps to Reproduce:
> 1. Install Privoxy
> 2. Add it to the start up list (systemctl enable privoxy.service)
> 3. Reboot.

works for me

On a second reboot I managed to reproduce it.

privoxy's log shows:

Jun 07 22:58:31.595 7fed949d4720 Info: Listening on port 8118 on IP address 127.0.0.1
Jun 07 22:58:31.595 7fed949d4720 Error: Can not resolve 127.0.0.1: Address family for hostname not supported
Jun 07 22:58:31.595 7fed949d4720 Fatal error: can't bind to 127.0.0.1:8118: The hostname is not resolvable

The problem is not about the loopback device, which is correctly configured all the time, but about the real interface - eth0 in my case.

NetworkManager is started and begins to configure eth0. eth0 gets an IPv6 link-scope address immediately. DHCP is used to configure IPv4, so it takes some time before eth0 gets an IPv4 address.
During the time window privoxy is started and does getaddrinfo("127.0.0.1", ...) with the AI_ADDRCONFIG flag. This fails with the error EAI_ADDRFAMILY.

I don't know if that's the expected behavior of getaddrinfo().

Maybe privoxy should just lose the AI_ADDRCONFIG in bind_port().

OK, so as in the previous bug, the fix is indeed to enable the network service.

systemctl enable network.service

but still, it seems that privoxy should start "out of box", post install, on the default port, without having to configure it or enable the network service.

or enable NetworkManager-wait-online.service and that causes network.target to be triggered only after the network is really up

(In reply to comment #4)
> the fix is indeed to enable the network service.

Well, to be precise: it's a workaround, not a fix.

To fix this, privoxy should remove the AI_ADDRCONFIG flag used in bind_port() because the administrator decides exactly what protocol to use by specifying the listen-address option. privoxy should not try to outsmart the administrator.

As an additional improvement privoxy should use the IP_FREEBIND socket option to allow the configuration "listen-address 192.168.0.1:8118" to start regardless of the ordering with respect to the network service.

I have now had this bug once in F16 with privoxy 3.0.16 (also there's another closed bug #694597 for this):

-----
Jan 24 12:59:56.555 7f84553e0700 Fatal error: can't bind to 127.0.0.1:8118: The hostname is not resolvable
-----

As noted above there appears to be a problem with Privoxy trying to connect to the loopback device has been set up by Network-Manager. It seems unclear whether Privoxy will be adopting the suggested changes by Michal Schmidt above:

http://sourceforge.net/tracker/index.php?func=detail&aid=3349356&group_id=11118&atid=111118

As a workaround and a positive adoption of Fedora standards, could I suggest Fedora adopting a System.d service to replace the init.d service included by the Privoxy devs? It should be possible I think to automatically start the privoxy service after Network-Manager has started and therefore 'lo' has been set up.   

I think this should be done at a Fedora level as Privoxy appear to think that system.d support should be handled at a distribution level:

http://sourceforge.net/tracker/index.php?func=detail&aid=3399928&group_id=11118&atid=361118

Such a system.d service appears to be extremely straight forward:

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=privoxy.service;att=1;bug=639635

(In reply to comment #7)
> As a workaround and a positive adoption of Fedora standards, could I suggest
> Fedora adopting a System.d service to replace the init.d service included by
> the Privoxy devs? It should be possible I think to automatically start the
> privoxy service after Network-Manager has started and therefore 'lo' has been
> set up.   
> 
> I think this should be done at a Fedora level as Privoxy appear to think that
> system.d support should be handled at a distribution level:

Well upstream really should be shipping unit files more and more GNU/Linux distro are picking up systemd as their init system
 
> Such a system.d service appears to be extremely straight forward:
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=privoxy.service;att=1;bug=639635

*cough*....*cough*

You can find proper unit file for privoxy in bug 784090

(In reply to comment #8)

> Well upstream really should be shipping unit files more and more GNU/Linux
> distro are picking up systemd as their init system

Yes, absolutely. But since they're not going to should Fedora not fix currently broken package, through this small step?

> *cough*....*cough*
>
> You can find proper unit file for privoxy in bug 784090

Yes exactly as I said it is a simple service file for system.d.

Units are not allowed to be introduced into GA releases 

What that means that units that get shipped for rawhide now wont be in F15 and F16 but only in F17 unless the maintainer request to be granted an exception from fesco but that's something you need to convince the privoxy maintainer to do.

(In reply to comment #10)

I'm sorry I'm only a user of Fedora trying to see that a sensible response is given to this problem which I have researched to see if there is a proposed solution for Fedora and found that I couldn't find one. 

> Units are not allowed to be introduced into GA releases 
>
> What that means that units that get shipped for rawhide now wont be in F15 and
> F16 but only in F17 unless the maintainer request to be granted an exception
> from fesco but that's something you need to convince the privoxy maintainer to
> do.

I don't entirely follow what you mean by this but I guess you are saying that it is not possible to include a privoxy.service file into the packages for F15 or F16 without permission from the privoxy maintainer. 

I certainly don't think it is my position to negotiate on behalf of Fedora for privoxy to allow this. If this is the case then it seems reasonable to include this file for F17. Are you saying this is likely to happen, or are you saying another bug report needs to be filled out?

(In reply to comment #11)
> (In reply to comment #10)
> 
> I don't entirely follow what you mean by this but I guess you are saying that
> it is not possible to include a privoxy.service file into the packages for F15
> or F16 without permission from the privoxy maintainer. 

Yes the maintainer of the privoxy has to contact fesco and ask for a permission to introduce the unit files into both F15 and F16 release.
 
> I certainly don't think it is my position to negotiate on behalf of Fedora for
> privoxy to allow this. If this is the case then it seems reasonable to include
> this file for F17. Are you saying this is likely to happen, or are you saying
> another bug report needs to be filled out?

Nope no need for you to file another report the unit file is in bug 784090 and now it's up to the maintainer to package it and ship it. 

You could comment on that bug if you have tested it and it works for you as you expect which might help it getting package sooner.

(In reply to comment #12)

Thank you. I will try the service and post response in bug 784090.

This BZ has a solution that does not involve migrating to a native systemd unit. It is possible to express needed dependencies in the SysV initscript using LSB headers.

Getting rid of that AI_ADDRCONFIG in bind_port() requires no talking to FESCo either.

(In reply to comment #14)

Hi, Michal. As posted above the privoxy devs do appear to be aware of this approach (and even this bug report): 

http://sourceforge.net/tracker/index.php?func=detail&aid=3349356&group_id=11118&atid=111118

It just seams that they are unsure about implementing it. It seems sensible to work around the problem in the meantime since system.d unit files will prevent it and are being adopted by Fedora over SysV anyway.

It seems they already implemented it.
From the changelog of privoxy 3.0.18:

  - Fixed bind failures with certain GNU libc versions if no non-loopback
    IP address has been configured on the system. This is mainly an issue
    if the system is using DHCP and Privoxy is started before the network
    is completely configured.
    Reported by Raphael Marichez in #3349356.
    Additional insight from Petr Pisar.

This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping