Advisory Text ============= A problem was found with the httpd systemd unit files that frequently resulted in a deadlock when stopping or restarting the service. The unit file was configured to use the httpd -k graceful-stop command to stop the running instances of httpd. This command is asynchronous but systemd expects the command to be synchronous, only exiting once all the processes have stopped. This causes systemd to send a SIGTERM to all processes remaining in the cgroup which can cause problems for the shutdown process resulting in the deadlock. systemd would later send a SIGKILL which would properly kill the processes but this would only happen after a timeout. This update changes the systemd unit to not send the initial SIGTERM and thus waits for the processes to exit normally before (if things don't go well) calling SIGKILL as before after a timeout. Reproducible: Steps to Reproduce:
SRPM: apache-2.4.4-7.1.mga3.src.rpm Note to QA: To get the problem to present itself you would typically have to make at least a few request to a simple apache + PHP page... using a simple PHP script (<?php phpinfo();) and ab to make a few requests to that page should be sufficient to get apache into a state where it would exhibit the problem.
Assignee: mageia => qa-bugs
Colin could you list the rpms please too. I'm adding this one to the easy bugs email.
apache-2.4.4-7.1.mga3.i586.rpm RPMS: apache-devel-2.4.4-7.1.mga3.i586.rpm apache-doc-2.4.4-7.1.mga3.noarch.rpm apache-htcacheclean-2.4.4-7.1.mga3.i586.rpm apache-mod_cache-2.4.4-7.1.mga3.i586.rpm apache-mod_dav-2.4.4-7.1.mga3.i586.rpm apache-mod_dbd-2.4.4-7.1.mga3.i586.rpm apache-mod_ldap-2.4.4-7.1.mga3.i586.rpm apache-mod_proxy-2.4.4-7.1.mga3.i586.rpm apache-mod_proxy_html-2.4.4-7.1.mga3.i586.rpm apache-mod_ssl-2.4.4-7.1.mga3.i586.rpm apache-mod_suexec-2.4.4-7.1.mga3.i586.rpm apache-mod_userdir-2.4.4-7.1.mga3.i586.rpm apache-2.4.4-7.1.mga3.x86_64.rpm apache-devel-2.4.4-7.1.mga3.x86_64.rpm apache-doc-2.4.4-7.1.mga3.noarch.rpm apache-htcacheclean-2.4.4-7.1.mga3.x86_64.rpm apache-mod_cache-2.4.4-7.1.mga3.x86_64.rpm apache-mod_dav-2.4.4-7.1.mga3.x86_64.rpm apache-mod_dbd-2.4.4-7.1.mga3.x86_64.rpm apache-mod_ldap-2.4.4-7.1.mga3.x86_64.rpm apache-mod_proxy-2.4.4-7.1.mga3.x86_64.rpm apache-mod_proxy_html-2.4.4-7.1.mga3.x86_64.rpm apache-mod_ssl-2.4.4-7.1.mga3.x86_64.rpm apache-mod_suexec-2.4.4-7.1.mga3.x86_64.rpm apache-mod_userdir-2.4.4-7.1.mga3.x86_64.rpm Also validated on x86_64 by me! Just checked on a real world public facing server after several days of uptime and it restarted happily.
Whiteboard: (none) => va
Whiteboard: va => has_procedure
MGA3-32-OK but not with overmuch assurance. I installed Apache and PHP on Mageia3 32-bit, and even before I found out how to drive Apache noticed that the system - with Apache enabled as a start-up process - took several minutes to shut down. Repeatedly. Realising that this may be the 'bug', I installed the update apache-2.4.4-7.1.mga3.i586.rpm and noticed at once that the system shut down normally again. I then found the default web page /var/www/html/index.html which displays from http://localhost/ in a browser. Using the MCC 'services' function, I turned on & off the http service (Apache) and checked that the browser displayed or could not display the page in question according to whether Apache was running. The transition from running to stopped was rapid & consistent. So I reckon the bug is fixed for MGA3-32; but a 2nd opinion would be nice. I know, I *should* have found this easy test before updating Apache, but did not find the method in time. Rusty on Apache.
CC: (none) => lewyssmith
MGA3-32-OK with more confidence I reverted to the issued Apache *without* PHP, & tried simply stopping/starting it in MCC/Services: it stopped quickly, repeatedly. Invoking the default web page in a browser made no difference: this behaved as would be expected. Like after the update... I then added issued PHP5, re-started the system, and Apache immediately took ages to stop from MCC/Services. Without even invoking any web access. Viewing the default page made no change to this behaviour. So it seems that the presence of PHP has something to do with it. In effect, this comment 5 [invoke the fault] should be before comment 4 [test the update]. Given that the latter shows that the update *does* eliminate the long wait for Apache (with PHP) to terminate, let it be!
Whiteboard: has_procedure => has_procedure MGA3-32-OK
Validating. Sorry for the delay Colin we're snowed under. Advisory from comment 0 uploaded Could sysadmin please push from 3 core/updates_testing to core/updates Thanks!
Keywords: (none) => validated_updateWhiteboard: has_procedure MGA3-32-OK => has_procedure MGA3-32-OK mga3-64-okCC: (none) => sysadmin-bugs
Update pushed: http://advisories.mageia.org/MGAA-2013-0060.html
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED