Dear Rafael, I would leave it as it is.
It is not yet clear for me why this is delaying the whole startup, but I agree with you, it is probably not worth investigating more time since the "workaround" is fine and simple. What is clear is that iscsi needs "network-online", as per the directive in the file /lib/systemd/system/iscsid.service which says: After=network.target network-online.target It also says: Before=remote-fs-pre.target because indeed it must be completed before mounting the LUNs' remote filesystem. But you also have the same kind of directive in Openvpn-client: /lib/systemd/system/[email protected] After=network-online.target ... and openvpn by itself does NOT delay the whole startup. But it also does not need to put ordering on remote-fs obviously. So the link I am missing, is what says somewhere that it needs iscsid or the successors like remote-fs, and that results in gdm + plymouth-quit-wait being delay AFTER iscsid and subsequently the whole user session being delayed. As for my configuration, it is much better with my "workaround" anyway. Indeed, I have fixed the "hang up" issue. It was PEBCAK... when I "discovered" the LUN it got 2 addresses, ipv4 and ipv6. $ sudo iscsiadm -m node -l hit both targets, so ipv6 joined, the second target (ipv4) couldn't work because the LUN was already in use. So iscsi was "working as designed". I removed one of the target and now all is fine. I have noticed that even though the service is not started at machine boot, issuing the command "manually" starts the service, as shown looking at the systemd status of the services. So that's a much better configuration for me. Even if it was not delaying the whole process by 10 seconds, it is better NOT to load services you don't systematically need, and load them only "on demand". This interesting discussion made me realise that those 3 bits at startup are needed ONLY if iscsi mounts are necessary at some point in the boot process. Otherwise they just consume time at startup (a lot in my case) and memory and stay idling. So maybe an idea (no sure it can be done) would be to inspect if there are "automatic" nodes (mine is "manual") and start the service only then. But I am not sure systemd supports "variable" After/Before/Want clauses, because that would be determined only once the inspection of nodes is done. What I mean is that if determining there is no "automatic" node is enough, you won't need the clause: After=wetwork- online.target. It could also not be worth the time and investment since my "workaround" is really as simple as 1 command! As a summary, and to be logic: - if people need iscsi at startup, what is done here is what must be done anyway. You have no other solution but to wait for network-online, then the iscsi mounts (clause Before=remote-fs). - if other people like me only need "on demand", they have a "workaround" with my report... and they are welcome to spend more time investigating why this is delaying the startup so badly: I don't have the "systemd skills" myself to spot it! As for my own use, the "workaround" is enough and better, and I will reapply it if iscsi is updated and re-enables the services. Best Regards. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1882986 Title: open-iscsi is slowing down the boot process To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1882986/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
