Here's something I don't understand... Why do so many people hate systemd but not macOS's launchd [0]? Don't they serve similar purposes? I've been digging into macOS for a few months now, and I'm pretty happy with their defaults.
EDIT: I don't know why I'm being downvoted for asking a genuine question. I'm not a linux expert, so I'd love to hear your criticisms.
The use of non-executing service definition files isn't really the problem with systemd - it's one of the parts I actually like.
The problem is more about the project itself. The scope keeps creeping to consume more and more things. The developers have a "we know better, do it this way, your argument is irrelevant" type attitude to outsiders.
Indeed your last argument is my beef with systemd as well. I describe it as:
"Systemd is great! But it's an inconsiderate piece of software!"
Meaning it work nice, it does it's job it does it fast. But if you want to things your way, or want to run something not-systemd standard, you are in for some fun.
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?)
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...
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?
> 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.
>> 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.
In theory, yes. In practice, systemd reinvents half of the rest of the system, poorly. Even to the point of shipping a half assed dns resolver and a dhcp client that doesn't even support lease renewal, and when people file bugs the invariable response is to blame the user.
I don't even understand how someone could ship that DNS resolver, especially as the default install. It's completely broken on my systems, literally crashing on every other lookup. Nobody online seems to have a fix either, I just had to disable the thing and revert back to the old resolver.
I hate systemd because it's horribly, cancerously invasive, often messing with existing functionality that works well and replacing it with worse substitutes / duplicates.
In recent memory, off the top of my head, it messed with NTP, DNS resolution, Syslog, DHCP, Nohup/Tmux, not to speak of taking over udev so it won't run without it (thanks for eudev).
Systemd is effectively Freedesktop/Fedora/Gnome dictating how every last Linux distro is supposed to behave. And doing so by invasive dependency chains.
Observe how LFS now have two parallel books. One continuing the one they have maintained from the start, and another dedicated to systemd. This is a good indicator how invasive systemd is in the basic construct of a Linux distro.
For future reference, you might find it helpful to read "man defaults" and "man PlistBuddy". And its binary is at /usr/libexec/PlistBuddy.
I can't say I blame you, though. Figuring out what all these tools did and what they were for required a fair amount of reading and experimenting on my end.
Binary plists have been around for ages, in fact they come from NeXT. But most stuff on OSX will still happily interpret XML (and now JSON) based plists just fine if need be. For all your conversion needs there's plutil.
As I said: not my area of expertise. Though the docs I was reading were suggesting that the change from file to binary had occurred after OSX was introduced.
I've been happily using macOS server at home for a few months. It's not a production-ready deployment, but I haven't had any complaints.
Aside from that, using it on my personal laptops has worked surprisingly well. Once I familiarized myself with the CLI tools, I haven't had any issues.
For the same reason an airline mechanic doesn't care about the location of the fuel injectors in his car, but cares very much about the location on the engines he works on all day.
I won't claim to speak for everyone here, but there's almost nothing I install third-party that I care about during the startup process (on my laptop). And even if I did, they're generally closed-source apps I can't access the source of anyway. 99% of my day-to-day usage of a laptop is with applications I'm manually starting and stopping.
I care VERY much about services automatically starting properly on a server. 99% of my day-to-day usage of a server is applications that automatically start and stop.
I don't like both. While I can understand the need for complex configuration on macOS: it runs on laptops, my Linux runs strictly on server, reboots once in few weeks or months and I don't care about boot time (my BIOS boots for 5 minutes, I could care less if Linux will boot for 10 or 60 seconds) at all. Good old init with bash scripts worked wonderfully, was transparent, easy to understand, hack and extend. While I can live with systemd, it's a step in wrong direction.
Not nearly enough engineers care about MacOS at the same emotional level as Linux. People who use Mac usually don't care much about internal architecture but their actual experience while Linux users who are also developers are extremely vocal of every single component inside Linux
Or it could be that MacOS doesn't run on servers, where Things Just Have To Work. MacOS has the luxury of always having a ready pair of hands right there to fiddle with things. The people who care about systemd one way or the other are the people who care for servers.
Look upthread at the 'nohup and logout' "bug". That's not something you're going to encounter on MacOS, because it's not something you do on MacOS.
I think it's more that MacOS is run on end user machines where the defaults are just fine. As long as you don't have to fiddle with it launchd generally stays out of the way. If you start trying to get fancy you quickly find yourself in plist hell and brick walls of "Apple doesn't think this is a valid use case, so it is impossible".
Not sure why you think people don't dislike launchd.
The problem with systemd was that there was potential to be better; the idea is good but the core developers reek of hubris.
Launchd is OSX, and osx has some horrors but that's ok because they're desktop systems and you don't work on fleets of thousands of them usually.
There was a time where Apple were threatening to upstream it to FreeBSD- but aside from that I think the consensus is that launchd is quite horrible too. It's just systemd could have been so much better and not tried to gobble up the entire Linux ecosystem.
For me the problem with SystemD is that it seems to be trying to make Linux run like Windows.
If you are running in a generic "This is my machine and I just did the normal install for a regular use case then everything works" it seems great. But the instant you try to do something a little out of the ordinary it becomes a absolute nightmare of opaque message passing interfaces and hours on Google.
A few examples:
1. In the old days you could network boot a machine with a kernel compiled with a couple of flags turned on and an NFS share. SystemD systems can be network booted, but you're going to spend a lot of time poring over obscure forums finding all of the tweaks you need to make, and it will be a lot slower and toss up error messages for things like UUIDs changing on different systems.
2. If you want to have the wireless card change MAC addresses before it connects for slightly improved anonymity at public hotspots, you had better be willing to upgrade to the bleeding edge. NetworkManager broke the existing solutions for doing this and implemented it's own model, but it required a version of wpa_supplicant that was never really released so you had to build it yourself from a snapshot and install it and tell your distro not to update it. The SystemD devs got tired of waiting for the wpa_supplicant devs to release the new version so they moved the functionality into their code. At the same time they pulled in the DNS resolver but broke it so it crashes on literally every other name lookup.
3. NetworkManager pulled in OpenVPN support as an option. It's awesome when it works, but when it dies it refuses to give you any sort of clue as to why the connection didn't work. You just get a generic "it failed" message like in Windows. Not "Authentication Failed", "Cannot connect to Server", or "Clocks unsynchronized", not even a cryptic error code. Every single error results in just a generic message and you have to either hope the logs have something useful or more often you have to fire up Wireshark and inspect the authentication exchange by hand to figure out what is up.
Lord help you if you find yourself with a machine that hangs at boot because some process didn't receive some message it was expecting and now you have to figure out who was supposed to send that message and why they didn't send it. This isn't the old days where you could trace shell scripts to figure out where the problem was, now you have to know the whole thing before you can fix anything.
And don't get me started about moving the syslog into some binary database thing that you can't grep without going through some export process.
Having worked with inits of BSD, sysv, upstart, systemd, and launchd varieties, I strongly prefer the administrative and debug capabilities of the script-oriented ones.
BSD's choice to drop everything into a single rc file is not particularly elegant, but it can be coerced to do what you want. The sysvinit user interface, frankly, isn't bad:
I've been known to copy the files elsewhere to work with them, if necessary. The last time that was necessary was well over a decade ago. As a sysadmin (1 - 15k boxen), broken init scripts simply weren't on my radar. (Neither was boot time, or network management, or device management, or logfile management, or ....)
I'll add that my distro of choice is Debian (or derivatives, which I generally mean here). One thing that I noticed when first switching to Debian, back in the mid 1990s, was that its init scripts were vastly easier to follow than Red Hat's. Debian has a fairly standard structure (/etc/init.d/skeleton is the bare-bones template), and most scripts follow that within some reason. There are a few exceptions -- scripts which initialise things (bootclean, mount, networking) rather than start services, tend not to look like service initialisation scripts, on the inside. On the outside, though, they do.
Further: once configured properly, those scripts don't change. Debian in particular does an extraordinarily good job of extracting out all necessary configuration to an /etc/ configfile (which it then won't touch unless you specifically tell it to).
My experience on MacOS (see elsewhere in this thread) is that stuff which ought be easy isn't. My experience with systemd, to date, hasn't evidenced this, as I am largely using the extant sysvinit scripts. But I've noticed numerous things Wot Used To Work ... do not. And the response from the sysvinit devs, particularly from the top, as well as various sycophants on numerous fora, has been exceedingly disturbing.
Case in point, my single most controversial Reddit comment:
OpenBSD doesn't work like that, either. The OpenBSD people reinvented Mewburn rc just over six years ago. None of FreeBSD, TrueOS/PC-BSD, FreeNAS, OpenBSD, NetBSD, DragonFly BSD have a single rc file containing everything.
With the sole exception of MirOS BSD as far as I am aware, the world has actually let go of that idea.
Maybe you're thinking of /etc/rc.local, which is a script on *BSD where you could just dump random commands, which would then be executed at startup. Last I checked, this mechanism is still supported, but not really the way to do it.
My understanding is that interpersonal drama and similar BS has large role in it. Note how often is the anger targetted at main dude behavior. Also some don't like change, react aggressively to it and systemd is change.
There are also technical reasons, but those tend to attract less of pure anger.
> how often is the anger targetted at main dude behavior
That anger comes from somewhere. We don't just go around picking random people to become angry with. Poettering has a lot of influence in core components of Linux (dbus, pulseaudio, systemd) and he's a bad developer. His designs are horrible, his implementations buggy and shoddy and don't fit into the overall architecture of the rest of the system. So, yeah, there's anger towards him and I think it's more than deserved.
> Also some don't like change, react aggressively
We like change just fine if it brings improvements. If not, we don't like those changes. Again, we don't go around hating on random changes.
>There are also technical reasons, but those tend to attract less of pure anger.
All of the anger is caused by technical reasons. Whether it's shoddy programming or shoddy reasoning about technical issues on the systemd developers part. Almost no-one personally knows Poettering or the systemd developers, yet we still think their software sucks.
> We don't just go around picking random people to become angry with.
There are all kinds of people and plenty in Linux community do pick up on people merely for not be deferential enough to authority. Or for asking question they find stupid (or don't know answer for). You can get flamed quite easily.
Not all, probably not you, but a lot of people there get quite aggressive quite easily.
> We like change just fine if it brings improvements.
I personally know people who get outrages over changes whenever change happen. Maybe not you, but you are not everybody.
> All of the anger is caused by technical reasons.
No, not all of it. A lot of it is cause by arrogance which is not technical reason. You don't need to know someone personally to get that feeling. A certain amount of the anger has faulty reasoning on itself.
EDIT: I don't know why I'm being downvoted for asking a genuine question. I'm not a linux expert, so I'd love to hear your criticisms.
[0] http://www.launchd.info