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 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.
"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.
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've not mucked much with OSX admin, but the times I have, it's been fairly ugly. PLISTs particularly so.
/facepalm
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?
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...
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.
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.
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.
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).
My guess is, it's not as relevant because Mac OS isn't as widely used in servers as Linux.
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.
All you've got to do is tweak the PLIST.
Read the manages. They're out of date.
Looked at the PLIST tools (not my thing). Doesn't seem to be an option.
There used to be, back when PLISTs were actual files you could edit. That's gone away now though, best I can tell.
Got a Linux box up and running, that now accepts remote logs.
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.
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.
It's not on AWS. Your use case is just a hobby or one man shop or just one data point. It doesn't necessarily scale well for other use cases.
I think what other people are pointing out is that companies aren't lining up to use it or replacing it over a linux server or window server.
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.
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.
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.
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.
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:
/etc/init.d/<service> [start|stop|reload|restart]
/bin/sh -x /etc/init.d/<service> [start|stop|reload|restart]
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:
https://www.reddit.com/r/linux/comments/2dvmdn/what_do_you_a...
(No comment on the general tendency of crowdsourced moderation systems to vote for popularity rather than truth.)
... is a description that is out of date by coming up to 2 decades. Mewburn rc came along at the start of the 21st century.
That's ... over a decade out of date.
Re-pitching my comment at that specific configuration: it wasn't elegant, but it could be coerced to do what I wanted.
With the sole exception of MirOS BSD as far as I am aware, the world has actually let go of that idea.
Cheers.
There are also technical reasons, but those tend to attract less of pure anger.
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.
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.