On Thu, Jan 19, 2023, at 11:53 AM, Gordon Messmer wrote: > On 2023-01-19 00:55, Lennart Poettering wrote: >> >> What you could do is split up the problem: have iscsi-starter.service >> or so, that is separate from the iscsi.service main service. The >> former's job would be to scan if iscsi volumes are configured. If it >> finds configured ones, it would then issue "systemctl start --no-block >> iscsi.service" to enqueue a start job for the real thing. > > > Something like that was suggested last year, and Colin Walters objected, > for what that's worth. > > If the PR to allow installing only the "core" storage drivers is > rejected, then I'll work on a PR to implement this change instead. Heh well, I'm obviously going to defer to Lennart if he has an opinion on how you should do something with systemd. It wouldn't even be the first thing calling `systemctl start` in the boot process...sadly there's NetworkManager dispatcher scripts that *also* `try-restart iscsid` =/ That said, I do think a general better pattern is to either: - Have the daemon itself run `systemctl enable` if it detects the scenario; though the problem with this is that if the daemon is removed, the enablement state will "leak", but a workaround for that is to ship a unit in your daemon which is itself conditionally enabled, and *that* unit has Wants/Requires=iscsid.service. So there'd be libvirt-iscsid-requirement.service or so. - Write a "stamp file" to /var/lib/mydaemon, then a generator can key off that. (Instead of e.g. starting up libvirt and parsing its whole database etc.) But this intersects with the /var requirement, unless you move it to /etc. (I had actually forgotten though that it's not guaranteed /var is mounted, I'm pretty sure we have some implicit requirements on that some places) This thread is really similar to https://github.com/containers/podman/pull/17110 _______________________________________________ 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
