reassign 730744 libc6 found 730744 2.13-38 affects 730744 apache2.2-common thanks
Am Freitag, 29. November 2013, 01:52:38 schrieb Thibaut VARENE: > I can't tell whether that's an apache2 or libc bug, here's the > story: > > Apache suddenly stopped working (it was still working a week ago, > and there was no configuration change on the system in the > interval). I suspect the last logrotation triggered this, but > unfortunately I can't track it down to an upgraded packages: I run > unattended-upgrades, but there's nothing in the logs for that > period, and I don't remember manually dist-upgrading either, so I'm > really clueless as to what broke. To me, this seems like a glibc bug. As I understand the kernel commit log, accept4 has been introduced in 2.6.28. This is also stated by the accept4 man page. However, in that version, only a few architectures got a distinct syscall number for accept4. On most arches, accept4 was only usable through the socketcall multiplexing syscall. In later versions, more architectures introduced distinct syscall numbers for accept4. Glibc should use socketcall if running on an old kernel that does not have the accept4 direct syscall. On some archs, the direct accept4 call was introduced as late as 3.2. Relevant commits: de11defebf00007677fb7ee91d9b089b78786fbb 81e4a5e3057740a625cf556879ae0becf6199f8c 21d93e2e29722d7832f61cc56d73fb953ee6578e 65cc21b4523e94d5640542a818748cd3be8cd6b4 86250b9d12caa1a3dee12a7cf638b7dd70eaadb6 As a workaround, you could rebuild libapr1 adding apr_cv_accept4=no to the configure arguments. Possibly simply rebuilding it on the affected machine without source change is already sufficient because configure will detect that accept4 does not work. It's possible that this problem has been introduced with apr 1.4.6-3+deb7u1 and that the powerpc buildds were already running a newer kernel than in wheezy when that version was built. If the libc maintainers disagree with my analysis, they should re- assign to libapr1. But I think I will require the accept4 man page to be adjusted before I change apr's behavior. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
