Control: found -1 libapache2-mod-auth-openidc/2.1.6-1 Control: tags -1 + jessie stretch
Hi George, On 19.07.2017 20:01, Georges Racinet wrote: > This is some kind of a trap : simply enabling the module and performing > a reload (no restart) gives a non-responsive Apache2 server. > I had this first with jessie's 1.6.0-1, then with jessie-backports' > (reporting against the latter). First of all, I can confirm that it happens in Stretch, too. > Steps to reproduce, once the package is installed : > > a2enmod auth_openidc > systemctl reload apache2 > > then the HTTP server becomes unresponsive : accepts connections for a > while but hangs indefinitely, then does not accept connections at all. On the other hand, when you use a2enmod, it tells you pretty clearly, that you should *restart*, not just reload Apache: > $ a2enmod auth_openidc > Enabling module auth_openidc. > To activate the new configuration, you need to run: > systemctl restart apache2 > The error log displays continuous segmentation faults that I saw only > while rechecking for this report (I had a first version with just > complains about missing directives, which is perhaps another story). For the record, error_log contains myriads of lines like > [Wed Jul 26 16:13:07.253839 2017] [core:notice] [pid 2071] AH00052: child pid > 21254 exit signal Segmentation fault (11) > [Wed Jul 26 16:13:07.253885 2017] [core:error] [pid 2071] AH00546: no record > of generation 7 of exiting child 21254 and I've attached the strace log of one of the child processes. We just ship the example conf file from upstream, where everything is commented out. But this does not lead to warnings about missing directives after a restart of Apache2 on my system. > In any case, breaking an Apache2 server with a simple reload should not > happen (I'm even surprised it's possible) Yes, and we will continue to look into it. > With the segmentation faults, this looks quite similar to #850331. I did > not have the occasion yet to give it a try on a stretch system, in case > the backported version would have a compatibility issue with jessie's > Apache2 I don't think this is related. > Thanks for your attention and your work in general! Thank you for reporting this. -- Moritz Schlarb Unix-Gruppe | Systembetreuung Zentrum für Datenverarbeitung Johannes Gutenberg-Universität Mainz Raum 01-321 - Tel. +49 6131 39-29441 OpenPGP Fingerprint: DF01 2247 BFC6 5501 AFF2 8445 0C24 B841 C7DD BAAF
set_robust_list(0x7f6427f817a0, 24) = 0
rt_sigaction(SIGHUP, {sa_handler=0x7f641dafa0c0, sa_mask=[],
sa_flags=SA_RESTORER|SA_INTERRUPT, sa_restorer=0x7f64274920c0},
{sa_handler=0x7f641daf9a80, sa_mask=[HUP USR1], sa_flags=SA_RESTORER,
sa_restorer=0x7f64274920c0}, 8) = 0
rt_sigaction(SIGTERM, {sa_handler=0x7f641dafa0c0, sa_mask=[],
sa_flags=SA_RESTORER|SA_INTERRUPT, sa_restorer=0x7f64274920c0},
{sa_handler=0x7f641daf9a40, sa_mask=[], sa_flags=SA_RESTORER,
sa_restorer=0x7f64274920c0}, 8) = 0
rt_sigaction(SIGUSR1, {sa_handler=0x7f641dafa040, sa_mask=[],
sa_flags=SA_RESTORER|SA_INTERRUPT, sa_restorer=0x7f64274920c0},
{sa_handler=0x7f641daf9a80, sa_mask=[HUP USR1], sa_flags=SA_RESTORER,
sa_restorer=0x7f64274920c0}, 8) = 0
getpid() = 17615
getpid() = 17615
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f6427ebc000
mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x7f6427eba000
geteuid() = 0
setgid(33) = 0
open("/proc/sys/kernel/ngroups_max", O_RDONLY) = 10
read(10, "65536\n", 31) = 6
close(10) = 0
open("/etc/group", O_RDONLY|O_CLOEXEC) = 10
lseek(10, 0, SEEK_CUR) = 0
fstat(10, {st_mode=S_IFREG|0644, st_size=900, ...}) = 0
mmap(NULL, 900, PROT_READ, MAP_SHARED, 10, 0) = 0x7f6427f84000
lseek(10, 900, SEEK_SET) = 900
fstat(10, {st_mode=S_IFREG|0644, st_size=900, ...}) = 0
munmap(0x7f6427f84000, 900) = 0
close(10) = 0
setgroups(1, [33]) = 0
geteuid() = 0
setuid(33) = 0
getpid() = 17615
--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x8} ---
chdir("/etc/apache2") = 0
rt_sigaction(SIGSEGV, {sa_handler=SIG_DFL, sa_mask=[],
sa_flags=SA_RESTORER|SA_INTERRUPT, sa_restorer=0x7f64274920c0},
{sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER|SA_RESETHAND,
sa_restorer=0x7f64274920c0}, 8) = 0
getpid() = 17615
getpid() = 17615
kill(17615, SIGSEGV) = 0
rt_sigreturn({mask=[]}) = 0
--- SIGSEGV {si_signo=SIGSEGV, si_code=SI_USER, si_pid=17615, si_uid=33} ---
+++ killed by SIGSEGV +++
<<attachment: schlarbm.vcf>>
