Bug 976188 - target_core_iblock still opens the mpath device after stopping targetcli
target_core_iblock still opens the mpath device after stopping targetcli
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: targetcli (Show other bugs)
7.0
Unspecified Unspecified
urgent Severity urgent
: rc
: ---
Assigned To: Andy Grover
Storage QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-20 01:46 EDT by Xiaowei Li
Modified: 2015-01-26 19:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-20 17:42:00 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Xiaowei Li 2013-06-20 01:46:16 EDT
Description of problem:


Version-Release number of selected component (if applicable):
kernel-3.9.0-0.rc8.54.el7.x86_64
targetcli-2.1.fb25-1.el7.noarch

How reproducible:
100%

Steps to Reproduce:
1. /backstores/block> create dev=/dev/mapper/mpathc name=mpathc
2. save and exit targetcli
3. service targetcli stop
4. multipath -F
5. check target_core_iblock, it's still in use
[root@storageqe-13 network-scripts]# lsmod | grep bloc
target_core_iblock     18075  1 
target_core_mod       285866  9

Actual results:
Jun 20 01:37:08 | mpathc: map in use
Jun 20 01:37:08 | failed to remove multipath map mpathc

Expected results:


Additional info:
Comment 2 Andy Grover 2013-06-20 17:42:00 EDT
I could duplicate this behavior if the targetcli service was never started. In this case, "service targetcli stop" doesn't actually run the service stop command -- systemd is perhaps being too smart.

Solutions to this would be starting the service before calling stop, or running the command that stop runs: "targetcli clearconfig confirm=true", instead of "service targetcli stop".

Closing, please feel free to reopen if needed.
Comment 3 Xiaowei Li 2013-06-24 00:05:14 EDT
(In reply to Andy Grover from comment #2)
> I could duplicate this behavior if the targetcli service was never started.
> In this case, "service targetcli stop" doesn't actually run the service stop
> command -- systemd is perhaps being too smart.
> 
> Solutions to this would be starting the service before calling stop, or
> running the command that stop runs: "targetcli clearconfig confirm=true",
> instead of "service targetcli stop".
> 
> Closing, please feel free to reopen if needed.

yes, targetcli clearconfig confirm=true can fix this issue. but I have checked the /usr/lib/systemd/system/targetcli.service, it should issue the mentioned command when executing service targetcli stop. 

====
ExecStop=/usr/bin/targetcli clearconfig confirm=true
====

from my side, service targetcli stop should have the same function of 'targetcli clearconfig confirm=true', can you explain why 'service targetcli stop' does not work?
Comment 4 Andy Grover 2013-06-24 14:25:16 EDT
From http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities/

systemd only stops running services. On traditional SysV a K link installed for shutdown was executed when going down regardless whether the service was started before or not. systemd is more strict here and does not stop service that weren't started in the first place.

-------------

So unless systemd thinks the targetcli service is started, the ExecStop line won't be called.

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