RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 976188 - target_core_iblock still opens the mpath device after stopping targetcli
Summary: target_core_iblock still opens the mpath device after stopping targetcli
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: targetcli
Version: 7.0
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Andy Grover
QA Contact: Storage QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-20 05:46 UTC by Xiaowei Li
Modified: 2023-03-08 07:25 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-06-20 21:42:00 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Xiaowei Li 2013-06-20 05:46:16 UTC 
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 21:42:00 UTC 
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 04:05:14 UTC 
(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 18:25:16 UTC 
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.