On Fr, 20.01.23 14:04, Colin Walters (walters@xxxxxxxxxx) wrote: > > > 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. Just to say this clearly: I am actually with Colin on this too: needlessly adding in dynamic transactions during boot is not a great approach generally, since it reduces what we can parallelize, and makes behaviour less predictable and efficeint. Thus, people should not use what I proposed as a model for anything. It's a passable solution to an immediate problem, not more. So, what should the actual model to follow be in my opinion? Well, iscsid should just arrive in 2023 and watch rtnetlink on its own, and not rely on any "wait-online" services to delay boot processes. It should start early, not delay anything and make iscsi block devices pop up locally the instant connectivity allows it. And it should watch connectivity on its own, and retry contacting its severs whenever a new local network interface pops up and gets configured. And vice versa: if connectivity is lost (and policy dictates) remove block devices again. Or in other words, its 2022, and hotplug hardware is a thing, since 25 years now. iscsi devices should really feel like any other hotplugged hw, and be robust to network configuration changes. In such a model, iscsid would be a daemon you could start at any time in the boot process, and it would just work and make the devices it is configured for popup the moment that's possible, without any external scheduling and very very robustly. I am aware though that storage folks are not typically on the forefront of how device management is supposed to work these days (we still have some storage stuff pulling in systemd-udev-settle.service, don't we?), so I have no illusion that iscsi maintainers would even accept existance of rtnetlink as a thing. Maybe 25y from now, we'll see movement on that. > 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's much worse actually, and just another artifact of the fact that iscsid is too dumb to just watch the network state on its own, the one major thing it really depends on. Lennart -- Lennart Poettering, Berlin _______________________________________________ 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
