search

KillingSpark / rustysd

A service manager that is able to run "traditional" systemd services, written in rust
MIT License
495 stars 15 forks source link

System to use "export service names" for e.g. separate mount management #50

Open axelkar opened 2 days ago

axelkar commented 2 days ago

In systemd, I like how I can make services dependent on mounts and networking.

With rustysd, I don't want a bloated PID1 so could there be a generic system to "export service names" so separate daemons can implement the networking, device and mount management for example? Without using rsdctl start network-online.target?

axelkar commented 2 days ago

Also is there some kind of worklist? I can try to implement some features in rustysd since I love the idea.

KillingSpark commented 23 hours ago

Hi! Depending on network and mounts is a pretty cool feature systemd has. The network thing has been a bane of linux init systems since for ever, and the systemd way isn't perfect by any means. Part of this is that it's hard to define when networking is "up".

I think leaving the definition of what "networking is up" means to the user of rustysd is the way to go here and the definition of a target depending on services (maybe some oneshot services checking reachability) is the way to do that.

The mounts are way more clean cut in this regard and that's why systemd has a special kind of unit for these. On the other hand the mechanisms to (efficiently) check for a mount are very much platform specific.

There isn't really a worklist, but I like the idea of experimenting with the mount units. It's fine if this starts out as a feature gated for linux users.

I'm not sure I agree that this should be moved to a separate daemon though. You get into weird territory like how systemd depends on a functioning dbus server running to work properly. I think PID1 should always be working even if no other process is currently running on the machine. In this case "just" mounts wouldn't work correctly if the daemon fails for some reason, which could be seen as acceptable, but I think just out of principle this should stay in process.