| 2018-03-14 16:20:17 |
Steve Langasek |
bug |
|
|
added bug |
| 2018-03-14 19:02:46 |
Scott Moser |
bug |
|
|
added subscriber Scott Moser |
| 2018-04-18 22:54:35 |
Steve Langasek |
open-iscsi (Ubuntu): importance |
Undecided |
High |
|
| 2018-04-18 22:54:36 |
Steve Langasek |
open-iscsi (Ubuntu): status |
New |
Triaged |
|
| 2018-04-18 22:56:21 |
Steve Langasek |
open-iscsi (Ubuntu): assignee |
|
Mathieu Trudel-Lapierre (cyphermox) |
|
| 2018-04-18 22:56:26 |
Steve Langasek |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-04-18 22:56:26 |
Steve Langasek |
bug task added |
|
open-iscsi (Ubuntu Bionic) |
|
| 2018-05-23 13:55:15 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/open-iscsi/+git/open-iscsi/+merge/346739 |
|
| 2018-05-24 15:43:04 |
Launchpad Janitor |
merge proposal unlinked |
https://code.launchpad.net/~paelzer/ubuntu/+source/open-iscsi/+git/open-iscsi/+merge/346739 |
|
|
| 2018-05-25 07:03:42 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/open-iscsi/+git/open-iscsi/+merge/346739 |
|
| 2018-05-29 13:34:13 |
Scott Moser |
description |
In bionic, the open-iscsi systemd unit has the following guards to keep it from running on systems with no iscsi targets configured:
# Must have some pre-defined targets to login to
ConditionDirectoryNotEmpty=|/etc/iscsi/nodes
# or have a session to use via iscsid
ConditionDirectoryNotEmpty=|/sys/class/iscsi_session
However, iscsid starts from a separate unit and does not include this check. Thus, iscsid starts on every Ubuntu Server install, whether or not it has anything to do.
We should replicate these unit conditionals to the iscsid unit, to ensure the daemon doesn't run (consuming memory, and slowing boot) when not needed. |
In bionic, the open-iscsi systemd unit has the following guards to keep it from running on systems with no iscsi targets configured:
# Must have some pre-defined targets to login to
ConditionDirectoryNotEmpty=|/etc/iscsi/nodes
# or have a session to use via iscsid
ConditionDirectoryNotEmpty=|/sys/class/iscsi_session
However, iscsid starts from a separate unit and does not include this check. Thus, iscsid starts on every Ubuntu Server install, whether or not it has anything to do.
We should replicate these unit conditionals to the iscsid unit, to ensure the daemon doesn't run (consuming memory, and slowing boot) when not needed.
Related bugs:
* bug 1630946: ubuntu-server depends on open-iscsi and runs iscsid Edit |
|
| 2018-05-29 13:34:23 |
Scott Moser |
description |
In bionic, the open-iscsi systemd unit has the following guards to keep it from running on systems with no iscsi targets configured:
# Must have some pre-defined targets to login to
ConditionDirectoryNotEmpty=|/etc/iscsi/nodes
# or have a session to use via iscsid
ConditionDirectoryNotEmpty=|/sys/class/iscsi_session
However, iscsid starts from a separate unit and does not include this check. Thus, iscsid starts on every Ubuntu Server install, whether or not it has anything to do.
We should replicate these unit conditionals to the iscsid unit, to ensure the daemon doesn't run (consuming memory, and slowing boot) when not needed.
Related bugs:
* bug 1630946: ubuntu-server depends on open-iscsi and runs iscsid Edit |
In bionic, the open-iscsi systemd unit has the following guards to keep it from running on systems with no iscsi targets configured:
# Must have some pre-defined targets to login to
ConditionDirectoryNotEmpty=|/etc/iscsi/nodes
# or have a session to use via iscsid
ConditionDirectoryNotEmpty=|/sys/class/iscsi_session
However, iscsid starts from a separate unit and does not include this check. Thus, iscsid starts on every Ubuntu Server install, whether or not it has anything to do.
We should replicate these unit conditionals to the iscsid unit, to ensure the daemon doesn't run (consuming memory, and slowing boot) when not needed.
Related bugs:
* bug 1630946: ubuntu-server depends on open-iscsi and runs iscsid |
|
| 2018-05-30 07:25:38 |
Christian Ehrhardt |
open-iscsi (Ubuntu): status |
Triaged |
Fix Committed |
|
| 2018-05-30 07:25:41 |
Christian Ehrhardt |
open-iscsi (Ubuntu): assignee |
Mathieu Trudel-Lapierre (cyphermox) |
|
|
| 2018-05-30 07:25:43 |
Christian Ehrhardt |
open-iscsi (Ubuntu Bionic): assignee |
Mathieu Trudel-Lapierre (cyphermox) |
|
|
| 2018-05-30 08:07:45 |
Christian Ehrhardt |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900397 |
|
| 2018-05-30 08:07:45 |
Christian Ehrhardt |
bug task added |
|
open-iscsi (Debian) |
|
| 2018-05-30 09:35:24 |
Bug Watch Updater |
open-iscsi (Debian): status |
Unknown |
New |
|
| 2018-06-01 06:58:21 |
Launchpad Janitor |
open-iscsi (Ubuntu): status |
Fix Committed |
Fix Released |
|
| 2018-06-01 08:10:31 |
Christian Ehrhardt |
open-iscsi (Ubuntu Bionic): status |
Triaged |
Won't Fix |
|
| 2018-06-01 19:30:32 |
Steve Langasek |
open-iscsi (Ubuntu Bionic): status |
Won't Fix |
Triaged |
|
| 2018-06-07 07:06:56 |
Christian Ehrhardt |
description |
In bionic, the open-iscsi systemd unit has the following guards to keep it from running on systems with no iscsi targets configured:
# Must have some pre-defined targets to login to
ConditionDirectoryNotEmpty=|/etc/iscsi/nodes
# or have a session to use via iscsid
ConditionDirectoryNotEmpty=|/sys/class/iscsi_session
However, iscsid starts from a separate unit and does not include this check. Thus, iscsid starts on every Ubuntu Server install, whether or not it has anything to do.
We should replicate these unit conditionals to the iscsid unit, to ensure the daemon doesn't run (consuming memory, and slowing boot) when not needed.
Related bugs:
* bug 1630946: ubuntu-server depends on open-iscsi and runs iscsid |
[Impact]
* Service is running uselessly which is consuming a few cycles/memory as
well as rasising general concerns e.g. on minimizing attack surfcae of
a system.
* Fix by switching to socket activation
[Test Case]
* After installing open-iscsi (which is default installed) the service
iscsid is running which is mostly useless
* After the upgrade only the iscsid.socket should run
* Ensure that iscsid.service should come up as needed
[Regression Potential]
* I'm not sure we can/shall SRU this, but was asked to express my
thoughts in the regression potential. It is not that it would not
"work", we tested in cosmic and so far all is fine - the tools will
call the abstract socket and it will spawn.
So it is not that I see it totally "failing"
* I'd more be concerned that one would have e.g. scripts and other upper
level code that does like:
if service-is-not-running; then break; else do what you should do
This would give up before socket-triggering it which might be too much
to SRU. On a Upgrade to a newer release such minor adaptions are usual,
but for SRUs?
* But also we don't stop the service on upgrade (for safety of the data),
so you'd have four different Bionics
a) old iscsid.service runnign by default
b) upgraded, but not rebooted iscsid.service still running
c) upgraded, rebooted iscid.service disabled,
iscsid.socket running
d) new deploy after this (e.g. new cloud image) iscid.service disabled,
iscsid.socket running
a+b are similar as well as c+d.
* OTOH there are a few things reducing this impact, first of all this is
a config, so one can "systemctl enable iscsid.service" and will have
the old behavior
* Is this a real blocker, I'm not sure - so I documented as requested and
would want the SRU team to discuss before an upload.
[Other Info]
* n/a
---
In bionic, the open-iscsi systemd unit has the following guards to keep it from running on systems with no iscsi targets configured:
# Must have some pre-defined targets to login to
ConditionDirectoryNotEmpty=|/etc/iscsi/nodes
# or have a session to use via iscsid
ConditionDirectoryNotEmpty=|/sys/class/iscsi_session
However, iscsid starts from a separate unit and does not include this check. Thus, iscsid starts on every Ubuntu Server install, whether or not it has anything to do.
We should replicate these unit conditionals to the iscsid unit, to ensure the daemon doesn't run (consuming memory, and slowing boot) when not needed.
Related bugs:
* bug 1630946: ubuntu-server depends on open-iscsi and runs iscsid |
|
| 2018-06-07 15:28:11 |
Steve Langasek |
description |
[Impact]
* Service is running uselessly which is consuming a few cycles/memory as
well as rasising general concerns e.g. on minimizing attack surfcae of
a system.
* Fix by switching to socket activation
[Test Case]
* After installing open-iscsi (which is default installed) the service
iscsid is running which is mostly useless
* After the upgrade only the iscsid.socket should run
* Ensure that iscsid.service should come up as needed
[Regression Potential]
* I'm not sure we can/shall SRU this, but was asked to express my
thoughts in the regression potential. It is not that it would not
"work", we tested in cosmic and so far all is fine - the tools will
call the abstract socket and it will spawn.
So it is not that I see it totally "failing"
* I'd more be concerned that one would have e.g. scripts and other upper
level code that does like:
if service-is-not-running; then break; else do what you should do
This would give up before socket-triggering it which might be too much
to SRU. On a Upgrade to a newer release such minor adaptions are usual,
but for SRUs?
* But also we don't stop the service on upgrade (for safety of the data),
so you'd have four different Bionics
a) old iscsid.service runnign by default
b) upgraded, but not rebooted iscsid.service still running
c) upgraded, rebooted iscid.service disabled,
iscsid.socket running
d) new deploy after this (e.g. new cloud image) iscid.service disabled,
iscsid.socket running
a+b are similar as well as c+d.
* OTOH there are a few things reducing this impact, first of all this is
a config, so one can "systemctl enable iscsid.service" and will have
the old behavior
* Is this a real blocker, I'm not sure - so I documented as requested and
would want the SRU team to discuss before an upload.
[Other Info]
* n/a
---
In bionic, the open-iscsi systemd unit has the following guards to keep it from running on systems with no iscsi targets configured:
# Must have some pre-defined targets to login to
ConditionDirectoryNotEmpty=|/etc/iscsi/nodes
# or have a session to use via iscsid
ConditionDirectoryNotEmpty=|/sys/class/iscsi_session
However, iscsid starts from a separate unit and does not include this check. Thus, iscsid starts on every Ubuntu Server install, whether or not it has anything to do.
We should replicate these unit conditionals to the iscsid unit, to ensure the daemon doesn't run (consuming memory, and slowing boot) when not needed.
Related bugs:
* bug 1630946: ubuntu-server depends on open-iscsi and runs iscsid |
[Impact]
* Service is running uselessly which is consuming a few cycles/memory as
well as rasising general concerns e.g. on minimizing attack surfcae of
a system.
* This is also the only service in a default server install which pulls in the network-online.target, which has implications for boot ordering and speed in various configurations.
* Fix by switching to socket activation
[Test Case]
* After installing open-iscsi (which is default installed) the service
iscsid is running which is mostly useless
* After the upgrade only the iscsid.socket should run
* Ensure that iscsid.service should come up as needed
[Regression Potential]
* I'm not sure we can/shall SRU this, but was asked to express my
thoughts in the regression potential. It is not that it would not
"work", we tested in cosmic and so far all is fine - the tools will
call the abstract socket and it will spawn.
So it is not that I see it totally "failing"
* I'd more be concerned that one would have e.g. scripts and other upper
level code that does like:
if service-is-not-running; then break; else do what you should do
This would give up before socket-triggering it which might be too much
to SRU. On a Upgrade to a newer release such minor adaptions are usual,
but for SRUs?
* But also we don't stop the service on upgrade (for safety of the data),
so you'd have four different Bionics
a) old iscsid.service runnign by default
b) upgraded, but not rebooted iscsid.service still running
c) upgraded, rebooted iscid.service disabled,
iscsid.socket running
d) new deploy after this (e.g. new cloud image) iscid.service disabled,
iscsid.socket running
a+b are similar as well as c+d.
* OTOH there are a few things reducing this impact, first of all this is
a config, so one can "systemctl enable iscsid.service" and will have
the old behavior
* Is this a real blocker, I'm not sure - so I documented as requested and
would want the SRU team to discuss before an upload.
[Other Info]
* n/a
---
In bionic, the open-iscsi systemd unit has the following guards to keep it from running on systems with no iscsi targets configured:
# Must have some pre-defined targets to login to
ConditionDirectoryNotEmpty=|/etc/iscsi/nodes
# or have a session to use via iscsid
ConditionDirectoryNotEmpty=|/sys/class/iscsi_session
However, iscsid starts from a separate unit and does not include this check. Thus, iscsid starts on every Ubuntu Server install, whether or not it has anything to do.
We should replicate these unit conditionals to the iscsid unit, to ensure the daemon doesn't run (consuming memory, and slowing boot) when not needed.
Related bugs:
* bug 1630946: ubuntu-server depends on open-iscsi and runs iscsid |
|
| 2018-06-07 15:44:36 |
Steve Langasek |
open-iscsi (Ubuntu Bionic): assignee |
|
Dimitri John Ledkov (xnox) |
|
| 2018-09-05 14:10:31 |
Scott Moser |
nominated for series |
|
Ubuntu Xenial |
|
| 2018-09-05 14:10:31 |
Scott Moser |
bug task added |
|
open-iscsi (Ubuntu Xenial) |
|
| 2018-09-06 16:39:17 |
Steve Langasek |
open-iscsi (Ubuntu Bionic): assignee |
Dimitri John Ledkov (xnox) |
|
|
| 2018-09-07 14:12:53 |
Scott Moser |
merge proposal linked |
|
https://code.launchpad.net/~smoser/ubuntu/+source/open-iscsi/+git/open-iscsi/+merge/354478 |
|
| 2018-09-07 14:13:07 |
Scott Moser |
merge proposal linked |
|
https://code.launchpad.net/~smoser/ubuntu/+source/open-iscsi/+git/open-iscsi/+merge/354483 |
|
| 2018-09-10 05:03:28 |
Christian Ehrhardt |
description |
[Impact]
* Service is running uselessly which is consuming a few cycles/memory as
well as rasising general concerns e.g. on minimizing attack surfcae of
a system.
* This is also the only service in a default server install which pulls in the network-online.target, which has implications for boot ordering and speed in various configurations.
* Fix by switching to socket activation
[Test Case]
* After installing open-iscsi (which is default installed) the service
iscsid is running which is mostly useless
* After the upgrade only the iscsid.socket should run
* Ensure that iscsid.service should come up as needed
[Regression Potential]
* I'm not sure we can/shall SRU this, but was asked to express my
thoughts in the regression potential. It is not that it would not
"work", we tested in cosmic and so far all is fine - the tools will
call the abstract socket and it will spawn.
So it is not that I see it totally "failing"
* I'd more be concerned that one would have e.g. scripts and other upper
level code that does like:
if service-is-not-running; then break; else do what you should do
This would give up before socket-triggering it which might be too much
to SRU. On a Upgrade to a newer release such minor adaptions are usual,
but for SRUs?
* But also we don't stop the service on upgrade (for safety of the data),
so you'd have four different Bionics
a) old iscsid.service runnign by default
b) upgraded, but not rebooted iscsid.service still running
c) upgraded, rebooted iscid.service disabled,
iscsid.socket running
d) new deploy after this (e.g. new cloud image) iscid.service disabled,
iscsid.socket running
a+b are similar as well as c+d.
* OTOH there are a few things reducing this impact, first of all this is
a config, so one can "systemctl enable iscsid.service" and will have
the old behavior
* Is this a real blocker, I'm not sure - so I documented as requested and
would want the SRU team to discuss before an upload.
[Other Info]
* n/a
---
In bionic, the open-iscsi systemd unit has the following guards to keep it from running on systems with no iscsi targets configured:
# Must have some pre-defined targets to login to
ConditionDirectoryNotEmpty=|/etc/iscsi/nodes
# or have a session to use via iscsid
ConditionDirectoryNotEmpty=|/sys/class/iscsi_session
However, iscsid starts from a separate unit and does not include this check. Thus, iscsid starts on every Ubuntu Server install, whether or not it has anything to do.
We should replicate these unit conditionals to the iscsid unit, to ensure the daemon doesn't run (consuming memory, and slowing boot) when not needed.
Related bugs:
* bug 1630946: ubuntu-server depends on open-iscsi and runs iscsid |
[Impact]
* Service is running uselessly which is consuming a few cycles/memory as
well as rasising general concerns e.g. on minimizing attack surfcae of
a system.
* This is also the only service in a default server install which pulls in the network-online.target, which has implications for boot ordering and speed in various configurations.
* Fix by switching to socket activation
[Test Case]
* After installing open-iscsi (which is default installed) the service
iscsid is running which is mostly useless
- this is a bit critical, as we don't want to stop a running service.
- so you have two cases
1. uninstall the package before upgrade; then install the new version.
should be service off, socket on
2. upgrade install, should have service (still) on, socket enabled.
3. after 2. reboot should be service off, socket on
* Also ensure that iscsid.service should come up as needed
# should be off
$ systemctl status iscsid.service iscsid.socket
$ iscsiadm -m discovery -t sendtargets -p 127.0.0.1
# should be enabled now
$ systemctl status iscsid.service iscsid.socket
[Regression Potential]
* We were discussing if we shall SRU this. First of all the change should
work as in the new version, abstract sockets are not super new.
* We were concerned that one would have e.g. scripts and other upper
level code that does like:
if service-is-not-running; then break; else do what you should do
This would give up before socket-triggering it which might be too much
to SRU. On a Upgrade to a newer release such minor adaptions are usual,
but for SRUs?
But in any config using it it will run, and as slangasek outlined " I
think anyone checking for the running status of an open-iscsi service,
on a system that does not have any iscsi targets configured, is writing
buggy code and that should not be catered to in the face of the
significant impact this bug has on all other users of Ubuntu Server."
* But also we don't stop the service on upgrade (for safety of the data),
so you'd have four different Bionics
a) old iscsid.service runnign by default
b) upgraded, but not rebooted iscsid.service still running
c) upgraded, rebooted iscid.service disabled,
iscsid.socket running
d) new deploy after this (e.g. new cloud image) iscid.service disabled,
iscsid.socket running
a+b are similar as well as c+d.
* If anyone strictly needs the old behavior it is a config, so one can
"systemctl enable iscsid.service" and is done.
* OTOH in our discussion it was agreed that the upgrade regression we fix
outweighs the potential regression.
[Other Info]
* n/a
---
In bionic, the open-iscsi systemd unit has the following guards to keep it from running on systems with no iscsi targets configured:
# Must have some pre-defined targets to login to
ConditionDirectoryNotEmpty=|/etc/iscsi/nodes
# or have a session to use via iscsid
ConditionDirectoryNotEmpty=|/sys/class/iscsi_session
However, iscsid starts from a separate unit and does not include this check. Thus, iscsid starts on every Ubuntu Server install, whether or not it has anything to do.
We should replicate these unit conditionals to the iscsid unit, to ensure the daemon doesn't run (consuming memory, and slowing boot) when not needed.
Related bugs:
* bug 1630946: ubuntu-server depends on open-iscsi and runs iscsid |
|
| 2018-09-10 06:04:45 |
Christian Ehrhardt |
bug |
|
|
added subscriber Chris Gregan |
| 2018-09-25 21:46:36 |
Steve Langasek |
description |
[Impact]
* Service is running uselessly which is consuming a few cycles/memory as
well as rasising general concerns e.g. on minimizing attack surfcae of
a system.
* This is also the only service in a default server install which pulls in the network-online.target, which has implications for boot ordering and speed in various configurations.
* Fix by switching to socket activation
[Test Case]
* After installing open-iscsi (which is default installed) the service
iscsid is running which is mostly useless
- this is a bit critical, as we don't want to stop a running service.
- so you have two cases
1. uninstall the package before upgrade; then install the new version.
should be service off, socket on
2. upgrade install, should have service (still) on, socket enabled.
3. after 2. reboot should be service off, socket on
* Also ensure that iscsid.service should come up as needed
# should be off
$ systemctl status iscsid.service iscsid.socket
$ iscsiadm -m discovery -t sendtargets -p 127.0.0.1
# should be enabled now
$ systemctl status iscsid.service iscsid.socket
[Regression Potential]
* We were discussing if we shall SRU this. First of all the change should
work as in the new version, abstract sockets are not super new.
* We were concerned that one would have e.g. scripts and other upper
level code that does like:
if service-is-not-running; then break; else do what you should do
This would give up before socket-triggering it which might be too much
to SRU. On a Upgrade to a newer release such minor adaptions are usual,
but for SRUs?
But in any config using it it will run, and as slangasek outlined " I
think anyone checking for the running status of an open-iscsi service,
on a system that does not have any iscsi targets configured, is writing
buggy code and that should not be catered to in the face of the
significant impact this bug has on all other users of Ubuntu Server."
* But also we don't stop the service on upgrade (for safety of the data),
so you'd have four different Bionics
a) old iscsid.service runnign by default
b) upgraded, but not rebooted iscsid.service still running
c) upgraded, rebooted iscid.service disabled,
iscsid.socket running
d) new deploy after this (e.g. new cloud image) iscid.service disabled,
iscsid.socket running
a+b are similar as well as c+d.
* If anyone strictly needs the old behavior it is a config, so one can
"systemctl enable iscsid.service" and is done.
* OTOH in our discussion it was agreed that the upgrade regression we fix
outweighs the potential regression.
[Other Info]
* n/a
---
In bionic, the open-iscsi systemd unit has the following guards to keep it from running on systems with no iscsi targets configured:
# Must have some pre-defined targets to login to
ConditionDirectoryNotEmpty=|/etc/iscsi/nodes
# or have a session to use via iscsid
ConditionDirectoryNotEmpty=|/sys/class/iscsi_session
However, iscsid starts from a separate unit and does not include this check. Thus, iscsid starts on every Ubuntu Server install, whether or not it has anything to do.
We should replicate these unit conditionals to the iscsid unit, to ensure the daemon doesn't run (consuming memory, and slowing boot) when not needed.
Related bugs:
* bug 1630946: ubuntu-server depends on open-iscsi and runs iscsid |
[Impact]
* Service is running uselessly which is consuming a few cycles/memory as
well as raising general concerns e.g. on minimizing attack surface of
a system.
* This is also the only service in a default server install which pulls in the network-online.target, which has implications for boot ordering and speed in various configurations.
* Fix by switching to socket activation
[Test Case]
* After installing open-iscsi (which is default installed) the service
iscsid is running which is mostly useless
- this is a bit critical, as we don't want to stop a running service.
- so you have two cases
1. uninstall the package before upgrade; then install the new version.
should be service off, socket on
2. upgrade install, should have service (still) on, socket enabled.
3. after 2. reboot should be service off, socket on
* Also ensure that iscsid.service should come up as needed
# should be off
$ systemctl status iscsid.service iscsid.socket
$ iscsiadm -m discovery -t sendtargets -p 127.0.0.1
# should be enabled now
$ systemctl status iscsid.service iscsid.socket
[Regression Potential]
* We were discussing if we shall SRU this. First of all the change should
work as in the new version, abstract sockets are not super new.
* We were concerned that one would have e.g. scripts and other upper
level code that does like:
if service-is-not-running; then break; else do what you should do
This would give up before socket-triggering it which might be too much
to SRU. On a Upgrade to a newer release such minor adaptions are usual,
but for SRUs?
But in any config using it it will run, and as slangasek outlined " I
think anyone checking for the running status of an open-iscsi service,
on a system that does not have any iscsi targets configured, is writing
buggy code and that should not be catered to in the face of the
significant impact this bug has on all other users of Ubuntu Server."
* But also we don't stop the service on upgrade (for safety of the data),
so you'd have four different Bionics
a) old iscsid.service runnign by default
b) upgraded, but not rebooted iscsid.service still running
c) upgraded, rebooted iscid.service disabled,
iscsid.socket running
d) new deploy after this (e.g. new cloud image) iscid.service disabled,
iscsid.socket running
a+b are similar as well as c+d.
* If anyone strictly needs the old behavior it is a config, so one can
"systemctl enable iscsid.service" and is done.
* OTOH in our discussion it was agreed that the upgrade regression we fix
outweighs the potential regression.
[Other Info]
* n/a
---
In bionic, the open-iscsi systemd unit has the following guards to keep it from running on systems with no iscsi targets configured:
# Must have some pre-defined targets to login to
ConditionDirectoryNotEmpty=|/etc/iscsi/nodes
# or have a session to use via iscsid
ConditionDirectoryNotEmpty=|/sys/class/iscsi_session
However, iscsid starts from a separate unit and does not include this check. Thus, iscsid starts on every Ubuntu Server install, whether or not it has anything to do.
We should replicate these unit conditionals to the iscsid unit, to ensure the daemon doesn't run (consuming memory, and slowing boot) when not needed.
Related bugs:
* bug 1630946: ubuntu-server depends on open-iscsi and runs iscsid |
|
| 2018-09-25 21:59:40 |
Steve Langasek |
open-iscsi (Ubuntu Bionic): status |
Triaged |
Fix Committed |
|
| 2018-09-25 21:59:42 |
Steve Langasek |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-09-25 21:59:43 |
Steve Langasek |
bug |
|
|
added subscriber SRU Verification |
| 2018-09-25 21:59:48 |
Steve Langasek |
tags |
|
verification-needed verification-needed-bionic |
|
| 2018-10-02 00:26:25 |
Scott Moser |
tags |
verification-needed verification-needed-bionic |
verification-done verification-done-bionic |
|
| 2018-10-02 17:54:12 |
Launchpad Janitor |
open-iscsi (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-10-02 17:54:18 |
Steve Langasek |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-11-08 21:48:28 |
Scott Moser |
description |
[Impact]
* Service is running uselessly which is consuming a few cycles/memory as
well as raising general concerns e.g. on minimizing attack surface of
a system.
* This is also the only service in a default server install which pulls in the network-online.target, which has implications for boot ordering and speed in various configurations.
* Fix by switching to socket activation
[Test Case]
* After installing open-iscsi (which is default installed) the service
iscsid is running which is mostly useless
- this is a bit critical, as we don't want to stop a running service.
- so you have two cases
1. uninstall the package before upgrade; then install the new version.
should be service off, socket on
2. upgrade install, should have service (still) on, socket enabled.
3. after 2. reboot should be service off, socket on
* Also ensure that iscsid.service should come up as needed
# should be off
$ systemctl status iscsid.service iscsid.socket
$ iscsiadm -m discovery -t sendtargets -p 127.0.0.1
# should be enabled now
$ systemctl status iscsid.service iscsid.socket
[Regression Potential]
* We were discussing if we shall SRU this. First of all the change should
work as in the new version, abstract sockets are not super new.
* We were concerned that one would have e.g. scripts and other upper
level code that does like:
if service-is-not-running; then break; else do what you should do
This would give up before socket-triggering it which might be too much
to SRU. On a Upgrade to a newer release such minor adaptions are usual,
but for SRUs?
But in any config using it it will run, and as slangasek outlined " I
think anyone checking for the running status of an open-iscsi service,
on a system that does not have any iscsi targets configured, is writing
buggy code and that should not be catered to in the face of the
significant impact this bug has on all other users of Ubuntu Server."
* But also we don't stop the service on upgrade (for safety of the data),
so you'd have four different Bionics
a) old iscsid.service runnign by default
b) upgraded, but not rebooted iscsid.service still running
c) upgraded, rebooted iscid.service disabled,
iscsid.socket running
d) new deploy after this (e.g. new cloud image) iscid.service disabled,
iscsid.socket running
a+b are similar as well as c+d.
* If anyone strictly needs the old behavior it is a config, so one can
"systemctl enable iscsid.service" and is done.
* OTOH in our discussion it was agreed that the upgrade regression we fix
outweighs the potential regression.
[Other Info]
* n/a
---
In bionic, the open-iscsi systemd unit has the following guards to keep it from running on systems with no iscsi targets configured:
# Must have some pre-defined targets to login to
ConditionDirectoryNotEmpty=|/etc/iscsi/nodes
# or have a session to use via iscsid
ConditionDirectoryNotEmpty=|/sys/class/iscsi_session
However, iscsid starts from a separate unit and does not include this check. Thus, iscsid starts on every Ubuntu Server install, whether or not it has anything to do.
We should replicate these unit conditionals to the iscsid unit, to ensure the daemon doesn't run (consuming memory, and slowing boot) when not needed.
Related bugs:
* bug 1630946: ubuntu-server depends on open-iscsi and runs iscsid |
[Impact]
* Service is running uselessly which is consuming a few cycles/memory as
well as raising general concerns e.g. on minimizing attack surface of
a system.
* This is also the only service in a default server install which pulls in the network-online.target, which has implications for boot ordering and speed in various configurations.
* Fix by switching to socket activation
[Test Case]
* After installing open-iscsi (which is default installed) the service
iscsid is running which is mostly useless
- this is a bit critical, as we don't want to stop a running service.
- so you have two cases
1. uninstall the package before upgrade; then install the new version.
should be service off, socket on
2. upgrade install, should have service (still) on, socket enabled.
3. after 2. reboot should be service off, socket on
* Also ensure that iscsid.service should come up as needed
# should be off
$ systemctl status iscsid.service iscsid.socket
$ iscsiadm -m discovery -t sendtargets -p 127.0.0.1
# should be enabled now
$ systemctl status iscsid.service iscsid.socket
[Regression Potential]
* We were discussing if we shall SRU this. First of all the change should
work as in the new version, abstract sockets are not super new.
* We were concerned that one would have e.g. scripts and other upper
level code that does like:
if service-is-not-running; then break; else do what you should do
This would give up before socket-triggering it which might be too much
to SRU. On a Upgrade to a newer release such minor adaptions are usual,
but for SRUs?
But in any config using it it will run, and as slangasek outlined " I
think anyone checking for the running status of an open-iscsi service,
on a system that does not have any iscsi targets configured, is writing
buggy code and that should not be catered to in the face of the
significant impact this bug has on all other users of Ubuntu Server."
* But also we don't stop the service on upgrade (for safety of the data),
so you'd have four different Bionics
a) old iscsid.service runnign by default
b) upgraded, but not rebooted iscsid.service still running
c) upgraded, rebooted iscid.service disabled,
iscsid.socket running
d) new deploy after this (e.g. new cloud image) iscid.service disabled,
iscsid.socket running
a+b are similar as well as c+d.
* If anyone strictly needs the old behavior it is a config, so one can
"systemctl enable iscsid.service" and is done.
* OTOH in our discussion it was agreed that the upgrade regression we fix
outweighs the potential regression.
[Other Info]
* The SRU of this change caused a regression described in bug 1802354.
---
In bionic, the open-iscsi systemd unit has the following guards to keep it from running on systems with no iscsi targets configured:
# Must have some pre-defined targets to login to
ConditionDirectoryNotEmpty=|/etc/iscsi/nodes
# or have a session to use via iscsid
ConditionDirectoryNotEmpty=|/sys/class/iscsi_session
However, iscsid starts from a separate unit and does not include this check. Thus, iscsid starts on every Ubuntu Server install, whether or not it has anything to do.
We should replicate these unit conditionals to the iscsid unit, to ensure the daemon doesn't run (consuming memory, and slowing boot) when not needed.
Related bugs:
* bug 1630946: ubuntu-server depends on open-iscsi and runs iscsid
* bug 1802354: iscsid does not run if there are only initramfs initiated targets |
|
| 2020-08-13 14:25:02 |
Rafael David Tinoco |
merge proposal linked |
|
https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/open-iscsi/+git/open-iscsi/+merge/389234 |
|
| 2022-08-03 07:13:11 |
Bug Watch Updater |
open-iscsi (Debian): status |
New |
Fix Released |
|
