Bug 853300

Would you please attach the log files? See here: http://en.opensuse.org/openSUSE:Bugreport_YaST . Thanks.

Created attachment 570509 [details]
log zip of /var/log/YaST2

Please see time around 2-13-11-03.

The reason is that the iscsid init script is missing from the open-iscsi package in 13.1.
This script activates the automatic login via:

iscsiadm -m node --loginall=automatic

in Version 12.3 it is still present:

 # cat /etc/SuSE-release
openSUSE 12.3 (x86_64)
[...]
# rpm -ql open-iscsi | grep init.d/iscsid
/etc/init.d/iscsid


but not in 13.1:

# cat /etc/SuSE-release
openSUSE 13.1 (x86_64)

#  rpm -ql open-iscsi | grep init.d/iscsid
#


Unless this functionality has been moved to systemd, we would need to get the /etc/init.d/iscsid script back into 13.1.

The functionality has indeed been moved to systemd.
Please do a:

systemctl list-unit-files

and check wheter iscsi.service is enabled.
If not, enable it via:

systemctl start iscsi.service

I see, thanks for your patient explain!

This means yast2-iscsi-client has to start/enable service 'iscsi' additional to service 'iscsid'? And service can be removed 'boot.iscsid-early' (is obsolete).
Is this correct?

(In reply to comment #7)
> This means yast2-iscsi-client has to start/enable service 'iscsi' additional to
> service 'iscsid'? And service can be removed 'boot.iscsid-early' (is obsolete).
Should be: And service 'boot.iscsid-early' can be removed...
> Is this correct?
An additional question:
I assume that both services 'iscsi' and 'iscsid' are always required to run. Or does it makes sense to start only one?

(In reply to comment #7)
> This means yast2-iscsi-client has to start/enable service 'iscsi' additional to
> service 'iscsid'? And service can be removed 'boot.iscsid-early' (is obsolete).
> Is this correct?

The service iscsid is the iSCSI daemon. You do not need to start this one, but you do need to start iscsid.socket. BTW, iscsid.socket should be started by enabled and started by default upon installation.

The iscsi service takes care of automatically logging into iSCSI targets where "startup" is set to "onboot". This would be for non-root volumes.

And you are correct that all /etc/init.d init scripts for open-iscsi went away, including boot.iscsid-early.

Please let me know if you need any more information.

(In reply to comment #12)
> (In reply to comment #7)
> > This means yast2-iscsi-client has to start/enable service 'iscsi' additional to
> > service 'iscsid'? And service can be removed 'boot.iscsid-early' (is obsolete).
> > Is this correct?
> 
> The service iscsid is the iSCSI daemon. You do not need to start this one, but
> you do need to start iscsid.socket. BTW, iscsid.socket should be started by
> enabled and started by default upon installation.

If the iscsid.service is dependend on iscsid.socket, then the service file must reflect that in its unit file. The section "Sockets" in the iscsid.service unit file seems to be the right place where to express such dependency according to http://www.freedesktop.org/software/systemd/man/systemd.service.html .

I have tested: call 'systemctl start iscsid.socket' and afterwards e.g. 'iscsiadm'. The iscsid.service i started automatically then.
If I understand Hannes and comment #12 correctly this is expected behaviour.
Comment #13 describes different approach.
 
How to solve this?

(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #7)
> > > This means yast2-iscsi-client has to start/enable service 'iscsi' additional to
> > > service 'iscsid'? And service can be removed 'boot.iscsid-early' (is obsolete).
> > > Is this correct?
> > 
> > The service iscsid is the iSCSI daemon. You do not need to start this one, but
> > you do need to start iscsid.socket. BTW, iscsid.socket should be started by
> > enabled and started by default upon installation.
> 
> If the iscsid.service is dependend on iscsid.socket, then the service file must
> reflect that in its unit file. The section "Sockets" in the iscsid.service unit
> file seems to be the right place where to express such dependency according to
> http://www.freedesktop.org/software/systemd/man/systemd.service.html .

Bug bnc#847953 already addresses the need to explicitly specify the link between iscsid.socket and iscsid.service. It currently works without that explicit specification because systemd assumes that the two service files are related.

(In reply to comment #14)
> I have tested: call 'systemctl start iscsid.socket' and afterwards e.g.
> 'iscsiadm'. The iscsid.service i started automatically then.
> If I understand Hannes and comment #12 correctly this is expected behaviour.
> Comment #13 describes different approach.
> 
> How to solve this?

I don't see any difference.

The three iscsi serivce files are related like this:

iscsid.socket is enabled by default when installed, and it simply listens on the iscsid socket, then starts the iscsid.service if it sees any traffic

iscsid.service *is* the iscsid. It is not normally started by default, since that would mean that the iscsid daemon would be running all the time. Instead, it is started automatically by systemd via iscsid.socket (see above)

iscsi.service is a service that runs on top of iscsid.service. This highest-level service takes care of automatically logging into iscsi targets at boot time that have 'startup' set to automatic, as well as logging out of *any* target at system shutdown time. This service has to be started when installed.

It's all clear to me - except: who initially starts iscsid.socket?
Your comment says: iscsid.socket is enabled by default when installed, ...

On my test system (SLES12 Alpha 3) I have installed package 'open-iscsi'. Calling "systemctl status iscsid.socket" shows Active: inactive.

Is this solved with fix for bnc #847953?

What's right approach for YaST iscsi-client?
Not to start/enable service 'iscsid' at all (because iscsid.socket is started/enabled by default and will start iscsid.service if needed).
Only start/enable service 'iscsi' for automatic login.

(In reply to comment #17)

> Only start/enable service 'iscsi' for automatic login.
Read your comment again, I assume correct way is to start 'iscsi' in any case because also needed for logging out of any target?

(In reply to comment #17)
> It's all clear to me - except: who initially starts iscsid.socket?
> Your comment says: iscsid.socket is enabled by default when installed, ...
> 
> On my test system (SLES12 Alpha 3) I have installed package 'open-iscsi'.
> Calling "systemctl status iscsid.socket" shows Active: inactive.

That is how it is supposed to work. Excellent. I believe it says "inactive" because there is no current communication via that socket. But "Active" means it is ready to start up iscsid.service if you try to talk to the iSCSI daemon.

> 
> Is this solved with fix for bnc #847953?

No. There is no actual bug for bnc#845953, which is why I haven't gotten around to fixing it yet.

> 
> What's right approach for YaST iscsi-client?
> Not to start/enable service 'iscsid' at all (because iscsid.socket is
> started/enabled by default and will start iscsid.service if needed).
> Only start/enable service 'iscsi' for automatic login.

That's a good question, since this is new territory.

I would suggest enabling iscsi.service, since this should not actually cause the iscsi daemon to run unless the system has target nodes marked in the database with startup=automatic.

(In reply to comment #19)
> (In reply to comment #17)
> > It's all clear to me - except: who initially starts iscsid.socket?
> > Your comment says: iscsid.socket is enabled by default when installed, ...
> > 
> > On my test system (SLES12 Alpha 3) I have installed package 'open-iscsi'.
> > Calling "systemctl status iscsid.socket" shows Active: inactive.
> 
> That is how it is supposed to work. Excellent. I believe it says "inactive"
> because there is no current communication via that socket. But "Active" means
> it is ready to start up iscsid.service if you try to talk to the iSCSI daemon.
> 

I get error messages when calling 'iscsiadm' if status of iscsid.socket is inactive. The data seems to be delivered anywhy, so simply ignore errors?  
Scenario see below:

Status after installing package "open-iscsi":

# systemctl status iscsid.socket
iscsid.socket - Open-iSCSI iscsid Socket
   Loaded: loaded (/usr/lib/systemd/system/iscsid.socket; disabled)
   Active: inactive (dead)
     Docs: man:iscsid(8)
           man:iscsiadm(8)
   Listen: @ISCSIADM_ABSTRACT_NAMESPACE (Stream)

Calling "iscsiadm":

# iscsiadm -m session -P 1
Target: iqn.2013-10.de.suse:test_file1
        Current Portal: 10.120.66.182:3260,1
        Persistent Portal: 10.120.66.182:3260,1
                **********
                Interface:
                **********
                Iface Name: default
                Iface Transport: tcp
                Iface Initiatorname: iqn.1996-04.de.suse:01:19eacab02a1d
                Iface IPaddress: 10.120.64.243
                Iface HWaddress: <empty>
                Iface Netdev: <empty>
                SID: 1
iscsiadm: iscsid is not running. Could not start it up automatically using the startup command in the /etc/iscsi/iscsid.conf iscsid.startup setting. Please check that the file exists or that your init scripts have started iscsid.
iscsiadm: can not connect to iSCSI daemon (111)!
                iSCSI Connection State: Unknown
                iSCSI Session State: LOGGED_IN
                Internal iscsid Session State: Unknown

(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #17)
> > > It's all clear to me - except: who initially starts iscsid.socket?
> > > Your comment says: iscsid.socket is enabled by default when installed, ...
> > > 
> > > On my test system (SLES12 Alpha 3) I have installed package 'open-iscsi'.
> > > Calling "systemctl status iscsid.socket" shows Active: inactive.
> > 
> > That is how it is supposed to work. Excellent. I believe it says "inactive"
> > because there is no current communication via that socket. But "Active" means
> > it is ready to start up iscsid.service if you try to talk to the iSCSI daemon.
> > 
> 
> I get error messages when calling 'iscsiadm' if status of iscsid.socket is
> inactive. The data seems to be delivered anywhy, so simply ignore errors?  
                               should be:  anyhow

And what is expected status afterwards?
Both 'iscsid.service' and *iscsid.socket' remain inactive.

What I found out so far (also talked to meissner):
'iscsid.socket' is enabled (because listed in system-preset) but it is NOT started on installation of package 'open-iscsi'. It's only started on boot/reboot
(same is with 'iscsi.service').

My conclusion is:
It's needed to start 'iscsid.socket' (and 'iscsi.service') in YaST iSCSI client manually.

I think the functionality to start '<xy>.socket' should be added to the YaST Service module (might be also needed for other services, e.g. multipath).

As the official systemd.socket docs say: For each socket file a matching service file must exist, describing the service to start on incoming traffic on the socket. 

Adding systemd.socket support to Yast::SystemdService or Yast::Service module would violate this principle. I see the solution for this issue in updating the iscsid.service unit by adding correct options in order to start/stop the iscsid.socket. Normally this should not be necessary as all sockets whose unit shares the same name as the service are passed to the spawned process (as the doc says), but maybe this is not the normal situation. 

Honestly, I don't think the Yast or yast2-iscsi-client should be responsible for handling socket behaviour of a service.

(In reply to comment #23)

If iscsid.socket as well as iscsid.service exists the it is allowed to start the socket by using:

     systemctl start iscsid.socket

to get this socket and its socket activation active.   Otherwise you have to reboot.  The order is: start the socket and any connection on the socket will then start the associated  service its self.

(In reply to comment #21)
> (In reply to comment #20)
> > (In reply to comment #19)
...
> > 
> > I get error messages when calling 'iscsiadm' if status of iscsid.socket is
> > inactive. The data seems to be delivered anywhy, so simply ignore errors?  
>                                should be:  anyhow
> 
> And what is expected status afterwards?
> Both 'iscsid.service' and *iscsid.socket' remain inactive.

There was an error, and iscsid.socket and iscsi.service are not auto-enabled, as they should be.

I have submitted an update to package systemd-presets-branding-openSUSE. This adds two lines to the file /usr/lib/systemd/system-preset/90-default-openSUSE.preset:

  ...
  iscsid.socket
  iscsi.service

Note that this enables these services, but as per systemd guidelines, it does not start them. You will still need to manually start them or reboot.

to start them, run "systemctl start iscsid.socket" and "systemctl start iscsi.service" to do that

This is an autogenerated message for OBS integration:
This bug (853300) was mentioned in
https://build.opensuse.org/request/show/222252 13.1 / systemd-presets-branding-openSUSE

(In reply to comment #22)
> What I found out so far (also talked to meissner):
> 'iscsid.socket' is enabled (because listed in system-preset) but it is NOT
> started on installation of package 'open-iscsi'. It's only started on
> boot/reboot
> (same is with 'iscsi.service').
> 
> My conclusion is:
> It's needed to start 'iscsid.socket' (and 'iscsi.service') in YaST iSCSI client
> manually.
> 
> I think the functionality to start '<xy>.socket' should be added to the YaST
> Service module (might be also needed for other services, e.g. multipath).

Gabriele: I agree with you. I think it is up to Yast to start the services if the user wants it to run now and not just after the next reboot.

As per systemd guidelines, systemd can not know if the installation was done in a Virtual Machine or change-root environment, so it does not ever start a service automatically.

(In reply to comment #23)
> As the official systemd.socket docs say: For each socket file a matching
> service file must exist, describing the service to start on incoming traffic on
> the socket. 

There is both an "iscsid.socket" serivce file, and a "iscsid.service" service file. One of the nice things about systemd is that the iscsi daemon service (as represented by the "iscsid.service" service file), can be "socket activated". Thus, the "iscsid.socket" service file is paired automatically by systemd with the "iscsid.service" service file.

If the "iscsid.socket" service is enabled, then if somebody tries to talk to the socket that the iscsi daemon uses, systemd starts up the "iscsid.service" service, thus starting the iscsi daemon.

> 
> Adding systemd.socket support to Yast::SystemdService or Yast::Service module
> would violate this principle. I see the solution for this issue in updating the
> iscsid.service unit by adding correct options in order to start/stop the
> iscsid.socket. Normally this should not be necessary as all sockets whose unit
> shares the same name as the service are passed to the spawned process (as the
> doc says), but maybe this is not the normal situation. 
> 
> Honestly, I don't think the Yast or yast2-iscsi-client should be responsible
> for handling socket behaviour of a service.

As mentioned in an earlier comment, Yast (as the highest-level installation agent) needs to start the iscsid.socket and iscsi.service services. It does *not* need to start the "iscsid.service" service, as that will be done automatically (as detailed above).

Thanks for explanation, I'm getting now what socket-activated services represent. I'm going to add support for sockets into the yast2-services-manager package.

I think the yast iscsi client should also "enable" the services and not just "start" them.

So it does not need to be done by default in the presets.

This is an autogenerated message for OBS integration:
This bug (853300) was mentioned in
https://build.opensuse.org/request/show/222681 Factory / systemd-presets-branding-openSUSE

(In reply to comment #31)
> I think the yast iscsi client should also "enable" the services and not just
> "start" them.
YaST iscsi client has already the 'Service' dialog where the service, so far 'iscsid', can be enabled/disabled.
I will change/enhance this to have the possibility to enable/disable 'iscsid.socket' and 'iscsi.service'.
> 
> So it does not need to be done by default in the presets.

(In reply to comment #31)
> I think the yast iscsi client should also "enable" the services and not just
> "start" them.
> 
> So it does not need to be done by default in the presets.

That is not correct, but I don't think that point matters with respect to this bug.

(In reply to comment #33)
...
> I will change/enhance this to have the possibility to enable/disable
> 'iscsid.socket' and 'iscsi.service'.
...

This will not hurt anything, but I am still working to have iscsid.socket and iscsi.service enabled by default.

Again some questions:

The YaST iscsi client also runs in inst-sys and needs started service there.
AFAIK (also talked to snwint) systemd is not running in inst-sys and the only possibility is to start services manually (e.g. /sbin/sshd).
Current YaST iscsi client implementation starts 'iscsid' daemon manually when running during installation. 
I think this must remain like it is for SLES12. Running 'iscsid' should be OK and 'iscsid.socket' and 'iscsi.service' shouldn't be needed? 
Or is there another approach?

Another issue is reloading the service. Current implementation reloads 'iscsid' if /etc/iscsi/initiatorname has changed.
How to do this in future? I found that only 'reload-or-restart' is supported for iscsid and iscsid.socket. Do it for 'iscsid' or 'iscsid.socket'?

Proposal for systemd socket support in yast2-services-manager at https://github.com/yast/yast-services-manager/pull/55 .

(In reply to comment #35)
> Again some questions:
> 
> The YaST iscsi client also runs in inst-sys and needs started service there.
> AFAIK (also talked to snwint) systemd is not running in inst-sys and the only
> possibility is to start services manually (e.g. /sbin/sshd).
> Current YaST iscsi client implementation starts 'iscsid' daemon manually when
> running during installation. 
> I think this must remain like it is for SLES12. Running 'iscsid' should be OK
> and 'iscsid.socket' and 'iscsi.service' shouldn't be needed? 
> Or is there another approach?

If you run "/sbin/iscsid" manually, it should not effect any of the systemd functionality. The "start" script in systemd for open-iscsi is idempotent, i.e. running it when the service is already started should not hurt anything.

But the daemon is smart enough to detect if systemd is running when it starts up, and it configures it's socket accordingly, at start time. So if you start iscsid manually, then later start systemd, I _believe_ the daemon will have a problem interacting properly with systemd. In other words, iscsid will have to be restarted. This hopefully will not be an issue in the future, using Dracut.

> 
> Another issue is reloading the service. Current implementation reloads 'iscsid'
> if /etc/iscsi/initiatorname has changed.
> How to do this in future? I found that only 'reload-or-restart' is supported
> for iscsid and iscsid.socket. Do it for 'iscsid' or 'iscsid.socket'?

If you are restarting the daemon because configuration has changed (there is also /etc/iscsi/iscsid.conf), then you need only do a "systemctl restart iscsid.service". Note that current connections continue when you restart the daemon, but any errors in those connections that occur during this restart period cannot be handled.

openSUSE-RU-2014:0276-1: An update that has one recommended fix can now be installed.

Category: recommended (low)
Bug References: 853300
CVE References: 
Sources used:
openSUSE 13.1 (src):    systemd-presets-branding-openSUSE-0.3.0-3.4.1

Update for yast2 package for systemd socket support has been submitted to factory and openSUSE-13.1, see here: https://build.opensuse.org/request/show/224107

Update released for openSUSE 13.1. Resolved fixed.

Reopening the bug because also affects SLES12 (systemd socket support will be added).

openSUSE-RU-2014:0357-1: An update that has two recommended fixes can now be installed.

Category: recommended (moderate)
Bug References: 853300,864934
CVE References: 
Sources used:
openSUSE 13.1 (src):    yast2-3.0.13-13.1

Systemd support for iscsid.socket and start of iscsi.service added, 
yast-iscsi-client-3.1.4 submitted for SLES12.

This is an autogenerated message for OBS integration:
This bug (853300) was mentioned in
https://build.opensuse.org/request/show/228117 Factory / systemd-presets-branding-openSUSE