Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

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!
Tasklist

FS#38467 - [polipo] DNS error -> simple fix for polipo.service

Attached to Project: Community Packages
Opened by kvtb (kvtb) - Saturday, 11 January 2014, 18:59 GMT
Last edited by Thorsten Töpper (Atsutane) - Tuesday, 14 January 2014, 19:34 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Thorsten Töpper (Atsutane)
Jelle van der Waa (jelly)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The wiki page on polipo https://wiki.archlinux.org/index.php/Polipo
contains a Troubleshouting section, with three (ugly) ways to workaround a DNS error if polipo starts before the network is fully up.

However, I think the real fix is quite simple, and is simply adding 1 line to the systemd service file provided in the pkg.

Namely, add the following line to the [Unit] section of polipo.service:

Wants=network-online.target


When this line is added to the polipo.service file, the DNS problem should be fixed...
This task depends upon

Closed by  Thorsten Töpper (Atsutane)
Tuesday, 14 January 2014, 19:34 GMT
Reason for closing:  Upstream
Additional comments about closing:  Took also a closer look at it and I agree with Dave.
Comment by Dave Reisner (falconindy) - Sunday, 12 January 2014, 05:32 GMT
This can't possibly fix anything. Presumably you meant After, not Wants. I'd still be suspicious because there's nothing short of a custom written unit which will provide network-online.target.
Comment by kvtb (kvtb) - Sunday, 12 January 2014, 10:06 GMT
If you're right, then I do not understand why adding that line works for me.
After your comment, I did some digging and found this:

man systemd.special(7)

network-online.target
Units that strictly require a configured network connection should pull in network-online.target (via a Wants= type dependency) and order themselves after it. This target unit is intended to pull in a service that delays further execution until the network is sufficiently set up. What precisely this requires is left to the implementation of the network managing service.

Note the distinction between this unit and network.target. This unit is an active unit (i.e. pulled in by the consumer rather than the provider of this functionality) and pulls in a service which possibly adds substantial delays to further execution. In contrast, network.target is a passive unit (i.e. pulled in by the provider of the functionality, rather than the consumer) that usually does not delay execution much. Usually, network.target is part of the boot of most systems, while network-online.target is not, except when at least one unit requires it. Also see Running Services After the Network is up for more information.

All mount units for remote network file systems automatically pull in this unit, and order themselves after it. Note that networking daemons that simply provide functionality to other hosts generally do not need to pull this in.
Comment by Dave Reisner (falconindy) - Sunday, 12 January 2014, 14:12 GMT
Yes the key here is the last sentence of the first paragraph: "What precisely this requires is left to the implementation of the network managing service."
Comment by Dave Reisner (falconindy) - Sunday, 12 January 2014, 17:21 GMT
network-manager-online.service seems to pull in network-online.target. So, users of network-manager will benefit from this (probably no one else).

A better solution would be to file a bug upstream for polipo to implement support for dynamic binding.

Loading...