make the service fail gracefully if unable to load modules
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu Cloud Archive |
Triaged
|
High
|
Unassigned | ||
Ussuri |
Fix Released
|
Undecided
|
Unassigned | ||
rtslib-fb |
New
|
Unknown
|
|||
python-rtslib-fb (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Focal |
Fix Released
|
Undecided
|
Unassigned | ||
Groovy |
Fix Released
|
Undecided
|
Unassigned |
Bug Description
[Impact]
========
The LIO interfaces is inherently tied to the kernel.
That makes the service fail on e.g. a container install:
See "systemctl status rtslib-
root@f:~# systemctl status rtslib-
● rtslib-
Loaded: loaded (/lib/systemd/
Active: failed (Result: exit-code) since Thu 2020-02-27 14:10:35 UTC; 3s ago
Process: 23831 ExecStart=
Process: 23832 ExecStart=
Main PID: 23832 (code=exited, status=1/FAILURE)
Feb 27 14:10:35 f target[23832]: File "/usr/bin/
Feb 27 14:10:35 f target[23832]: errors = RTSRoot(
Feb 27 14:10:35 f target[23832]: File "/usr/lib/
Feb 27 14:10:35 f target[23832]: modprobe(
Feb 27 14:10:35 f target[23832]: File "/usr/lib/
Feb 27 14:10:35 f target[23832]: raise RTSLibError(
Feb 27 14:10:35 f target[23832]: rtslib_
Feb 27 14:10:35 f systemd[1]: rtslib-
Feb 27 14:10:35 f systemd[1]: rtslib-
Feb 27 14:10:35 f systemd[1]: Failed to start Restore LIO kernel target configuration.
It is ok that this doesn't work in a container, but it also breaks the package installation status which should be avoided.
[Test Plan]
===========
To reproduce this bug, simply do the following:
$ lxc launch ubuntu-daily:groovy python-
$ lxc shell python-
# apt update && apt upgrade
# reboot
# apt install python3-rtslib-fb
...and this should fail to install.
To make sure that this bug is indeed fixed, install the patched version of this package and that should install fine.
[Where problems could occur]
=======
This is a workaround since there doesn't seem to be a in-container use case. But in case there is one, then that'd fail to work, so we might better find a better solution for this in the long term.
The disccusion has been initiated upstream (cf: https:/
Related branches
- Christian Ehrhardt (community): Approve
- Canonical Server: Pending requested
- git-ubuntu developers: Pending requested
-
Diff: 28 lines (+9/-0)2 files modifieddebian/changelog (+8/-0)
debian/python3-rtslib-fb.rtslib-fb-targetctl.service (+1/-0)
- Christian Ehrhardt (community): Approve
- Canonical Server packageset reviewers: Pending requested
- Canonical Server: Pending requested
-
Diff: 54 lines (+28/-4)3 files modifieddebian/changelog (+11/-0)
debian/python3-rtslib-fb.rtslib-fb-targetctl.service (+16/-0)
debian/rules (+1/-4)
summary: |
- make the init script fail gracefully if unable to load modules + make the service fail gracefully if unable to load modules |
Changed in python-rtslib-fb (Ubuntu): | |
assignee: | Rafael David Tinoco (rafaeldtinoco) → nobody |
no longer affects: | python-rtslib-fb (Ubuntu Groovy) |
description: | updated |
Changed in python-rtslib-fb (Ubuntu Focal): | |
assignee: | Utkarsh Gupta (utkarsh) → nobody |
Changed in rtslib-fb: | |
status: | Unknown → New |
Filed upstream as I'd want their input on how to best solve this. /github. com/open- iscsi/rtslib- fb/issues/ 157
=> https:/
FYI: the debian init script is a copy of the one from upstream (which is always dangerous as they can get out of sync, I much prefer copying them in d/rules to stay with upstream - we might include that when suggesting to Debian)
Subscribing and assigning Rafael who is driving this for HA.