Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
axelkar opened this issue Jun 28, 2024 · 2 comments
Open

Comments

@axelkar
Copy link

axelkar commented Jun 28, 2024

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
Copy link
Author

axelkar commented Jun 28, 2024

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

@KillingSpark
Copy link
Owner

KillingSpark commented Jun 30, 2024

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".

  • When Network-Manager or some equivalent ist running?
  • When we have an IP?
  • When we can reach some other IP endpoint via ping?
  • ....

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants