Bug 1065493 - TimeoutStopSec=0 doesn't work
Summary: TimeoutStopSec=0 doesn't work
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-14 18:58 UTC by David Teigland
Modified: 2014-07-01 13:11 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-01 13:11:09 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

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.


Note You need to log in before you can comment on or make changes to this bug.