Bug 1065493

Summary:	TimeoutStopSec=0 doesn't work
Product:	Red Hat Enterprise Linux 7	Reporter:	David Teigland <teigland>
Component:	systemd	Assignee:	systemd-maint
Status:	CLOSED NOTABUG	QA Contact:	qe-baseos-daemons
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	7.0	CC:	msekleta, systemd-maint-list
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2014-07-01 13:11:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description David Teigland 2014-02-14 18:58:27 UTC

Description of problem:

I add TimeoutStopSec=0 to /usr/lib/systemd/system/sanlock.service

Make sanlock busy with:
systemctl start wdmd sanlock
sanlock direct init -s foo:1:/dev/vgx/leases:0
sanlock client add_lockspace -s foo:1:/dev/vgx/leases:0

Try to stop sanlock:
systemctl stop sanlock

systemd sends SIGTERM a couple times, and eventually SIGKILL.
I need to prevent it from sending SIGKILL, and it appears that
should be done with TimeoutStopSec=0.

(Issue originated from bug 1064991)

Version-Release number of selected component (if applicable):

systemd-207-11.el7.x86_64
sanlock-3.1.0-1.el7.x86_64

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 2 RHEL Program Management 2014-03-22 06:01:07 UTC

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 3 Michal Sekletar 2014-07-01 13:11:09 UTC

TimeoutStopSec=0 disables timeout logic involved in stopping services, but doesn't change procedure of stopping services. You can not prevent systemd from actually stopping the service, and sometimes SIGKILL is the only way. Hence I think this is issue of configuration and not a bug in systemd. Please consult manpage systemd.kill for more details.