Bug 436175 - Would be nice if it didn't start with no targets configured
Would be nice if it didn't start with no targets configured
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: iscsi-initiator-utils (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Mike Christie
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 246960
  Show dependency treegraph
 
Reported: 2008-03-05 14:15 EST by Jeremy Katz
Modified: 2013-01-09 23:35 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-10-13 14:30:17 EDT
Type: ---
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 Jeremy Katz 2008-03-05 14:15:49 EST
It'd be nice if the iscsi initscripts just exited quickly and quietly if you
don't have any targets configured rather than slowing boot
Comment 1 Mike Christie 2008-03-07 10:12:25 EST
By slowing down boot do you just mean that it spits out that error message when
it does not need to, or is there some other hang?

I added a check for running sessions, and will fix the other part of the slow
down if I misunderstood you.

Thanks.
Comment 2 Jeremy Katz 2008-03-07 10:24:26 EST
Spits out the error message and runs commands when there's nothing configured. 
The best way to speed up boot is for us to do less :-)
Comment 3 Mike Christie 2008-04-04 15:11:10 EDT
I did as much as I could.

Shutdown is better and if there are no sessions running then we take the fast
path and are quiet. For "start" we have to startup iscsid even if there are no
targets setup, because iscsid needs to be running to discover future targets.
Users do service iscsi start, then run iscsiadm to do discovery. iscsiadm then
talks to the daemon. Or when iscsid starts up it talks to a isns server to find
new targets.

Fixed in iscsi-initiator-utils-6.2.0.868-0.6
Comment 4 Jesse Keating 2008-04-04 15:57:51 EDT
(In reply to comment #3)
> I did as much as I could.
> 
> Shutdown is better and if there are no sessions running then we take the fast
> path and are quiet. For "start" we have to startup iscsid even if there are no
> targets setup, because iscsid needs to be running to discover future targets.
> Users do service iscsi start, then run iscsiadm to do discovery. iscsiadm then
> talks to the daemon. Or when iscsid starts up it talks to a isns server to find
> new targets.
> 
> Fixed in iscsi-initiator-utils-6.2.0.868-0.6
> 

Uh, if the user has to start the iscsi service, why can't the iscsi service init
ensure that iscsiadm is either already running, or start it up?  We have many
methods of bringing up services on demand, pick one?

Comment 5 Mike Christie 2008-04-07 14:16:50 EDT
(In reply to comment #4)
> (In reply to comment #3)
> > I did as much as I could.
> > 
> > Shutdown is better and if there are no sessions running then we take the fast
> > path and are quiet. For "start" we have to startup iscsid even if there are no
> > targets setup, because iscsid needs to be running to discover future targets.
> > Users do service iscsi start, then run iscsiadm to do discovery. iscsiadm then
> > talks to the daemon. Or when iscsid starts up it talks to a isns server to find
> > new targets.
> > 
> > Fixed in iscsi-initiator-utils-6.2.0.868-0.6
> > 
> 
> Uh, if the user has to start the iscsi service, why can't the iscsi service init
> ensure that iscsiadm is either already running, or start it up?  We have many
> methods of bringing up services on demand, pick one?
> 

If I do "service iscsi start" then it will start iscsid, and if the user has
setup iscsi to automatically log into targets and find iscsi disks it will do
that too.

The iscsid daemon talks to the kernel and is the iscsi state machine (iscsi is
one of those messed up drivers where it is partially in the kernel and
userspace). iscsid handles async kernel iscsi events, isns events (isns is
basically just a way for targets/disks to tell the initiator/host that there has
been some event like new storage was added or removed) and passes requests from
userspace to the kernel (for example when we log into a target iscsiadm sends a
request to iscsid which then sends it to the kernel).

Are you saying for the case where a user runs iscsiadm to find new targets/disks
that iscsiadm should start the iscsi service for the user right? I can do this,
but I had thought this would not happen very much. Users normally would install
the iscsi rpm, start the service, then discover storage that they want to log
into automatically when the service restarts. So most likely only the first
startup would not have disks discovered and the iscsi script would not be doing
anything really useful.

Do you guys think that users are going to install the rpm and just have it
sitting there with no disks discovered a lot? In that case, I get what you are
saying and I agree a on demand startup makes sense.

Or did I goof up what the service should be doing? Should doing "service iscsi
start" just check if the user has asked us to log into targets and find disks
automatically? And then when iscsiadm is run to log into a target/disk it would
automatically start iscsid?

The only other problem is where nothing is configured (well the only thing that
is setup is to handle certain events) and we want iscsid to start to handle
async events automagically. For that, iscsid is actually listening on tcp/ip
sockets or netlink sockets, so it must be up and running.
Comment 6 Bug Zapper 2008-05-14 01:47:43 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 7 Jeremy Katz 2008-06-13 13:39:22 EDT
(In reply to comment #5)
> Are you saying for the case where a user runs iscsiadm to find new targets/disks
> that iscsiadm should start the iscsi service for the user right? I can do this,
> but I had thought this would not happen very much. 

It's probably not a bad way for it to work.  Especially as it will then write
out records so that in the future, the startup just happens

>Users normally would install
> the iscsi rpm, start the service, then discover storage that they want to log
> into automatically when the service restarts. So most likely only the first
> startup would not have disks discovered and the iscsi script would not be doing
> anything really useful.
> 
> Do you guys think that users are going to install the rpm and just have it
> sitting there with no disks discovered a lot? In that case, I get what you are
> saying and I agree a on demand startup makes sense.

The RPM gets installed in a significant number of cases now that libvirt depends
upon it.  Even if it's not being used.
Comment 8 Mike Christie 2008-06-13 14:59:43 EDT
Ok, will put it on my todo. I have to research how to launch it on demand. I
have never worked with those APIs.

Thanks for the comments Jeremy and Jesse.
Comment 9 Hans de Goede 2008-10-13 14:30:17 EDT
Short intro: I've recently begun as an iscsi-initiator-utils co-maintainer and
as such I'm looking into all open bugs.

The iscsi services are *vital* for systems using iscsi, so they must be enabled
bu default.

iscsi-initiator-utils-6.2.0.870-0.1.rc1.fc10 which will be in tomorrows rawhide
has rewritten initscripts, which will silently exit with a 0 status ASAP when
iscsi is not needed, as requested in this bug.

The iscsiadm needing iscsid problem has been fixed by patching iscsiadm to start iscsid when necessary.

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