open-iscsi is slowing down the boot process
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
open-iscsi (Ubuntu) |
Opinion
|
Undecided
|
Unassigned |
Bug Description
This is not a bug, but rather an "optimisation" request.
(Probably set this as "enhancement request" + Low)
Apparently, the package is assuming the user will need some iscsi mounts for his session, and is putting dependencies in the systemd services/targets which effects are to delay "graphical.target" to after the point when the network is online.
A great job has been done by Ubuntu so that the O.S. appears to be "snappy" from the boot, and when the session is in "auto-login", it really makes a great difference and a good feeling of the system being very quick.
This assumption of open-iscsi sort of ruins that effort.
As an example, on my PC the graphical target is delayed 10 seconds more (was 22 seconds and is now 32). The impression is not as good and the system feels "slow again" (although it is just a feeling!)
Step to reproduced (you don't even need to have iscsi LUNs to to so, just install the package!)
- Start from a clean 20.04, boot up and issue: systemd-analyze
- Now install open-iscsi, reboot and issue again: systemd-analyze
The result will probably be a big impact on "graphical target", although total time does not change a lot.
My usage is not needing iscsi targets for my session.
I have a NAS with iscsi LUNs, and when I need those mounts, I just start them with a command.
sudo iscsiadm -m node -l
Then Gnome recognises a new disk has been inserted and does an "auto mount".
This command works whether the service was started or not.
This wrong assumption is easily fixed in my case with this command:
sudo systemctl disable iscsid.socket iscsid.service open-iscsi.service
Then, at the next reboot the graphical target is snappy again, and does not have to wait for network-online and remote-fs targets.
I don't know what can be done to cope with both situations : those who need an iscsi target mounted for their session, and those who don't... but I guess the philosophy now should be to assume the user does not need such targets, and don't put dependencies that delay the snappy boot process.
For those who need those mounted remote fs for their session, detailed help on how to enable iscsi services at startup should be provided.
Related branches
- Bryce Harrington (community): Approve
- Canonical Server: Pending requested
- Rafael David Tinoco: Pending requested
-
Diff: 24923 lines (+4835/-457)29 files modifieddebian/changelog (+987/-0)
debian/control (+4/-2)
debian/extra/initramfs.hook (+1/-1)
debian/extra/initramfs.local-bottom (+20/-0)
debian/extra/initramfs.local-top (+30/-2)
debian/extra/net-interface-handler (+80/-0)
debian/iscsi-network-interface.rules (+3/-0)
debian/iscsid.service (+1/-1)
debian/open-iscsi.finalrd (+40/-0)
debian/open-iscsi.postinst (+25/-40)
debian/open-iscsi.service (+6/-6)
debian/patches/lp1755858-default-iscsid_conf-to-iscsid_socket.patch (+30/-0)
debian/patches/series (+1/-0)
debian/rules (+27/-8)
debian/tests/README-boot-test.md (+139/-0)
debian/tests/control (+4/-0)
debian/tests/get-image (+227/-0)
debian/tests/install (+5/-2)
debian/tests/patch-image (+374/-0)
debian/tests/test-open-iscsi.py (+426/-0)
debian/tests/testlib.py (+1153/-0)
debian/tests/testsuite (+7/-0)
debian/tests/tgt-boot-test (+534/-0)
debian/tests/xkvm (+704/-0)
dev/null (+0/-395)
iscsiuio/src/.gitignore (+1/-0)
iscsiuio/src/unix/.gitignore (+1/-0)
test/.gitignore (+3/-0)
test/harness/.gitignore (+2/-0)
Zakhar,
Thanks for taking the time to report this bug and help make Ubuntu better. Perhaps this could be because of other iscsid/open-iscsi service dependencies. Could you provide an example of your systemd-analyze with and without the services, in question, enabled ?
Thank you!
-rafaeldtinoco