Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've worked with launchd, and I hate it more than systemd. Most of it is because of launchd's atrocious doc. Note that launchd was rewritten a few versions ago for Reasons [1]. I couldn't find any release notes that highlighted this, and you wouldn't know it from launchd's version number...

Thing is, launchd's developers made a good effort at preserving backwards compatibility, but it's far from perfect. And most online docs (such as launchd.info that you're linking to) is subtly out-of-date. For example, I see no mention of "service-targets": new launchd learned about "bootstrap domains" (huh?), which are namespaces implemented at the Mach (macOS kernel) level. It's not a Unixy thing. Trick question: how do you define a user job that runs in the background even when the user's not logged in? How do you define a user job that runs if the user logged in via SSH (ie not GUI)?

It's late and I'm tired, I can try being more coherent tomorrow. There are some good sources of information hidden out there, but the first few Google responses are woefully obsolete. And fuck Apple's own docs.

[1] I'm not sure what the reasons are, but I suspect for a) merging iOS and macOS functionality and b) tightly integrating it with the kernel's XPC interprocess comms infrastructure (again, for iOS?)



I'm glad to see I'm not the only one to have this experience.

I've not mucked much with OSX admin, but the times I have, it's been fairly ugly. PLISTs particularly so.


Oh god, XML config files where order matters >_< "oh but plutil can convert them to json!" Oh but it does so in-place, so I hope you copied the file before converting it, because launchd certainly can't read JSON plists...

/facepalm


> Most of it is because of launchd's atrocious doc.

Really? I read up on launchd a year or so ago to setup backups and I though the documentation was amazing...Which docs are you referring to?


The manpages for launchctl(1), launchd.plist(5), launchd(8), and Apple's online "Daemons and Services Programming Guide" (which has not been consistently updated for the new launchd)

For example, in the launchctl(1) manpage, can you elucidate what they mean for the "bootstrap" subcommand? (caveat: you're not allowed to use "bootstrap" in your definition. That's tautological).

What does "kickstart" mean? (again, tautological definition)

What's the significance of the various "domains"? What's user vs login vs gui domains? What's an "audit" session ID?

How do you reload a service's plist file?

Trick question: how do you kill your GUI by mistyping a common launchctl command? (I don't remember the command offhand, and am unwilling to experiment right now)

What does the LimitLoadToSessionType plist property do? What are the possible values?

etc...


> do you define a user job that runs in the background even when the user's not logged in?

Well, you can't. Only administrators get to define things that run when the user isn't logged in. That's an intentional decision.

> How do you define a user job that runs if the user logged in via SSH

Offhand, I don't think you can do that either, though I haven't researched this particular angle. And it would be surprising to me that SSH'ing into a machine would trigger daemons anyway.


> And it would be surprising to me that SSH'ing into a machine would trigger daemons anyway.

You might want to find out about systemd, then, which does exactly this. (-:

A PAM hook indirectly causes a per-user systemd instance to be created at login and terminated at logout, which triggers all of the per-user daemons that the account has.

If one has a user that is used for lots of little SSH sessions, hundreds of thousands of times a day, the overhead of starting up and tearing down the per-user systemd for each one, not least in terms of the log noise, becomes a serious consideration, and one has to learn the systemd mechanisms for making the user a "lingering" one.


For an OS that is frequently used headless, starting up per-user daemons on SSH makes some amount of sense. macOS is designed to be primarily GUI-driven, rather than primarily used headless, so it makes more sense for macOS to avoid the issue that you describe by not supporting launching per-user daemons on SSH.


I was assuming administrative control of course. How, as the administrator, do you define such user jobs? It's not a permissions issue, its a launchd job configuration issue.


As an administrator, you can place jobs into /Library/LaunchDaemons to run always, or /Library/LaunchAgents to run per-user when a user is logged in.


>> I've worked with launchd, and I hate it more than systemd. Most of it is because of launchd's atrocious doc.

I had to do some provisioning work with NFS and pf and the docs were maddening. I never actually got VirtualBox and NFS to play nicely but once I got a couple little quirks of pf it was pretty reliable.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: