Bug 436175

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.

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 :-)

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

(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?

(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.

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

(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.

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.

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.