KillingSpark / rustysd

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

macos support (osx) #27

Closed zboldyga closed 4 years ago

zboldyga commented 4 years ago

My dev environment is macos, so expanding to add macos support it seems like a solid starting point. I tinkered a bit today and didn't resolve yet, but it may be an easy transition. Will post here with results/findings.

Also, it might be good to decide exactly which platforms are being supported in the current version. We can include these in CI tests and executable builds, and strictly-enforce them with the #[cfg]s. I'm not sure if targeting all of linux would work, there might be subtleties in the support of the nix crate, or variations in some of the supported tooling. So maybe we try:

I would probably save windows support for last, mainly because I haven't used it in a long time, and I'm not sure if there's a way to spin-up containers with Windows without paying a license fee - will check that later.

zboldyga commented 4 years ago

@KillingSpark Just wanted to chime back in - after grappling with osx support for a few hours, I'm thinking it might be better to defer this feature until a later release. Reasons:

  1. Apple has deviated from the posix API that is effectively used in linux (nix::unistd) in many ways. Commands like setresuid have an apple equivalent (setuid), but the behavior is slightly different. 'setgroups' isn't available and instead opendirectoryd should be used. And ~a dozen more cases like this.

  2. I don't have experience with apple's opendirectoryd or launchctl. If someone with experience in those areas contributes, it might be a little quicker for them to add osx support.

Will shift my focus to general test cases & code cleanup for now :)

KillingSpark commented 4 years ago

Ok :) That's very good to know! Thanks for looking into that.

With windows it is probably a similar story.

I guess going for linux + *BSDs seems as the most achievable. But we should keep in mind to not let this assumption bleed into the codebase. Rustysd should stay as generic as possible outside of the src/platform