(apologies for the long-ish message, but I'd like to save people the
trouble of re-reading a year-old very long email thread)
Early last year there was a thread on this list (Re: "Is
NetworkManager-wait-online.service necessary by default?") in which
maintainers discussed the issue of boot times increasing when libvirt
was installed as a result of iscsi creating a service order dependency
between network-online and remote-fs-pre. If I'm not mistaken, it was
unanimously agreed that it was undesirable for this dependency to exist.
This delay is still the most common cause that I find among people who
complain that it takes a long time to boot Fedora, and unfortunately the
most common advice given to those people is "disable network-online".
It's difficult to explain why this is a Bad Thing (TM).
A number of possible solutions were discussed in that thread.
Unfortunately many of them don't work (or don't work reliably), which I
assume is why the problem is not solved, so I'm hoping to revive
discussion of the ones that will work. The problem occurs because: 1)
libvirt requires libvirt-daemon-driver-storage-iscsi and
iscsi-initiator-utils, 2) iscsi.service is enabled by default (per
https://pagure.io/fesco/issue/2386), 3) iscsi.service is ordered after
network-online and 4) before remote-fs-pre.target.
iscsi.service already has a "ConditionDirectoryNotEmpty", but that's
evaluated when the service would be executed, so the ordering dependency
between network-online and remote-fs-pre exists even though iscsi won't
start. There was some discussion of using ".path" units, but that seems
to have the same problem.
There was also discussion of disabling the service by default and using
a generator to enable the service, and Lennart thought this was the best
solution. I started work to add a simple generator, but the
documentation for systemd.generator states "Non-essential file systems
like /var/ and /home/ are mounted after generators have run," and the
purpose of the generator would be to enable the service when there are
files in /var/lib/iscsi/nodes.
Several people suggested using a weak dependency (Suggests:) on the
iscsi driver, but I don't think that would solve the problem for most
users because weak dependencies are installed by default and nothing
really communicates to users that unless they add an obscure option,
their boot times will increase.
So, things that could work:
The package dependency could be dropped from libvirt entirely. Libvirt
users who want iscsi support can install that storage driver manually.
(addressing condition 1)
A generator would work if the iscsi node configs were in /etc instead of
/var. Would we consider changing the package layout? Possibly, moving
the node configurations to /etc and changing /var/lib/iscsi/nodes to a
symlink, with a pre-install script to handle existing installations?
We'd also need to change the default service state to disabled.
(addressing condition 2)
The ordering dependency on remote-fs-pre.target could be dropped, though
I expect that there will be objections and that option wouldn't be
considered. (addressing condition 4)
FESCo could also revisit 2386 and reconsider whether enabled by default
is the right decision for this service. I assume there was an explicit
decision for this because of the policy that an enabled-by-default
service "must not require manual configuration to function", which iscsi
does. Maybe the fact that it requires manual configuration means that
interested users should also be required to enable the service, given
the pain that the status quo causes for what seems like the far more
common case that this service is installed by all users of libvirt but
not needed by most of them. (also addressing condition 2)
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
