Yet another win for Systemd.
Not compelling to me. Gonna stick with runit and/or s6 on my Artix Linux systems at home. But you do you Lennart.
You assessment isn’t entirely correct as this is indeed related to systemd. Read the PR https://github.com/systemd/systemd/pull/29748
@TCB13 services aren’t systemd-related just because they are launched by systemd.
From what I see in the repo, this functionality is being built into systemd (in the same vein as something like systemd-resolved), and introduces a new target dedicated for the new feature.
Sure, you could probably rip it out and use it with your own init system, but that seems tedious to now scour the documentation to ensure your init system brings up the ‘dependencies’ launched at the preceeding systemd targets, so the NVMe TCP service can run.
Would be easier to just use another existing implementation IMO, most people running their own init systems probably want more than the bare minimum featureset offered by the services included in systemd’s package
A service by itself shouldn’t be systemd, it should be implemented separately and run under systemd. However, this is using the systemd target subsystem which is a little more specific.
How is it related? Is there something preventing the executable from running without systemd? Just providing a service and target file doesn’t mean anything if it can run without them just fine. If it came with a reference init script instead I don’t think people would be arguing that it’s part of sysvinit and that sysvinit is bloated.
Oh, another arm growing.
“ via NVMe-TCP (in case you wonder what that is: it’s the new hot shit for exposing block devices over the network, kinda like iSCSI…”
So….?
I’m happy that this is coming to linux (I believe Nutanix has a great method to expose storage over IPs), but I would have liked if this was a bit more project/dependence agnostic.
I mean, it specifically is giving support for booting disks over an existing protocol to systemd. That’s pretty well within scope?
Oh, my gripe is not with Poettering creating a systemd service for it (for I cannot dispute that systemd wrappers such as this does make life somewhat easier), but I would have liked perhaps a more distribution agnostic method of running NVMe-TCP in a way that the OS would not have to be booted. I suppose I do understand the community’s support for this: systemd is used by most of the popular distributions, and writing a service in it will enable systemd to maybe interleave this between other processes and perhaps fulfill the goal of producing a block device on an L3 network without booting userland.
As one can probably surmise, I do not have a great understanding of how the process works - will have to figure out how MacOS did it first, and then about how Poettering implemented it. I think I’ll have a better idea of what the solution is geared towards.
Thanks for your comment!
I would have liked perhaps a more distribution agnostic method of running NVMe-TCP in a way that the OS would not have to be booted.
From the pull request:
This all requires that the target mode stuff is included in the initrd of course. And the system will the stay in the initrd forever.
I think that’s as minimal a boot target as you can reasonably get, or in other words you’re as far away from booting the OS as you can get.
So now the question is whether this uses any systemd-specific interfaces beyond the .service and .target files. If not, it should not take much effort to create a wrapper init script for the executable and run it on non systemd distros.
