Remix.run Logo
dontlaugh a day ago

It’s a pity macOS’s launchd couldn’t be adapted to Linux. It was an inspiration for systemd, so we might have had a single modern init for all common unix machines.

freedomben a day ago | parent | next [-]

Yeah, I remember that being discussed pretty heavily in the early days of systemd (especially the socket activation model & parallelization) but (IIRC) there were some concerns about how it would integrate with the rest of the linux world which did things a lot differently than Mac OS, especially in the server space where Linux has to be near-universal with nearly any conceivable application running on top of it. That definitely smells to me like a subjective determination and there were people at the time who disagreed with that analysis, so I'm not presenting it as fact, just my recollection of the winning argument(s) at the time.

Edit: Yes, I looked at the original "Rethinking PID 1" post and that seems to be the case[1]

[1]: https://0pointer.de/blog/projects/systemd.html

egorfine a day ago | parent | prev | next [-]

I am managing a fleet of server-side macs for rendering purposes and launchd is one of the major PITA. It's horrible. A single output saying "I/O error" for any error, including typos in plist files adds to the pain.

wpm a day ago | parent [-]

Don't worry, there's `launchctl error` where you can get oh goddamn it it just prints the same useless fucking error

6SixTy a day ago | parent | prev | next [-]

Kind of the main issue doing that is that Apple developed launchd behind closed doors, releasing periodically to open source. That kind of environment doesn't exactly inspire confidence that launchd on Linux could remain in sync with the main branch for very long nor that Apple will play nice with FOSS devs.

amarshall a day ago | parent | prev [-]

launchd’s ergonomics as a user are quite terrible, though. `start`? No…`kickstart`? No…`enable`? No…`load`? No…`bootstrap`? Maybe. I honestly don’t know. But either way, now is it the file path, the service name, or the fully-qualified name I need…?

wpm a day ago | parent [-]

Launchd 2.0 changed the syntax for the launchctl commands (and made it closed source as it now heavily relies on XPC.Framework). The man page for launchctl lays it all out. Load and unload became "bootstrap" and "bootout". Start became kickstart. As far as I can remember enable/disable are still the verbs, though in order to see the status of jobs' "enablement" you have to use the poorly named "print-disabled". Though the latter only matters for jobs that can actually be disabled, ie, any that have the "Disabled" key set to true in their plist file. By default, jobs in the various LaunchAgents or LaunchDaemons directories are always enabled and always loaded at login or boot respectively.

I literally teach people how to use launchctl every other week. I've found it's unituitive for learners because init systems tend to be unintuitive because there is a lot of hidden action and state going on. It wasn't until I started using it on my own I could develop some instinct for it. Personally, I don't find launchd anything but more ergonomic than systemd. A few man pages and some experimentation and you're at least crawling.

Not to say it couldn't be improved; I'd love to know why a failed bootstrap can't call plutil to at least lint the goddamn plist to notify of basic formatting issues instead of printing the same useless error for everything under the sun. "Error 5: Input/Output error" might as well just be an exit status of 5 for all the help it gives me.