[Bug 1882986] Re: open-iscsi is slowing down the boot process

[Zakhar]

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/openvpn-client at .service

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
Foundations Bugs, which is subscribed to open-iscsi in Ubuntu.
https://bugs.launchpad.net/bugs/1882986

Title:
  open-iscsi is slowing down the boot process

Status in open-iscsi package in Ubuntu:
  Invalid

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.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/open-iscsi/+bug/1882986/+subscriptions