tgtd target will not start unless it's configured with "allow-in-use yes"

Bug #605721 reported by Etienne Goyer
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
tgt (Ubuntu)
Fix Released
Medium
Chris Cheney
Maverick
Fix Released
Medium
Chris Cheney

Bug Description

Binary package hint: tgt

tgt-admin will not start a target unless we specify the "allow-in-use yes" directive in the target declaration. It complains that the device is in use, although I am positive it is not. Specifying "allow-in-use yes" is not recommended, and doing so is not really satisfactory.

ubuntu@lucid-server:~$ cat /etc/tgt/targets.conf
<target iqn.2005-03.org.open-iscsi:walrus.lun1>
   backing-store /dev/sda
   write-cache off
# allow-in-use yes
</target>
ubuntu@lucid-server:~$ sudo tgtd
ubuntu@lucid-server:~$ sudo tgt-admin -v -e
# default-driver not defined, defaulting to iscsi.

# Adding target: iqn.2005-03.org.open-iscsi:walrus.lun1
tgtadm --lld iscsi --op new --mode target --tid 1 -T iqn.2005-03.org.open-iscsi:walrus.lun1
# Device /dev/sda is used (already tgtd target?).
# Run 'lsof /dev/sda' to see the details.
# Skipping device /dev/sda - it is in use.
# You can override it with --force or 'allow-in-use yes' config option.
# Note - do so only if you know what you're doing, you may damage your data.
tgtadm --lld iscsi --op bind --mode target --tid 1 -I ALL

ubuntu@lucid-server:~$ sudo tgt-admin -s
Target 1: iqn.2005-03.org.open-iscsi:walrus.lun1
    System information:
        Driver: iscsi
        State: ready
    I_T nexus information:
    LUN information:
        LUN: 0
            Type: controller
            SCSI ID: IET 00010000
            SCSI SN: beaf10
            Size: 0 MB
            Online: Yes
            Removable media: No
            Backing store type: rdwr
            Backing store path: None
    Account information:
    ACL information:
        ALL
ubuntu@lucid-server:~$ lsof /dev/sda
ubuntu@lucid-server:~$

Revision history for this message
Etienne Goyer (etienne-goyer-outlands) wrote :

I am also positive no other tgtd process where running at the same time.

Changed in tgt (Ubuntu):
status: New → Triaged
assignee: nobody → Chris Cheney (ccheney)
importance: Undecided → Medium
Changed in tgt (Ubuntu Maverick):
milestone: none → maverick-alpha-3
Revision history for this message
Chris Cheney (ccheney) wrote :

Will take a look at this asap, probably during the sprint this next week.

Revision history for this message
Chris Cheney (ccheney) wrote :

When you get that error what does the following show:

"# Run 'lsof /dev/sda' to see the details."

Revision history for this message
Chris Cheney (ccheney) wrote :

I see you ran it in your comment above, but was it immediately after the error happened or some time later?

Revision history for this message
Chris Cheney (ccheney) wrote :

Hmm looking at the code I think its buggy. I'm not sure what it is actually trying to do but it doesn't seem to be doing it right in any case. It appears to be 8 bit shifting left, and then checking for 0. If the device is in use lsof returns 0 if it is not then it returns 1, at least as best as I can tell, in which case doing the bit shift causes the problem. I am not sure why it was added, but it probably was needed for something.

        # Check if userspace uses this device
        my $lsof_check = check_exe("lsof");
        if ($lsof_check ne 1) {
                system("lsof $backing_store &>/dev/null");
                my $exit_value = $? >> 8;
                if ($exit_value eq 0) {
                        execute("# Device $backing_store is used (already tgtd target?).");
                        execute("# Run 'lsof $backing_store' to see the details.");
                        return 0;
                }
        }
        return 1;
}

Revision history for this message
Chris Cheney (ccheney) wrote :

It appears to be a bug caused by using this:

                system("lsof $backing_store &>/dev/null");

instead of:

                system("lsof $backing_store >/dev/null 2>&1");

Revision history for this message
Chris Cheney (ccheney) wrote :

I was confused earlier about the direction of bitshift since the wrong calling convention was causing it to always return 0.

Revision history for this message
Chris Cheney (ccheney) wrote :

Forgot the # in the closes line in the upload. It was fixed in tgt 1:1.0.4-1ubuntu3

Changed in tgt (Ubuntu Maverick):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.