Bug 10591

Summary:	httpd sometimes deadlocks on restart/shutdown resulting in systemd timeout after a delay
Product:	Mageia	Reporter:	Colin Guthrie <mageia>
Component:	RPM Packages	Assignee:	QA Team <qa-bugs>
Status:	RESOLVED FIXED	QA Contact:
Severity:	normal
Priority:	Normal	CC:	lewyssmith, sysadmin-bugs, tmb
Version:	3	Keywords:	validated_update
Target Milestone:	---
Hardware:	i586
OS:	Linux
Whiteboard:	has_procedure MGA3-32-OK mga3-64-ok
Source RPM:	httpd	CVE:
Status comment:

Description Colin Guthrie 2013-06-22 15:48:44 CEST

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:

Comment 1 Colin Guthrie 2013-06-22 15:51:41 CEST

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

Comment 2 claire robinson 2013-07-03 07:59:19 CEST

Colin could you list the rpms please too. I'm adding this one to the easy bugs email.

Comment 3 Colin Guthrie 2013-07-03 09:32:46 CEST

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

claire robinson 2013-07-08 16:58:43 CEST

Whiteboard: va => has_procedure

Comment 4 Lewis Smith 2013-07-09 21:40:23 CEST

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

Comment 5 Lewis Smith 2013-07-10 22:06:11 CEST

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

Comment 6 claire robinson 2013-07-15 17:33:43 CEST

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_update
Whiteboard: has_procedure MGA3-32-OK => has_procedure MGA3-32-OK mga3-64-ok
CC: (none) => sysadmin-bugs

Comment 7 Thomas Backlund 2013-07-16 10:39:34 CEST

Update pushed:
http://advisories.mageia.org/MGAA-2013-0060.html

Status: NEW => RESOLVED
CC: (none) => tmb
Resolution: (none) => FIXED