FS#53240 - [bind] named process hangs on startup

Attached to Project: Arch Linux
Opened by Tim Dean (tpdean) - Friday, 10 March 2017, 18:31 GMT
Last edited by Sébastien Luttringer (seblu) - Tuesday, 14 March 2017, 21:27 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 22
Private No

Details

Description:

The named binary packaged in bind-9.11.0.P3-2-x86_64.pkg.tar.xz stopped working today on my server. The process seems to be hanging on startup. After a bit of debugging with strace, I found the following messages emitted prior to the hang:

seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1 EINVAL (Invalid argument)
seccomp(SECCOMP_SET_MODE_FILTER, 0, {len=35, filter=0x23fccb0}) = 0
getpid() = ?

I recompiled the source code without the --enable-seccomp configure flag, and the issue went away. Based on forum activity, I see other users having this issue as well: https://bbs.archlinux.org/viewtopic.php?id=223945

Additional info:
* package version(s)
* config and/or log files etc.


Steps to reproduce:
This task depends upon

Closed by  Sébastien Luttringer (seblu)
Tuesday, 14 March 2017, 21:27 GMT
Reason for closing:  Fixed
Additional comments about closing:  bind-9.11.0.P3-3
Comment by Tarqi Kazan (Tarqi) - Friday, 10 March 2017, 18:56 GMT
Same here. Downgrading glibc/gcc-libs helped. Compiling with the new gcc and libs may help. PS: I think this is *not* "LOW", but "URGENT".
Comment by Tim Dean (tpdean) - Friday, 10 March 2017, 23:24 GMT
This does seem to be related to the new gcc-6.3.1-2-x86_64, gcc-libs-6.3.1-2-x86_64, glibc-2.25-1, and binutils-2.28-1 packages that were pushed out today. Downgrading those packages eliminates the named hang on bind-9.11.0.P3-2.
Comment by Noel Kuntze (thermi) - Saturday, 11 March 2017, 14:10 GMT
I also hit this issue today. Please fix soon.
Comment by Patrick Goetz (pgoetz) - Saturday, 11 March 2017, 18:11 GMT
Can confirm that after updating today (March 11, 2017) named starts in a defunct state. If I run named and specify a log file like this:

# named -f -L /tmp/named.log -u named

i.e. by specifying a log file it works.

This comment posted in the Newbie Corner provides a temporary systemd fix:
https://bbs.archlinux.org/viewtopic.php?pid=1696446#p1696446
Comment by Patrick Goetz (pgoetz) - Saturday, 11 March 2017, 18:16 GMT
Please mark this as urgent. This is not a low priority issue for people running their own name service. My entire home network was shut down by this.
Comment by Sébastien Luttringer (seblu) - Sunday, 12 March 2017, 15:20 GMT
Downgrading only gblic to 2.24-2 fix the issue. Building a new version of bind against 2.25 doesn't help, neither using libseccomp from testing.
Comment by Allan McRae (Allan) - Monday, 13 March 2017, 01:11 GMT
The following commit removed PID caching in glibc.
https://sourceware.org/git/?p=glibc.git;a=commit;h=c579f48edba88380635ab98cb612030e3ed8691e

Bind does not mark getpid as a valid syscall under seccomp...

A short search located:
https://github.com/voidlinux/void-packages/blob/master/srcpkgs/bind/patches/seccomp.patch

Comment by Bogomil (smirky) - Monday, 13 March 2017, 09:42 GMT
I confirm the seccomp.patch works and with it, there's no need to downgrade packages.
Comment by Pascal Ernster (hardfalcon) - Monday, 13 March 2017, 17:00 GMT
I can confirm this, the voidlinux patch from Allan's comment fixes the bug. I've only tried it with the latest git checkout of bind, though, because I use OpenSSL 1.1, which is not yeat supported by the latest stable release of bind.
Comment by Isabell Cowan (Izzette) - Tuesday, 14 March 2017, 18:28 GMT
I'm with Tarqi and pgoetz, this is urgent, and it really ruined my morning. The "seccomp.patch" worked for me as well, but I think I might be moving my nameserver to a more stable distribution.

Loading...