Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#32422 - [unbound] systemd service needs

Attached to Project: Community Packages
Opened by Arthur Țițeică (roentgen) - Saturday, 03 November 2012, 12:53 GMT
Last edited by Gaetan Bisson (vesath) - Wednesday, 14 November 2012, 02:44 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



Unbound service always fails when booting the system most probably because it starts before the network

systemctl status unbound.service shows:

unbound[339:0] warning: too many file descriptors requested. The builtinmini-event cannot handle more than 1024. Config for less fds or compile with libevent
unbound[339:0] warning: continuing with less udp ports: 296
unbound[339:0] error: can't bind socket: Cannot assign requested address
unbound[339:0] debug: failed address port 53
unbound[339:0] fatal error: could not open ports

Starting the service afterwards is fine.

Additional info:
unbound 1.4.18-2
This task depends upon

Closed by  Gaetan Bisson (vesath)
Wednesday, 14 November 2012, 02:44 GMT
Reason for closing:  Won't implement
Comment by Gaetan Bisson (vesath) - Sunday, 04 November 2012, 05:12 GMT
With the default configuration (binding, there is no need for
Comment by Gaetan Bisson (vesath) - Sunday, 04 November 2012, 05:13 GMT
Well, the default listens to localhost only, my mistake.

But my point stands: if you change /etc/unbound/unbound.conf, you are also expected to adapt /etc/systemd/system/unbound.service accordingly...
Comment by Arthur Țițeică (roentgen) - Wednesday, 07 November 2012, 19:37 GMT
In my opinion daemons which provide network services should depend on the by default regardless of their default/initial configuration.
Comment by Gaetan Bisson (vesath) - Wednesday, 14 November 2012, 02:44 GMT
In my opinion daemons that do not require network connectivity to be started should not wait for network connectivity to be started...