On Thu, 2022-02-24 at 10:14 -0500, Colin Walters wrote: > > On Thu, Feb 24, 2022, at 6:17 AM, Benjamin Berg wrote: > > > 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 > > No, avoid such things unless absolutely necessary - it makes the > dependency graph dynamic, which systemd does support but doing so > brings a vast amount of complexity. Yeah, we need something dynamic depending on whether a directory is non-empty. I must have been blind before, because thinking about it now, this is exactly what .path units are for. All we should need is iscsi.path watching for the directory to be non-empty and moving the install section into the path unit. With that, we should get exactly what we want at boot time. The only side effect I see is that it will also trigger the service when the first node is created. But that may fine, as it just triggers an automatic login. > I think instead you can use e.g. a systemd generator: > https://www.freedesktop.org/software/systemd/man/systemd.generator.html > The generator (which can be the same binary) can then enable > iscsi.service only if the directory is non-empty. True, that is also a possible solution here. Maybe a bit better, though it does move the logic to be outside of the systemd units, making it a bit harder to see. > (Which is making things dynamic, but all dynamic computation happens > at a well-defined eraly fixed point and is acted on together > thereafter) > > Now I'd agree this behavior is not obvious, and perhaps systemd > should gain something like > EnableConditionDirectoryNotEmpty= that is defined to be evaluated at > the same time as generators or so, and if the conditions evaluate to > false then none of the unit dependencies will be pulled in either. Yeah, that sounds like an elegant solution to have a generic generator to do the above. Benjamin > > _______________________________________________ > 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
