Add different init systems service files for Nix

[unrooted]

I'm not a huge expert on OpenRC, however, this service, more or less, works.
Encountered only one issue with it - it shows accepted connection from pid [number], user [username] when doing anything nix-related, such as nix-shells, unless the current shell instance is not restarted. After that, it never shows up any more. I have no idea how to fix that, but I think it's just a cosmetic issue.

I have no idea whether my approach to add a service like this is okay, so correct me if I'm wrong - I've just followed the naming scheme according to other thing which can be found in misc and it's subfolders for init systems.

[unrooted]

Further, going down the rabbit hole, added service file for dinit as well. Worked on my Artix VM, however, as with OpenRC case, would be better if someone who specializes in that init system takes a look at it.

[cole-h]

Is there a reason for the weird spacing? Does dinit require this? (6 spaces followed by 2 tabs here, and 6 spaces followed by 1 tab for the logfile)

[unrooted]

I've just noticed that. To be honest - I've just followed how some built-in service files on Artix look like. I've wanted to keep it the same way, so the = is in the same place. (ntpd and cronie service files, for example). I can fix it with next commit.

Thanks for noticing. Besides from that, is there anything else? I'll for sure add more service files soon, however, my question is, should I declare some other things somewhere else to make it work with Nix? If so, where? Is the directory where the files are even OK?

[roberth]

It would be helpful to have very basic support for this in our configuration system, "NixOS", so this will be easier to write tests for.
My experimentation in NixOS/nixpkgs#148456 shows that it is quite feasible to leverage existing modules for the initless systems that are docker-style containers.
An OpenRC module could be built on top of such individual modules as well.

I guess there's also a shorter path to automated testing for these, but that won't be quite as useful, fwiw.

[roberth]

It would be good to have some tests for this. I've been doing work on modularizing the test framework, NixOS/nixpkgs#176557, though a bit more refactoring will be necessary to remove the NixOS (and implied systemd) bits.

[unrooted]

@roberth yeah tests would for sure make everything way easier, however, do we really need those...? It's not like we have 420 different init systems and many changes within the service files structure over time.

Your idea is nice, I must agree. I think we can try to implement something like that limited to Nix only, would be easier than pulling out systemd-relient components... Also, another possibility of tests is just setting up VMs and testing those things out manually, it shouldn't take long, I know this may seem like a big-no-no, but I guess it can be just easier than trying to either refactor your work or trying to do the same approach (as yours) for Nix only.

To be honest, I'm just worried that there's a long way ahead of us to fully make our dreams of init-agnostic (more or less, basically thanks to built-in init service files, so I dunno if calling it truly init-agnostic is proper, it's only thanks to adding 'translations' of systemd service files to different init systems) Nix possible

[roberth]

I don't think my idea has to be a blocker.

pulling out systemd-relient components

I was thinking we could pull out most of NixOS actually, by replacing nodes.nix. network.nix could be disabled and the remaining options that are set and/or used by the other modules should be a manageable set. Should; it still would have to be done.

I'm just worried that there's a long way ahead of us to fully make our dreams of init-agnostic [...] Nix possible

No need to worry. It is a long way, but you have to start somewhere.
You could build a prototype that reinvents all config management without NixOS and probably get something going fairly quickly that way, but that will be hard to sustain. It's not so much about implementation, but about managing interfaces that have a tendency to get duplicated, to the detriment of interface consumers.

If on the other hand you integrate with NixOS, for example by first integrating with its test driver, you have a better chance of sticking to the same interfaces where possible.

Anyway, it's just a thought.

[unrooted]

No, no, not a blocker, your idea is quite a cool one.

This PR only translates Nix daemon services and that's all, so I'm kinda scratching my head right now whether we need everything you've mentioned. Well, I think that at the start, implementations at Nix-level can be our way to go for the starters. What do you think? IMO it's one of the best ways, and then, gradually, take steps further into integrating other init systems into Nix ecosystem. If that's the case, then I guess it takes nothing more than just pure testing, even by hand in VMs with different init systems. It's not a huge deal, I always keep all init versions of Artix on my drive.

I don't quite understand the part where you mention NixOS-related modules and config management...? Correct me ASAP if I misunderstood certain things, however, I don't think it's doable to make a fully init-agnostic implementation of NixOS at this point, we're too late, I guess, it's grown too big (ironic how being so great just blocks certain things because they would require an enormous amount of time to work on those). AFAIK, NixOS heavily relies on systemd from top to bottom and most of it can't really work without it, to the point that this would be basically an absolute rewrite for each different init system, though correct me if I'm in wrong here. The idea of modularity yes seems cool, but this will be a module after module and so on and so on.

What exactly do you mean by reinventing config management without NixOS? I mean, it's not fully this, but home-manager somehow and somewhat partially resolves this issue, at least in case of $HOME kind of configs and stuff like that and not an init management kind of stuff. So I guess the second one is what you're saying to try? Just please confirm whether I understand the idea correctly.

Maybe I've misunderstood you, if so, sorry about that. If you have a bit of time, we can brainstorm a little if we set up a quick call, or something, just to makes things fully clear to me.

TL;DR let's brainstorm during a call or something because I'm not good at English and I don't want to misunderstand you since your ideas are cool

[fufexan]

LGTM.

[Et7f3]

Just suggested minor changes because I don't know about openRc

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/2023-07-24-nix-team-meeting-minutes-75/31112/1

[thufschmitt]

Discussed during the Nix team meeting. We can't really commit to maintain these as we have neither the knowledge nor the test infrastructure for it. Having them explicitly as 3d-party under contrib would be fine though

[sweiglbosker]

the void package has some changes that might be worth worth squeezing into this pr, if it is still being considered (im assuming combining stderr and stdout is not a void specific hack, might be worth investigating other packages).
The prlimit thing is akin to nixos systemd.services.nix-daemon.serviceConfig.LimitNOFILE

[roberth]

Would you like to co-maintain one or more of these files?

If we don't have automated tests, we'll have to rely on more maintainers, that's kind of the choice here.

[sweiglbosker]

yes, I am willing to maintain the runit service

[unrooted]

hi, quite a while, great to see another person interested in this topic

I can maintain OpenRC service, as I have seperate machine running Artix with OpenRC as init, and I don't need that machine anymore, so can be used as a test bench and can go ka-boom etc.

However, the question remains - whether my proposal on file placements is okay-ish and/or if any additional work needs to be done somewhere else.
I suspect, that one of the things that'd be considered a to-do, would be automation of detecting what's the init system, and then place appropriate services based on that info.

[sweiglbosker]

Detection is super simple, I can get that done quickly. As for the file approach, I see nothing wrong with it. I thing the main design consideration to make is how the services will be installed, i.e do we follow the current model of systemd and darwin and provide separate scripts for each init service.