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.
@winterayars systems targets were formerly known as runlevels, and this particular one probably could also work with init= because what else could you possibly run at the same time?
“You might be able to get away without systemd” does not mean there’s no benefit to using it. There could be a management benefit (easily putting the system in different states) and/or it may be (considerably) easier to do it with systemd baking it.
If you had to (hypothetically) reimplement most of systemd’s core functionally to do it without and can do it trivially with then that sounds like you don’t like “the project named systemd”, an opinion that should not have an impact on the technical decisions.
(Edit)
Actually i didn’t throw in any specific reasons that respond to the question itself. Let me do that.
This feature is leaning on connecting the storage through networking, which makes sense. (Ideally you would do it like macOS and only let direct computer-to-computer connection run it for security reasons, at least by default.) That means you need a DHCP stack spun up, which systemd gives the project an easy way to do. In addition, any other features can also lean on other pieces of the OS through systemd. It’s just easier.
Lennart Poettering, being a lead on the systemd project, is targeting systems where systemd is the init system. That is, it’s the first actual OS process started. With this in mind, if you wanted to start this “storage target mode” before systemd you would have to implement a bunch of stuff, ex a custom DHCP configuration to get networking going. Then, of course, you have the systemd “OS level” networking and then, separately, the “storage target mode” networking–which may mean you have to then implement UI to connect the device to the network if you have a special network configuration.
If you wanted to set this up after the init system then… uh… well, that’s the implementation as it currently is being developed. It’s a systemd target because systemd is the init system in question. That’s what Poettering is doing, here.
There are probably more reasons why it makes sense to use systemd, but fundamentally systemd is the init system and it can solve problems for the project.
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
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.
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.
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.
Exactly my point. Thanks.
@winterayars systems targets were formerly known as runlevels, and this particular one probably could also work with init= because what else could you possibly run at the same time?
You might be able to get away with just using init=
@winterayars then why the fuck is systemd involved?
“You might be able to get away without systemd” does not mean there’s no benefit to using it. There could be a management benefit (easily putting the system in different states) and/or it may be (considerably) easier to do it with systemd baking it.
If you had to (hypothetically) reimplement most of systemd’s core functionally to do it without and can do it trivially with then that sounds like you don’t like “the project named systemd”, an opinion that should not have an impact on the technical decisions.
(Edit)
Actually i didn’t throw in any specific reasons that respond to the question itself. Let me do that.
This feature is leaning on connecting the storage through networking, which makes sense. (Ideally you would do it like macOS and only let direct computer-to-computer connection run it for security reasons, at least by default.) That means you need a DHCP stack spun up, which systemd gives the project an easy way to do. In addition, any other features can also lean on other pieces of the OS through systemd. It’s just easier.
Lennart Poettering, being a lead on the systemd project, is targeting systems where systemd is the init system. That is, it’s the first actual OS process started. With this in mind, if you wanted to start this “storage target mode” before systemd you would have to implement a bunch of stuff, ex a custom DHCP configuration to get networking going. Then, of course, you have the systemd “OS level” networking and then, separately, the “storage target mode” networking–which may mean you have to then implement UI to connect the device to the network if you have a special network configuration.
If you wanted to set this up after the init system then… uh… well, that’s the implementation as it currently is being developed. It’s a systemd target because systemd is the init system in question. That’s what Poettering is doing, here.
There are probably more reasons why it makes sense to use systemd, but fundamentally systemd is the init system and it can solve problems for the project.
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
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.