Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

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

FS#41593 - [ntp] ./../lib/isc/unix/ifiter_getifaddrs.c:96: unexpected error:

Attached to Project: Arch Linux
Opened by Ruben Kelevra (RubenKelevra) - Sunday, 17 August 2014, 19:01 GMT
Last edited by Gaetan Bisson (vesath) - Saturday, 30 August 2014, 02:23 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Gaetan Bisson (vesath)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
NTP outputs following log-messages:

Aug 17 20:51:09 bragi.wk.freifunk.net ntpd[1455]: getting interface addresses: getifaddrs: Resource temporarily unavailable
Aug 17 20:51:15 bragi.wk.freifunk.net ntpd[1455]: ./../lib/isc/unix/ifiter_getifaddrs.c:96: unexpected error:
Aug 17 20:51:15 bragi.wk.freifunk.net ntpd[1455]: getting interface addresses: getifaddrs: Resource temporarily unavailable
Aug 17 20:51:43 bragi.wk.freifunk.net ntpd[1455]: ./../lib/isc/unix/ifiter_getifaddrs.c:96: unexpected error:
Aug 17 20:51:43 bragi.wk.freifunk.net ntpd[1455]: getting interface addresses: getifaddrs: Resource temporarily unavailable
Aug 17 20:51:53 bragi.wk.freifunk.net ntpd[1455]: ./../lib/isc/unix/ifiter_getifaddrs.c:96: unexpected error:
Aug 17 20:51:53 bragi.wk.freifunk.net ntpd[1455]: getting interface addresses: getifaddrs: Resource temporarily unavailable
Aug 17 20:52:08 bragi.wk.freifunk.net ntpd[1455]: ./../lib/isc/unix/ifiter_getifaddrs.c:96: unexpected error:
Aug 17 20:52:08 bragi.wk.freifunk.net ntpd[1455]: getting interface addresses: getifaddrs: Resource temporarily unavailable


Config file:
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org

# Only allow read-only access from localhost
restrict default noquery nopeer
restrict 127.0.0.1
restrict ::1

# Location of drift file
driftfile /var/lib/ntp/ntp.drift

Version:
Name : ntp
Version : 4.2.7.p446-1
Beschreibung : Network Time Protocol reference implementation
Architektur : x86_64
URL : http://www.ntp.org/
Lizenzen : custom
Gruppen : Nichts
Stellt bereit : Nichts
Hängt ab von : openssl libcap libedit
Optionale Abhängigkeiten: Nichts
Benötigt von : rk-server-basic
Optional für: Nichts
Konflikt mit : Nichts
Ersetzt : Nichts
Installationsgröße: 4004,00 KiB
Packer : Gaetan Bisson <bisson@archlinux.org>
Erstellt am : So 29 Jun 2014 18:42:31 CEST
Installiert am : Sa 05 Jul 2014 07:49:07 CEST
Installationsgrund : Installiert als Abhängigkeit für ein anderes Paket
Installations-Skript : Ja
Verifiziert durch: Signatur

This task depends upon

Closed by  Gaetan Bisson (vesath)
Saturday, 30 August 2014, 02:23 GMT
Reason for closing:  No response
Comment by Gaetan Bisson (vesath) - Monday, 18 August 2014, 01:12 GMT
Looks like you have something funny with your network configuration; I'm not sure what, though...
Comment by ojab (ojab) - Tuesday, 26 August 2014, 12:55 GMT
I'm not using arch, but have had the same issue. So JFYI: I've had server names (not IPs) in ntpd.conf and ntpd's blocking_getaddrinfo() for name resolution have failed somehow.
Issue was solved after I've replaced hostnames with IPs in ntpd.conf or if nscd was started before ntpd.

Still digging to find how it supposed to work though.
Comment by ojab (ojab) - Tuesday, 26 August 2014, 12:59 GMT
related lines from `sudo /usr/sbin/ntpd -g -u ntp:ntp -n -D 99`:
blocking_getaddrinfo given node ntp.ix.ru serv ntp fam 0 flags 0
blocking_getaddrinfo given node ntp2.vniiftri.ru serv ntp fam 0 flags 0
intres: EAI_SYSTEM errno 11 (Resource temporarily unavailable) means try again, right?
intres: resolver returned: System error (-11), retrying
blocking_getaddrinfo given node ntp.aas.ru serv ntp fam 0 flags 0
intres: EAI_SYSTEM errno 11 (Resource temporarily unavailable) means try again, right?
intres: resolver returned: System error (-11), retrying
sleep until 16:58:27 scheduled at 16:58:19 (>= 03:00:00)
intres: EAI_SYSTEM errno 11 (Resource temporarily unavailable) means try again, right?
intres: resolver returned: System error (-11), retrying
Comment by ojab (ojab) - Tuesday, 26 August 2014, 13:39 GMT Comment by ojab (ojab) - Tuesday, 26 August 2014, 14:45 GMT
`--without-threads` fixes the issue, seems that something is broken in ntpd's linux threaded resolver.
Comment by Gaetan Bisson (vesath) - Tuesday, 26 August 2014, 16:16 GMT
What OS do you use and what version of ntp? I just updated Arch to ntp-4.2.7.p465-1. If the issue persists could you report this issue upstream?
Comment by ojab (ojab) - Tuesday, 26 August 2014, 17:05 GMT
Linux from scratch/ntpd-4.2.7-p465. Don't know what exactly to report yet, hope that Ruben Kelevra will confirm my guesses (since he's only one whom I've googled with the same issue).

Looks like resolving issue is just a coincidence in my case. So there is theory #2.

If ntpd is started with `-n` (no fork), log looks like:
26 Aug 20:24:01 ntpd[18758]: Listening on routing socket on fd #31 for interface updates
26 Aug 20:24:32 ntpd[18758]: ./../lib/isc/unix/ifiter_getifaddrs.c:103: unexpected error:
26 Aug 20:24:32 ntpd[18758]: getting interface addresses: getifaddrs: Resource temporarily unavailable
26 Aug 20:24:34 ntpd[18758]: fatal out of memory (4048 bytes)

and crash is the error handling done wrong.
Routing socket (fd #41) is opened as (./ntpd/ntp_io.c):
int fd = socket(PF_NETLINK, SOCK_RAW, NETLINK_ROUTE);

but cap_net_raw is not enabled, so we can't use SOCK_RAW socket.

Ruben, can you try the attached patch? I doesn't remove the warning here, but ntpd no longer crashes.
Comment by ojab (ojab) - Tuesday, 26 August 2014, 23:03 GMT
Upstream bug with [I think] proper patch: http://bugs.ntp.org/show_bug.cgi?id=2646

Sorry for hijacking this bug, just needed to discuss it with someone ._.
Comment by Gaetan Bisson (vesath) - Saturday, 30 August 2014, 02:22 GMT
Glad you got it figured out. And since Ruben never replied I'll close this report. Cheers.

Loading...