| 2018-11-08 17:56:45 |
Scott Moser |
bug |
|
|
added bug |
| 2018-11-08 18:00:20 |
Joshua Powers |
bug |
|
|
added subscriber Joshua Powers |
| 2018-11-08 18:44:52 |
Scott Moser |
open-iscsi (Ubuntu): importance |
Undecided |
High |
|
| 2018-11-08 18:44:52 |
Scott Moser |
open-iscsi (Ubuntu): status |
New |
Confirmed |
|
| 2018-11-08 18:44:52 |
Scott Moser |
open-iscsi (Ubuntu): assignee |
|
Scott Moser (smoser) |
|
| 2018-11-08 21:48:58 |
Scott Moser |
description |
It was reported that after the changes made in bug 1755858, the iscsid
service was not running when initramfs (via iscsi_* params or iBft)
set up an iscsi mount.
This seems to not be a problem until there is a restart of the iscsi
*host* service or some other hiccup. Thus, in normal testing you will
not see this issue.
--
Related bugs:
* bug 1755858: iscsid autostarts on all servers when it has nothing to do Edit
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: open-iscsi 2.0.874-5ubuntu2.3 [modified: lib/systemd/system/open-iscsi.service]
ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18
Uname: Linux 4.15.0-36-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
Date: Thu Nov 8 17:42:46 2018
ProcEnviron:
TERM=screen.xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: open-iscsi
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.iscsi.iscsid.conf: 2018-10-12T16:51:00.187144 |
It was reported that after the changes made in bug 1755858, the iscsid
service was not running when initramfs (via iscsi_* params or iBft)
set up an iscsi mount.
This seems to not be a problem until there is a restart of the iscsi
*host* service or some other hiccup. Thus, in normal testing you will
not see this issue.
--
Related bugs:
* bug 1755858: iscsid autostarts on all servers when it has nothing to do.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: open-iscsi 2.0.874-5ubuntu2.3 [modified: lib/systemd/system/open-iscsi.service]
ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18
Uname: Linux 4.15.0-36-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
Date: Thu Nov 8 17:42:46 2018
ProcEnviron:
TERM=screen.xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: open-iscsi
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.iscsi.iscsid.conf: 2018-10-12T16:51:00.187144 |
|
| 2018-11-09 00:16:07 |
Steve Langasek |
bug |
|
|
added subscriber Steve Langasek |
| 2018-11-13 22:12:06 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~smoser/ubuntu/+source/open-iscsi/+git/open-iscsi/+merge/358737 |
|
| 2018-11-14 13:36:29 |
Francis Ginther |
tags |
amd64 apport-bug bionic uec-images |
amd64 apport-bug bionic id-5be36a3244fbc018f0cc1591 uec-images |
|
| 2018-11-15 05:15:21 |
Launchpad Janitor |
open-iscsi (Ubuntu): status |
Confirmed |
Fix Released |
|
| 2018-11-15 16:58:52 |
Scott Moser |
description |
It was reported that after the changes made in bug 1755858, the iscsid
service was not running when initramfs (via iscsi_* params or iBft)
set up an iscsi mount.
This seems to not be a problem until there is a restart of the iscsi
*host* service or some other hiccup. Thus, in normal testing you will
not see this issue.
--
Related bugs:
* bug 1755858: iscsid autostarts on all servers when it has nothing to do.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: open-iscsi 2.0.874-5ubuntu2.3 [modified: lib/systemd/system/open-iscsi.service]
ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18
Uname: Linux 4.15.0-36-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
Date: Thu Nov 8 17:42:46 2018
ProcEnviron:
TERM=screen.xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: open-iscsi
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.iscsi.iscsid.conf: 2018-10-12T16:51:00.187144 |
=== Begin SRU Template ===
[Impact]
A previous change to open-iscsi made under bug 1755858 caused a regression
that is seen when a system has only a single iscsi mount that was made
in the initramfs. The most likely scenario would be iscsi root.
The problem seen is that in this scenario the iscsid.service will not be
started. That generally works, but will have unexpected issues if
service is done to the iscsi target (external system). That could occur
if the remote system needed to be serviced for any reason. If iscsid
is running, the client will handle this scenario properly.
The change made here is to add a udev rule installed into
/lib/udev/rules.d/70-iscsi-disk.rules with the content:
SUBSYSTEM=="block", ACTION=="add", ENV{ID_PATH}=="*-iscsi-*",
ENV{SYSTEMD_WANTS}="iscsid.service"
The key things to see in that rule are:
a.) only matches on add of a block device.
We will not currently stop the iscsid.service ever via udev.
b.) only matches a PATH with '-iscsi-' in it.
tests show that ID_PATH will come up with something like:
ip-<ipv4-dotted-quad>:<port>-iscsi-<target>-lun-<lun>
example:
ip-192.168.1.1:3270-iscsi-mydisk1-lun-2
See other info section below for a 'udevadm info' output.
c.) uses SYSTEMD_WANTS.
More information can be seen on that at
https://www.freedesktop.org/software/systemd/man/systemd.device.html
doc states:
"[systemd_wants] may be used to activate arbitrary units when a specific
device becomes available."
[Test Case]
A check for iscsid.service to be running has been added to the dep8
test of the open-iscsi package. The simplist check is to have
the dep8 test run. The test will gate entry into -proposed so
we can have confidence the bug is fixed.
Since this bug was originally reported on Oracle public cloud instances
we should also test that platform.
To do that:
* launch a hardware instance on oracle of 16.04.
* verify iscsid.service is *not* running.
If iscsid.service is already running, it may have been started by
an image modification. To make this a valid test, you will
then need to disable whatever change made that occur.
* enable proposed and upgrade
* reboot
* verify that iscsid.service is running.
[Regression Potential]
The most likely chance for regression here would be the iscsid.service
running when it should not be running. Saving a udev rule execution
error, a false-positive on the 'match' above would trigger this.
It seems relatively unlikely that a non-iscsi device would have a ID_PATH
containing '-iscsi-', but is possible.
[Other Info]
Here is output of 'udevadm info' on a iscsi root device:
http://paste.ubuntu.com/p/dj89ScVR82/
=== End SRU Template ===
It was reported that after the changes made in bug 1755858, the iscsid
service was not running when initramfs (via iscsi_* params or iBft)
set up an iscsi mount.
This seems to not be a problem until there is a restart of the iscsi
*host* service or some other hiccup. Thus, in normal testing you will
not see this issue.
--
Related bugs:
* bug 1755858: iscsid autostarts on all servers when it has nothing to do.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: open-iscsi 2.0.874-5ubuntu2.3 [modified: lib/systemd/system/open-iscsi.service]
ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18
Uname: Linux 4.15.0-36-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
Date: Thu Nov 8 17:42:46 2018
ProcEnviron:
TERM=screen.xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: open-iscsi
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.iscsi.iscsid.conf: 2018-10-12T16:51:00.187144 |
|
| 2018-11-15 16:59:00 |
Scott Moser |
nominated for series |
|
Ubuntu Cosmic |
|
| 2018-11-15 16:59:00 |
Scott Moser |
bug task added |
|
open-iscsi (Ubuntu Cosmic) |
|
| 2018-11-15 16:59:00 |
Scott Moser |
nominated for series |
|
Ubuntu Bionic |
|
| 2018-11-15 16:59:00 |
Scott Moser |
bug task added |
|
open-iscsi (Ubuntu Bionic) |
|
| 2018-11-15 17:01:45 |
Scott Moser |
open-iscsi (Ubuntu Bionic): status |
New |
Confirmed |
|
| 2018-11-15 17:01:47 |
Scott Moser |
open-iscsi (Ubuntu Cosmic): status |
New |
Confirmed |
|
| 2018-11-15 17:01:53 |
Scott Moser |
open-iscsi (Ubuntu Bionic): importance |
Undecided |
High |
|
| 2018-11-15 17:01:55 |
Scott Moser |
open-iscsi (Ubuntu Cosmic): importance |
Undecided |
High |
|
| 2018-11-15 17:01:57 |
Scott Moser |
open-iscsi (Ubuntu Bionic): assignee |
|
Scott Moser (smoser) |
|
| 2018-11-15 17:01:59 |
Scott Moser |
open-iscsi (Ubuntu Cosmic): assignee |
|
Scott Moser (smoser) |
|
| 2018-11-15 17:02:02 |
Scott Moser |
open-iscsi (Ubuntu Bionic): status |
Confirmed |
In Progress |
|
| 2018-11-15 17:02:04 |
Scott Moser |
open-iscsi (Ubuntu Cosmic): status |
Confirmed |
In Progress |
|
| 2018-11-15 18:13:29 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~smoser/ubuntu/+source/open-iscsi/+git/open-iscsi/+merge/358860 |
|
| 2018-11-15 18:14:29 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~smoser/ubuntu/+source/open-iscsi/+git/open-iscsi/+merge/358861 |
|
| 2018-11-15 18:37:23 |
Scott Moser |
description |
=== Begin SRU Template ===
[Impact]
A previous change to open-iscsi made under bug 1755858 caused a regression
that is seen when a system has only a single iscsi mount that was made
in the initramfs. The most likely scenario would be iscsi root.
The problem seen is that in this scenario the iscsid.service will not be
started. That generally works, but will have unexpected issues if
service is done to the iscsi target (external system). That could occur
if the remote system needed to be serviced for any reason. If iscsid
is running, the client will handle this scenario properly.
The change made here is to add a udev rule installed into
/lib/udev/rules.d/70-iscsi-disk.rules with the content:
SUBSYSTEM=="block", ACTION=="add", ENV{ID_PATH}=="*-iscsi-*",
ENV{SYSTEMD_WANTS}="iscsid.service"
The key things to see in that rule are:
a.) only matches on add of a block device.
We will not currently stop the iscsid.service ever via udev.
b.) only matches a PATH with '-iscsi-' in it.
tests show that ID_PATH will come up with something like:
ip-<ipv4-dotted-quad>:<port>-iscsi-<target>-lun-<lun>
example:
ip-192.168.1.1:3270-iscsi-mydisk1-lun-2
See other info section below for a 'udevadm info' output.
c.) uses SYSTEMD_WANTS.
More information can be seen on that at
https://www.freedesktop.org/software/systemd/man/systemd.device.html
doc states:
"[systemd_wants] may be used to activate arbitrary units when a specific
device becomes available."
[Test Case]
A check for iscsid.service to be running has been added to the dep8
test of the open-iscsi package. The simplist check is to have
the dep8 test run. The test will gate entry into -proposed so
we can have confidence the bug is fixed.
Since this bug was originally reported on Oracle public cloud instances
we should also test that platform.
To do that:
* launch a hardware instance on oracle of 16.04.
* verify iscsid.service is *not* running.
If iscsid.service is already running, it may have been started by
an image modification. To make this a valid test, you will
then need to disable whatever change made that occur.
* enable proposed and upgrade
* reboot
* verify that iscsid.service is running.
[Regression Potential]
The most likely chance for regression here would be the iscsid.service
running when it should not be running. Saving a udev rule execution
error, a false-positive on the 'match' above would trigger this.
It seems relatively unlikely that a non-iscsi device would have a ID_PATH
containing '-iscsi-', but is possible.
[Other Info]
Here is output of 'udevadm info' on a iscsi root device:
http://paste.ubuntu.com/p/dj89ScVR82/
=== End SRU Template ===
It was reported that after the changes made in bug 1755858, the iscsid
service was not running when initramfs (via iscsi_* params or iBft)
set up an iscsi mount.
This seems to not be a problem until there is a restart of the iscsi
*host* service or some other hiccup. Thus, in normal testing you will
not see this issue.
--
Related bugs:
* bug 1755858: iscsid autostarts on all servers when it has nothing to do.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: open-iscsi 2.0.874-5ubuntu2.3 [modified: lib/systemd/system/open-iscsi.service]
ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18
Uname: Linux 4.15.0-36-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
Date: Thu Nov 8 17:42:46 2018
ProcEnviron:
TERM=screen.xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: open-iscsi
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.iscsi.iscsid.conf: 2018-10-12T16:51:00.187144 |
=== Begin SRU Template ===
[Impact]
A previous change to open-iscsi made under bug 1755858 caused a regression
that is seen when a system has only a single iscsi mount that was made
in the initramfs. The most likely scenario would be iscsi root.
The problem seen is that in this scenario the iscsid.service will not be
started. That generally works, but will have unexpected issues if
service is done to the iscsi target (external system). That could occur
if the remote system needed to be serviced for any reason. If iscsid
is running, the client will handle this scenario properly.
The change made here is to add a udev rule installed into
/lib/udev/rules.d/70-iscsi-disk.rules with the content:
SUBSYSTEM=="block", ACTION=="add", ENV{ID_PATH}=="*-iscsi-*",
ENV{SYSTEMD_WANTS}="iscsid.service"
The key things to see in that rule are:
a.) only matches on add of a block device.
We will not currently stop the iscsid.service ever via udev.
b.) only matches a PATH with '-iscsi-' in it.
tests show that ID_PATH will come up with something like:
ip-<ipv4-dotted-quad>:<port>-iscsi-<target>-lun-<lun>
example:
ip-192.168.1.1:3270-iscsi-mydisk1-lun-2
See other info section below for a 'udevadm info' output.
c.) uses SYSTEMD_WANTS.
More information can be seen on that at
https://www.freedesktop.org/software/systemd/man/systemd.device.html
doc states:
"[systemd_wants] may be used to activate arbitrary units when a specific
device becomes available."
[Test Case]
A check for iscsid.service to be running has been added to the dep8
test of the open-iscsi package. The simplist check is to have
the dep8 test run. The test will gate entry into -proposed so
we can have confidence the bug is fixed.
Since this bug was originally reported on Oracle public cloud instances
we should also test that platform.
To do that:
* launch a hardware instance on oracle of 16.04.
* verify iscsid.service is *not* running.
If iscsid.service is already running, it may have been started by
an image modification. To make this a valid test, you will
then need to disable whatever change made that occur.
* enable proposed and upgrade
* reboot
* verify that iscsid.service is running.
[Regression Potential]
The most likely chance for regression here would be the iscsid.service
running when it should not be running. Saving a udev rule execution
error, a false-positive on the 'match' above would trigger this.
It seems relatively unlikely that a non-iscsi device would have a ID_PATH
containing '-iscsi-', but is possible.
[Other Info]
Here is output of 'udevadm info' on a iscsi root device:
http://paste.ubuntu.com/p/dj89ScVR82/
There is autopkgtest run of proposed
bionic: http://paste.ubuntu.com/p/FqPPtD8jV6/
cosmic: http://paste.ubuntu.com/p/Fb3rYP7Xhs/
=== End SRU Template ===
It was reported that after the changes made in bug 1755858, the iscsid
service was not running when initramfs (via iscsi_* params or iBft)
set up an iscsi mount.
This seems to not be a problem until there is a restart of the iscsi
*host* service or some other hiccup. Thus, in normal testing you will
not see this issue.
--
Related bugs:
* bug 1755858: iscsid autostarts on all servers when it has nothing to do.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: open-iscsi 2.0.874-5ubuntu2.3 [modified: lib/systemd/system/open-iscsi.service]
ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18
Uname: Linux 4.15.0-36-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
Date: Thu Nov 8 17:42:46 2018
ProcEnviron:
TERM=screen.xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: open-iscsi
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.iscsi.iscsid.conf: 2018-10-12T16:51:00.187144 |
|
| 2018-11-15 19:52:08 |
Scott Moser |
description |
=== Begin SRU Template ===
[Impact]
A previous change to open-iscsi made under bug 1755858 caused a regression
that is seen when a system has only a single iscsi mount that was made
in the initramfs. The most likely scenario would be iscsi root.
The problem seen is that in this scenario the iscsid.service will not be
started. That generally works, but will have unexpected issues if
service is done to the iscsi target (external system). That could occur
if the remote system needed to be serviced for any reason. If iscsid
is running, the client will handle this scenario properly.
The change made here is to add a udev rule installed into
/lib/udev/rules.d/70-iscsi-disk.rules with the content:
SUBSYSTEM=="block", ACTION=="add", ENV{ID_PATH}=="*-iscsi-*",
ENV{SYSTEMD_WANTS}="iscsid.service"
The key things to see in that rule are:
a.) only matches on add of a block device.
We will not currently stop the iscsid.service ever via udev.
b.) only matches a PATH with '-iscsi-' in it.
tests show that ID_PATH will come up with something like:
ip-<ipv4-dotted-quad>:<port>-iscsi-<target>-lun-<lun>
example:
ip-192.168.1.1:3270-iscsi-mydisk1-lun-2
See other info section below for a 'udevadm info' output.
c.) uses SYSTEMD_WANTS.
More information can be seen on that at
https://www.freedesktop.org/software/systemd/man/systemd.device.html
doc states:
"[systemd_wants] may be used to activate arbitrary units when a specific
device becomes available."
[Test Case]
A check for iscsid.service to be running has been added to the dep8
test of the open-iscsi package. The simplist check is to have
the dep8 test run. The test will gate entry into -proposed so
we can have confidence the bug is fixed.
Since this bug was originally reported on Oracle public cloud instances
we should also test that platform.
To do that:
* launch a hardware instance on oracle of 16.04.
* verify iscsid.service is *not* running.
If iscsid.service is already running, it may have been started by
an image modification. To make this a valid test, you will
then need to disable whatever change made that occur.
* enable proposed and upgrade
* reboot
* verify that iscsid.service is running.
[Regression Potential]
The most likely chance for regression here would be the iscsid.service
running when it should not be running. Saving a udev rule execution
error, a false-positive on the 'match' above would trigger this.
It seems relatively unlikely that a non-iscsi device would have a ID_PATH
containing '-iscsi-', but is possible.
[Other Info]
Here is output of 'udevadm info' on a iscsi root device:
http://paste.ubuntu.com/p/dj89ScVR82/
There is autopkgtest run of proposed
bionic: http://paste.ubuntu.com/p/FqPPtD8jV6/
cosmic: http://paste.ubuntu.com/p/Fb3rYP7Xhs/
=== End SRU Template ===
It was reported that after the changes made in bug 1755858, the iscsid
service was not running when initramfs (via iscsi_* params or iBft)
set up an iscsi mount.
This seems to not be a problem until there is a restart of the iscsi
*host* service or some other hiccup. Thus, in normal testing you will
not see this issue.
--
Related bugs:
* bug 1755858: iscsid autostarts on all servers when it has nothing to do.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: open-iscsi 2.0.874-5ubuntu2.3 [modified: lib/systemd/system/open-iscsi.service]
ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18
Uname: Linux 4.15.0-36-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
Date: Thu Nov 8 17:42:46 2018
ProcEnviron:
TERM=screen.xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: open-iscsi
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.iscsi.iscsid.conf: 2018-10-12T16:51:00.187144 |
=== Begin SRU Template ===
[Impact]
A previous change to open-iscsi made under bug 1755858 caused a regression
that is seen when a system has only a iscsi mounts that were made
in the initramfs. The most likely scenario would be iscsi root.
The problem seen is that in this scenario the iscsid.service will not be
started. That generally works, but will have unexpected issues if
service is done to the iscsi target (external system). That could occur
if the remote system needed to be serviced for any reason. If iscsid
is running, the client will handle this scenario properly.
The change made here is to add a udev rule installed into
/lib/udev/rules.d/70-iscsi-disk.rules with the content:
SUBSYSTEM=="block", ACTION=="add", ENV{ID_PATH}=="*-iscsi-*",
ENV{SYSTEMD_WANTS}="iscsid.service"
The key things to see in that rule are:
a.) only matches on add of a block device.
We will not currently stop the iscsid.service ever via udev.
b.) only matches a PATH with '-iscsi-' in it.
tests show that ID_PATH will come up with something like:
ip-<ipv4-dotted-quad>:<port>-iscsi-<target>-lun-<lun>
example:
ip-192.168.1.1:3270-iscsi-mydisk1-lun-2
See other info section below for a 'udevadm info' output.
c.) uses SYSTEMD_WANTS.
More information can be seen on that at
https://www.freedesktop.org/software/systemd/man/systemd.device.html
doc states:
"[systemd_wants] may be used to activate arbitrary units when a specific
device becomes available."
[Test Case]
A check for iscsid.service to be running has been added to the dep8
test of the open-iscsi package. The simplist check is to have
the dep8 test run. The test will gate entry into -proposed so
we can have confidence the bug is fixed.
Since this bug was originally reported on Oracle public cloud instances
we should also test that platform.
To do that:
* launch a hardware instance on oracle of 16.04.
* verify iscsid.service is *not* running.
If iscsid.service is already running, it may have been started by
an image modification. To make this a valid test, you will
then need to disable whatever change made that occur.
* enable proposed and upgrade
* reboot
* verify that iscsid.service is running.
[Regression Potential]
The most likely chance for regression here would be the iscsid.service
running when it should not be running. Saving a udev rule execution
error, a false-positive on the 'match' above would trigger this.
It seems relatively unlikely that a non-iscsi device would have a ID_PATH
containing '-iscsi-', but is possible.
[Other Info]
Here is output of 'udevadm info' on a iscsi root device:
http://paste.ubuntu.com/p/dj89ScVR82/
There is autopkgtest run of proposed
bionic: http://paste.ubuntu.com/p/FqPPtD8jV6/
cosmic: http://paste.ubuntu.com/p/Fb3rYP7Xhs/
=== End SRU Template ===
It was reported that after the changes made in bug 1755858, the iscsid
service was not running when initramfs (via iscsi_* params or iBft)
set up an iscsi mount.
This seems to not be a problem until there is a restart of the iscsi
*host* service or some other hiccup. Thus, in normal testing you will
not see this issue.
--
Related bugs:
* bug 1755858: iscsid autostarts on all servers when it has nothing to do.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: open-iscsi 2.0.874-5ubuntu2.3 [modified: lib/systemd/system/open-iscsi.service]
ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18
Uname: Linux 4.15.0-36-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
Date: Thu Nov 8 17:42:46 2018
ProcEnviron:
TERM=screen.xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: open-iscsi
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.iscsi.iscsid.conf: 2018-10-12T16:51:00.187144 |
|
| 2018-11-20 17:15:50 |
Brian Murray |
open-iscsi (Ubuntu Cosmic): status |
In Progress |
Fix Committed |
|
| 2018-11-20 17:15:52 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2018-11-20 17:15:56 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2018-11-20 17:16:01 |
Brian Murray |
tags |
amd64 apport-bug bionic id-5be36a3244fbc018f0cc1591 uec-images |
amd64 apport-bug bionic id-5be36a3244fbc018f0cc1591 uec-images verification-needed verification-needed-cosmic |
|
| 2018-11-20 17:18:17 |
Brian Murray |
open-iscsi (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2018-11-20 17:18:24 |
Brian Murray |
tags |
amd64 apport-bug bionic id-5be36a3244fbc018f0cc1591 uec-images verification-needed verification-needed-cosmic |
amd64 apport-bug bionic id-5be36a3244fbc018f0cc1591 uec-images verification-needed verification-needed-bionic verification-needed-cosmic |
|
| 2018-11-27 20:06:10 |
Scott Moser |
attachment added |
|
bionic autopkg console log https://bugs.launchpad.net/ubuntu/cosmic/+source/open-iscsi/+bug/1802354/+attachment/5216832/+files/bionic-autopkgtest.log |
|
| 2018-11-27 20:06:40 |
Scott Moser |
attachment added |
|
bionic autopkg test artifacts https://bugs.launchpad.net/ubuntu/cosmic/+source/open-iscsi/+bug/1802354/+attachment/5216833/+files/bionic-autopkgtest-artifacts.tar.gz |
|
| 2018-11-27 20:07:49 |
Scott Moser |
tags |
amd64 apport-bug bionic id-5be36a3244fbc018f0cc1591 uec-images verification-needed verification-needed-bionic verification-needed-cosmic |
amd64 apport-bug bionic id-5be36a3244fbc018f0cc1591 uec-images verification-done-bionic verification-needed verification-needed-cosmic |
|
| 2018-11-27 20:46:42 |
Scott Moser |
attachment added |
|
cosmic autopkgtest artifacts https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1802354/+attachment/5216835/+files/cosmic-autopkgtest-artifacts.tar.gz |
|
| 2018-11-27 20:47:05 |
Scott Moser |
attachment added |
|
cosmic autopkgtest console log https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1802354/+attachment/5216836/+files/cosmic-autopkgtest.log |
|
| 2018-11-27 20:47:32 |
Scott Moser |
tags |
amd64 apport-bug bionic id-5be36a3244fbc018f0cc1591 uec-images verification-done-bionic verification-needed verification-needed-cosmic |
amd64 apport-bug bionic id-5be36a3244fbc018f0cc1591 uec-images verification-done verification-done-bionic verification-done-cosmic |
|
| 2018-11-29 21:54:33 |
Launchpad Janitor |
open-iscsi (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2018-11-29 21:54:37 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2018-12-04 20:04:49 |
Launchpad Janitor |
open-iscsi (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2018-12-19 15:05:53 |
Scott Moser |
description |
=== Begin SRU Template ===
[Impact]
A previous change to open-iscsi made under bug 1755858 caused a regression
that is seen when a system has only a iscsi mounts that were made
in the initramfs. The most likely scenario would be iscsi root.
The problem seen is that in this scenario the iscsid.service will not be
started. That generally works, but will have unexpected issues if
service is done to the iscsi target (external system). That could occur
if the remote system needed to be serviced for any reason. If iscsid
is running, the client will handle this scenario properly.
The change made here is to add a udev rule installed into
/lib/udev/rules.d/70-iscsi-disk.rules with the content:
SUBSYSTEM=="block", ACTION=="add", ENV{ID_PATH}=="*-iscsi-*",
ENV{SYSTEMD_WANTS}="iscsid.service"
The key things to see in that rule are:
a.) only matches on add of a block device.
We will not currently stop the iscsid.service ever via udev.
b.) only matches a PATH with '-iscsi-' in it.
tests show that ID_PATH will come up with something like:
ip-<ipv4-dotted-quad>:<port>-iscsi-<target>-lun-<lun>
example:
ip-192.168.1.1:3270-iscsi-mydisk1-lun-2
See other info section below for a 'udevadm info' output.
c.) uses SYSTEMD_WANTS.
More information can be seen on that at
https://www.freedesktop.org/software/systemd/man/systemd.device.html
doc states:
"[systemd_wants] may be used to activate arbitrary units when a specific
device becomes available."
[Test Case]
A check for iscsid.service to be running has been added to the dep8
test of the open-iscsi package. The simplist check is to have
the dep8 test run. The test will gate entry into -proposed so
we can have confidence the bug is fixed.
Since this bug was originally reported on Oracle public cloud instances
we should also test that platform.
To do that:
* launch a hardware instance on oracle of 16.04.
* verify iscsid.service is *not* running.
If iscsid.service is already running, it may have been started by
an image modification. To make this a valid test, you will
then need to disable whatever change made that occur.
* enable proposed and upgrade
* reboot
* verify that iscsid.service is running.
[Regression Potential]
The most likely chance for regression here would be the iscsid.service
running when it should not be running. Saving a udev rule execution
error, a false-positive on the 'match' above would trigger this.
It seems relatively unlikely that a non-iscsi device would have a ID_PATH
containing '-iscsi-', but is possible.
[Other Info]
Here is output of 'udevadm info' on a iscsi root device:
http://paste.ubuntu.com/p/dj89ScVR82/
There is autopkgtest run of proposed
bionic: http://paste.ubuntu.com/p/FqPPtD8jV6/
cosmic: http://paste.ubuntu.com/p/Fb3rYP7Xhs/
=== End SRU Template ===
It was reported that after the changes made in bug 1755858, the iscsid
service was not running when initramfs (via iscsi_* params or iBft)
set up an iscsi mount.
This seems to not be a problem until there is a restart of the iscsi
*host* service or some other hiccup. Thus, in normal testing you will
not see this issue.
--
Related bugs:
* bug 1755858: iscsid autostarts on all servers when it has nothing to do.
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: open-iscsi 2.0.874-5ubuntu2.3 [modified: lib/systemd/system/open-iscsi.service]
ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18
Uname: Linux 4.15.0-36-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
Date: Thu Nov 8 17:42:46 2018
ProcEnviron:
TERM=screen.xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: open-iscsi
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.iscsi.iscsid.conf: 2018-10-12T16:51:00.187144 |
=== Begin SRU Template ===
[Impact]
A previous change to open-iscsi made under bug 1755858 caused a regression
that is seen when a system has only a iscsi mounts that were made
in the initramfs. The most likely scenario would be iscsi root.
The problem seen is that in this scenario the iscsid.service will not be
started. That generally works, but will have unexpected issues if
service is done to the iscsi target (external system). That could occur
if the remote system needed to be serviced for any reason. If iscsid
is running, the client will handle this scenario properly.
The change made here is to add a udev rule installed into
/lib/udev/rules.d/70-iscsi-disk.rules with the content:
SUBSYSTEM=="block", ACTION=="add", ENV{ID_PATH}=="*-iscsi-*",
ENV{SYSTEMD_WANTS}="iscsid.service"
The key things to see in that rule are:
a.) only matches on add of a block device.
We will not currently stop the iscsid.service ever via udev.
b.) only matches a PATH with '-iscsi-' in it.
tests show that ID_PATH will come up with something like:
ip-<ipv4-dotted-quad>:<port>-iscsi-<target>-lun-<lun>
example:
ip-192.168.1.1:3270-iscsi-mydisk1-lun-2
See other info section below for a 'udevadm info' output.
c.) uses SYSTEMD_WANTS.
More information can be seen on that at
https://www.freedesktop.org/software/systemd/man/systemd.device.html
doc states:
"[systemd_wants] may be used to activate arbitrary units when a specific
device becomes available."
[Test Case]
A check for iscsid.service to be running has been added to the dep8
test of the open-iscsi package. The simplist check is to have
the dep8 test run. The test will gate entry into -proposed so
we can have confidence the bug is fixed.
Since this bug was originally reported on Oracle public cloud instances
we should also test that platform.
To do that:
* launch a hardware instance on oracle of 16.04.
* verify iscsid.service is *not* running.
If iscsid.service is already running, it may have been started by
an image modification. To make this a valid test, you will
then need to disable whatever change made that occur.
* enable proposed and upgrade
* reboot
* verify that iscsid.service is running.
[Regression Potential]
The most likely chance for regression here would be the iscsid.service
running when it should not be running. Saving a udev rule execution
error, a false-positive on the 'match' above would trigger this.
It seems relatively unlikely that a non-iscsi device would have a ID_PATH
containing '-iscsi-', but is possible.
**Note**: This change caused regression described in bug 1807978.
[Other Info]
Here is output of 'udevadm info' on a iscsi root device:
http://paste.ubuntu.com/p/dj89ScVR82/
There is autopkgtest run of proposed
bionic: http://paste.ubuntu.com/p/FqPPtD8jV6/
cosmic: http://paste.ubuntu.com/p/Fb3rYP7Xhs/
=== End SRU Template ===
It was reported that after the changes made in bug 1755858, the iscsid
service was not running when initramfs (via iscsi_* params or iBft)
set up an iscsi mount.
This seems to not be a problem until there is a restart of the iscsi
*host* service or some other hiccup. Thus, in normal testing you will
not see this issue.
--
Related bugs:
* bug 1755858: iscsid autostarts on all servers when it has nothing to do.
* bug 1807978: vmtest: iscsi/LVM tests failing on cosmic/disco
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: open-iscsi 2.0.874-5ubuntu2.3 [modified: lib/systemd/system/open-iscsi.service]
ProcVersionSignature: Ubuntu 4.15.0-36.39-generic 4.15.18
Uname: Linux 4.15.0-36-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.4
Architecture: amd64
Date: Thu Nov 8 17:42:46 2018
ProcEnviron:
TERM=screen.xterm-256color
PATH=(custom, no user)
LANG=C.UTF-8
SHELL=/bin/bash
SourcePackage: open-iscsi
UpgradeStatus: No upgrade log present (probably fresh install)
mtime.conffile..etc.iscsi.iscsid.conf: 2018-10-12T16:51:00.187144 |
|
