Hi, On Thu, 2022-02-24 at 07:47 +0100, Zbigniew Jędrzejewski-Szmek wrote: > On Thu, Feb 24, 2022 at 12:17:27AM +0000, Gary Buhrmaster wrote: > > On Wed, Feb 23, 2022 at 11:55 PM Chris Adams <linux@xxxxxxxxxxx> wrote: > > > > > > Once upon a time, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> said: > > > > So this is the culprit. iscsi.service has Before=remote-fs-pre.target, > > > > After=network-online.target, which means that it'll delay the boot. > > > > > > If that's the problem, there's some other issue. On my up-to-date F35 > > > system, iscsi.service also has: > > > > > > ConditionDirectoryNotEmpty=/var/lib/iscsi/nodes > > > > > > And on my systems, that directory is empty, so iscsi.service shouldn't > > > be holding up anything. > > Conditions are evaluated when the service would be exectued, so a unit > which is (eventually) skipped because of Conditions still has effect on > the boot ordering and may add additional jobs to the transaction. We want to wait for network-online.target only if the service is actually started. One way to achieve this might be to move waiting into ExecStartPre=. I imagine this could work by creating a new unit network-online-waitonly.target with After=network-online.target StopWhenUnneeded=yes which is then used inside iscsi.service ExecStartPre=/usr/bin/systemctl start network-online-waitonly.target Not great, but should work. I suppose the ideal solution would be that the iscsi service handles waiting internally and only becomes ready when the configured nodes are available or a timeout happens. Benjamin > systemd.unit(5) says: > > The conditions and asserts are checked at the time the queued > start job is to be executed. The ordering dependencies are > still respected, so other units are still pulled in and ordered > as if this unit was successfully activated, and the conditions > and asserts are executed the precise moment the unit would > normally start and thus can validate system state after the > units ordered before completed initialization. > > > How can one be sure that (in the general case) that one of the units > > that you are running After will not create the files/directories > > that will impact the test Condition(s)? > > We aren't. In fact the conditions are checked later as described above. > > > Those tests occur before the unit is actually started, but not > > before the ordering is performed. > > Yes. > > Zbyszek > _______________________________________________ > 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 on the list, report it: https://pagure.io/fedora-infrastructure
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
