Bug 703457

Summary:	umount_loop graceful kill is ineffective
Product:	[Fedora] Fedora	Reporter:	Philip Rowlands <phr>
Component:	initscripts	Assignee:	Bill Nottingham <notting>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	rawhide	CC:	iarlyy, jonathan, notting, plautrba, rvokal
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2011-05-10 19:04:08 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Philip Rowlands 2011-05-10 11:46:11 UTC

I'm looking at rc.d/init.d/functions, specifically __umount_loop, and __umount_loopback_loop.

The line "sig=-9" is redundant, as fuser -k defaults to SIGKILL. If the intention during the first loop iteration is to send some other signal (SIGTERM?), this does not occur.

Suggested fix is to specify "local sig=-15" at the top of the function(s). Alternativly, hard-code signal "-9" and do away with the "sig" variable and the logic to update it for the second loop iteration.

This bug has little practical effect on long-running processes, as the call from halt to __umount_loop follows the calls to killall5 which attempt graceful then forced process termination.

Comment 1 Bill Nottingham 2011-05-10 15:25:42 UTC

No argument with the analysis, although it's been that way forever.

Comment 2 Bill Nottingham 2011-05-10 19:04:08 UTC

http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=81b50ecb6be1df83b45c6ed868e855c6d11bf135

Will be in a future rawhide/F-16 initscripts build, thanks!

Comment 3 Philip Rowlands 2011-05-11 13:49:15 UTC

Thanks Bill,

I've found looking back at my notes where I first stumbled on this... I was experimenting putting / and /etc on separate filesystems, but this produces errors when umount tries to write the mtab lockfile onto the read-only /etc filesystem, forcing __umount_loop to loop.

On closer inspection I spotted the mistake in the assumed signal for fuser -k.

Comment 4 Bill Nottingham 2011-05-11 20:40:13 UTC

(In reply to comment #3)
> Thanks Bill,
> 
> I've found looking back at my notes where I first stumbled on this... I was
> experimenting putting / and /etc on separate filesystems,

Don't do that. :)

(Seriously - /etc is required to be on the same filesystem as /.)