Slashdot Mirror
Does launchd Beat cron?
Blamemyparents writes "For those who aren't Appleheads, you may not have heard that with Tiger, Apple swapped out old Unix standby cron for their own creation, launchd (Apple mentions it on their OS X page and has the man page for it up as well). Seems like it's a bit nerdy, but this changes a LOT about how *nix systems have done things for many years. Launchd is Apple's replacement for quite a few utilities, including launching and quitting quite a few different things, and getting info from the system and other running processes. This page from Ars Technica talks a bit more in depth about it. Apple has open sourced the thing, and is apparently hoping all the unix kids will take a look."
Because everything in OS X uses XML configs. A dang site better than Windows Registry or the thousands of permutations that Linux uses.
No, you don't get it. Why in hell would you want to write yet another config file parser and use your own awkward config format when you could use standard XML and that very same parser that's already loaded to system RAM as a shared lib?
I'm not sure Apple Gets It though. Why in the world would they use XML configs?
To make it easy to edit the files both by hand and via utilities which can be written very easily by leveraging existing XML parsing libraries?
Apple is doing a good thing here is shaking up the administrative and setup side of the UNIX world. Most of their work was actually NeXT's, but their "Application as directory" concept is wonderful in a lot of ways, and their reorganizing of the filesystem so that it makes more sense to users is probably a good move in the long run.
What makes UNIX superior for management and power-users is the ability to do everything you need to from command-line tools and options, and the fact that the storage for configuration is in understandable, alterable files. If those are still there...if I can still run my Apple from the shell--I'm a happy man.
The only exception to this would be cases where a vendor deliberately makes a deviation simply to introduce incompatibilities. I don't see that as the case here.
Why in the world would they use XML configs? Gesh.
Well, machine parsable, heaps of validation tools to make sure you haven't shanked it, and user readable text so you can go in there and hack on it if you want.
Given that damn near every scripting tool out there has xml support, it seems like they've kept 90% of the admin-friendliness of unix config files and improved on system parsing by simply hanging off of a well proven structured document format, which standard config files most certainly lack.
You move away from human readability/editability and into the realm where only a machine can fathom the format.
.whateverrc start with a hash mark? A semicolon? A double slash? C-style /* ... */ delimiters? XML-style ? Are you even allowed to have comments? Can you use nested parentheses? Are angle brackets a symbol for redirecting i/o or do they delimit XML tags? Does a pipe chain the output of cone command to the input of another, or is it a logical or operator? Replacing that mess with a single standard format will make things *more* human readable IMHO, and it will certainly make it easier to have a single integrated pointy-clicky interface for changing all those configuration options.
You're looking at this from the perspective of someone who understands and remembers the differences in a dozen config file formats. Most people don't.
Do comments in my
0 1 - just my two bits
For once I agree. XML is _ideal_ for configs. In fact, it is more suited for configs than for many other fields in which it's actively used. The key things are it's flexibility and human-editability.
We do need a replacement for our boot process. Boot GNU/Linux systems is slow. We want processes to be able to start concurrently, or in some cases, with specified pauses. If non-essentials (print server, etc.) start a few seconds after the log-in screen appears, I can be functional faster. We don't have a good system in place now.
We need a replacement. launchd isn't it. The problem, fundamentally, is XML. XML is a problem since, fundamentally, it is very flexible formatting, and so doesn't play nice with shell scripts. You can't easily cut/sed/etc. xml files. Until we get a suite of replacement tools that can easily modify XML files from shell scripts, XML won't cut it.
One of the key things to a good system is to make easy, common things fast and easy. The minimal overhead for any program that modifies an XML file is way, way, way to large to want to use it as the standard system format.
Isn't half the attraction to OS X for geeks how its not that much different from Linux or BSD from the console?
I'm sure some do. But in the aggregate most users will balance something like this against the benefits gained. There are those who are also experimental enough who will try this, and if they find it to be a better implementation will then port it over to other *nix variants, leading to a new "standard".
rc.d, cron, etc. may be the way other unices do things right now, but that in and of itself is not justification enough to be married to such mechanisms in perpetuity. Sometimes it's beneficial to *cough* you know, "think different."
Not only that but looking at the rest of the plist syntax reveals that this thing is waaay cooler than cron. It allows you to set user, group, chroot, check dependencies, designate where to send input and output, set resource limits and whole crapload of other things. Sure you can do this all from within a script, but this thing gives you all that for free.
"Design by committee" is not a way towards excellence. Excellence often comes in small doses and grows from there.
Let me give you an example from my work. I designed an software monitoring system which read values from our Oracle databases, put the values into RRD files and had a flexible configuration that allowed me to quickly create new sites as copies of other sites. Also I added dependencies and suppression, etc. I designed it to _MY_ specs, what _I_ wanted. But I wrote it in a flexible manner. It's now being used by over 200 people and stands a fair chance at company wide adoption. Not because I asked what people wanted, but because I chose a good solution (not the mythical "best" solution) which worked for me (I had a complex use case fortunately), and made it easily extendable. Now people are feeding data into the system from almost everywhere, and the whole system was rearchitected from a cron job to a continiously running set of daemons. Because of the modular nature of my design it allowed for this redesign easily.
So I think what Apple did rules. They didn't ask requirements from anyone, they had a flash of inspiration, created something awesome that works good for them, and then said 'hey, if you want to use this, go ahead!'
Apple never considered asking other Unices because they wanted something that worked, and also wanted to deliver too.
I think, to the contrary, we've greatly simplified Mac OS X. When it comes to programs that run without being explicitly started by the user, there used to be six or eight ways to skin the cat, many of which overlapped to a greater or lesser extent. Now there's one.
Two words:
Parallel Startup
init/inetd/cron are hardly "simple" tools, they have always seemed quite complex. And, since they all do basically the same thing (start programs) there is alot of duplication of effort, and possible security holes in each app.
One of my biggest irritations when I start up linux is how long it takes to do everything. It runs each service, in the order that is specified by the requirements one at a time. There are a lot of things that can be going on at once to get everything started. For example, while I'm waiting for my clock to sync with ntp (ubuntu does it on every boot) I could also be starting the webserver. Or, while I wait for my network card to be configured with DHCP, hotplug could be starting up, or some other service that doesn't need networking.
There is a lot of waiting that happens during the startup process that could be better spent actually starting something up!
Also, with regards to XML, I think it's a great idea. You don't have to worry about the config file being syntactically invalid because it can check it against the DTD.
Don't count your messages before they ACK.
XML is just a file format, and besides, everyone does it now. If we have a way of unifying those 1000 different Unix config and script file formats, then I say go for it, if only because today Unix configuration is a totally non-uniform mess. Why not XML? Even Apache uses it (with some limitations, but it's the thought that counts. well, at least they have angle brackets, that's a start I guess)...
/etc/rc.d (or /etc/init.d on most Linux systems) is a huge mess that's hurting startup time and performance. I think it's time for Unix people to realize that the whole application landscape severely suffers from integration problems. Take Monad for example, this is where Microsoft took the "Unix way" and implemented it for modern computing - think about it, friggin' Microsoft got this, and Unix geeks are still debating whether it's time to replace the ancient startup daemon that their fathers used!
The problem with "how Unix works" is that there are some tasks that cannot be done by one single, simple tool. Some of those tasks cannot be done by combining existing tools either, because program interaction on a Unix system seldomly goes beyond parsing the other app's text output for some keywords and then acting on it - which is cool in some way, but mainly it's all a big ugly hack.
It's reasonable to re-think the way application startup is done, the current
Though coming from a Unix background myself, I can see why Dave Cutler hated it so much, so he basically took his ideas and created NT. Why hasn't Unix been able to catch up in all this time? We could have done it, but ironically it's the community that makes Unix strong and at the same time kills innovation completely.
We're all very impressed if you work for Apple, but the chest-thumping is getting a little tiresome.
Isn't half the attraction to OS X for geeks how its not that much different from Linux or BSD from the console?
For a lot of us, the attraction of OS X is that it is -- finally -- a unix that doesn't suck.
Apple has done an amazing job in a few short years of replacing the stupid, archaic, and ridiculously fragmented parts of unix that have festered on it like a cancer for decades.
There are a lot of geeks who are perfectly capable of using unix (and do so on a daily basis) but f*cking hate it because there are 32 separete launch daemons, 47 different configuration file formats, and 376 different GUI permutations, all of which are mutually incompatible except for the token attempts by folks like the LSB, which everyone ignores.
The truth is that Apple is filling the role now that USC Berkeley filled years ago -- stepping back, evaluating what is there, keeping the good and replacing the bad. Unix had been in dire need of a benevolent dictator for years.
Recursive: Adj. See Recursive.
As far as I know, the parting of the Red Sea -if it happened at all- wasn't related to fileformats in any way :-)
.ini files. First of all, XML allows you to store information in a more structured way: you can store it a tree, whereas a .ini file allows only one level deep "trees". Obviously, and specifically for large projects, having just one nesting level is very limiting in structuring the configuration information. This is likely one of the reasons Microsoft switched to the registry which allows the information to be stored in a treestructure, similar to XML. And projects such as Apache already use a XML-like format because it makes structuring configuration information a lot easier.
.ini files aren't. XML schemas -such as DTDs- describe what an adhering XML file should look like. So, in an XML based configuration file, you could demand that the user provides a username and petname for example, by creating a DTD demanding this information to be available. Furthermore, self-documenting formats are in generally considered files which describe the field that are contained in them. So, as an example, file "a.dat" would not be self-documenting while file "b.dat" would be self documenting:
o me_user=1: favorite_pet=dog
.ini files can't do. .ini files.
.ini-fanboys shouldn't complain to much about their beloved .ini fileformat, as the main/user and designer of that format replaced the format too.
Furthermore, you seem to miss the point about XML. There's huge differences between XML and
Secondly, XML _is_ self-documenting while
a.dat:
123:12:adf:0:1:dog
b.dat:
userid=123:age=12:name=adf:vi_user=0:gn
And yes, self-documenting formats are indeed less compact. But the "bloat" serves a purpose: Understanding the format is easy.
So, XML does indeed solve several things. Yes, files adhering to the XML specification are a lot less compact then a file containing the pure information would be, but the "bloat" is there for a reason. I'm not a XML "fanboy" at all, and I'm certainly critical in regards to the justifyability of using XML for any and all formats, but for config files, I don't see a real problem. There's projects encoding large datafiles intirely in XML, thereby tripling the size of the datafiles... that's indeed something the phrase "unnecessary bloat" could be applied for. But for configfiles... With the average size of a configfile being what... 1K, 2K, 10K? And disks being many gigabytes large...
Lastly, XML files are both readable and editable by humans as it's a true textformat. It's not a binary file which is truly unreadable and uneditable by userfriendly texteditors, nor is it someting like a BASE64 encoded binary file. So, again I can't agree with that point either.
So, to summarize:
1. XML files are easier to store information consistently, as they allow you to put more structure in your stored information by storing it in a tree structure, which
2. XML files are self-documenting, the DTD files describe the contents the XML file should follow, and shows the user which options are available as well.
3. XML files _are_ readable and editable by humans as they are plain textfiles.
4. XML files are "bloated" because they offer _more_ then plain textfiles or minimally structured files such as
So, the
The launchd service isn't a daemon.
Then why give it a confusingly daemonish name by appending a "d" to the end of it?
It's a replacement for init.
Which is a daemon. I can see that a replacement of a daemon might not have to be a daemon, but I'm wondering how that's actually implemented and I'm skeptical of your claim. At the very least you've presented this in a very confusing manner.
If you can't figure out an xml plist config, then you are not smart enough to be in the shell.
I'd rather deal with "hard" stuff like xml tags than "easy" stuff like switching with screen to the man page over and over again...
You scared people clearly don't understand plist files and how they represent records and lists.
plists should be used MORE than just infrequent things like rc/cron... as far as I'm concerned all configs should be plists.
As for xml being slow...a standard parser may beat a custom parser; besides, configs are not read constantly, which is why xml is well suited. (especially for rc/cron...cron: I doubt it parses unchanged files repeatedly)
Democracy Now! - uncensored, anti-establishment news
Which is exactly what Apple - and the average user - wants. Hell, it's also exactly what you want for your X apps, and what you want for those 90% of times when you're configuring non-graphics apps and services through X, a web interface, or even a command-line configuration app.
The only time it falls down is when editing configuration files manually - and even then, it's still parsable by the human brain.
Now, I'm no XML fanboy. But honestly, when was the last time you edited anything more than the most trivial
What part of "a well regulated militia" do you not understand?
1. It's not about figuring it out. Just because you can figure something out doesn't make it optimal or even non-crap.
2. The grandparent post was talking about XML in general and how it's great for configuration data. That is what I was taking issue with. You can build record/list support on top of XML, but it doesn't fit in naturally.
3. I still think the property list XML format is crap. Property lists are decent; they're not perfect, but their extreme simplicity makes them very useful. The ASCII format is great, so why would you want an XML format?
Does having an XML format lets you leverage XML tools? It might have if property list XML worked with XML instead of simply beating it into submission. Apple created a completely opaque layer on top of XML instead of integrating directly.
A natural XML equivalent would be a little more verbose: Using Apple's XML format, you'll get:The result: something that's more verbose and harder to read than even a natural XML format.
What's worse is that you can't leverage DTD/Schema as much as you could with a natural XML format.
The basic point here is that the plist stuff is XML unfriendly.
<dictionary>
<key>item1</key>
<string>somevalue</string>
<key>item2</key>
<string>somevalue2</string>
</dictionary>
is basically useless to any other XML tool. XML format is supposedly for interoperability, so your suggestion to always unserialize into CFDictionary is not really useful.
An alternative could be:
<dictionary>
<item key="item1">
<string>somevalue</string>
</item>
<item key="item2">
<string>somevalue2</string>
</item>
</dictionary>
which would be readily digestible by any other XML parsing tool, XSL, etc.
(the value is the child of the item, rather than being an attribute, as often dictionary values can be other dictionaries, etc)
Damn straight. I love my work as a sysadmin, but I *hate* having to put up with the crap "unix" requires to do a good job. Which is why I don't run it on my desktop.
However, the question is are we losing simplicity for features?
Good question.
Let's look at it. When are programs run? The simplest answer is "when they need to."
No, I'm not being snide, merely rhetorical. When do programs need to run?
Programs need to run for a variety of reasons. Some need to to run when the machine is booted. Others need to run at particular times. Some, like certain network server processes are needed only when a user or another program requests service (e.g. accept connections on protocol/port). Others are spool oriented programs where files in a queue directory need to be processed when present but have no work to do when the queue is empty.
So rc scripts run programs at boot time which either do some work and die or act as standalone servers which are intended to live forever (or until they are explicitly told to stop).
init runs programs (like getty processes) which are long lived and are respawned when they die.
inetd/xinetd listens for connection attempts to network ports and spawns server processes on ports.
cron runs programs based on a schedule, the passage across a point in time triggers execution.
launchd provides a superset of the above triggers for spawning programs.
Think of it as
Run Program [ProgramArgs] [ TemporalTrigger | ServiceRequiredTrigger ]
By default, the simplest launchd file says "Run this program now just once.". It is thus a simple rc script which, at boot time, runs something and at shutdown time can be told to stop. Adding a further key/value pair can say "restart on exit," thus replacing inittab/init based functionality. Specifying a family/protocol/port says listen and start me when needed to serve a network request al a inet. Adding a qualifier to this type of socket definition says connect() to an address, instead of the more typical bind()/listen()/accept(). Specifying time based activation covers cron functionality, if you need at functionality specify the environment variable and working directory as well. To enable spool-like behavior or programs tied to arbitrary file system activity watch a file or directory for changes.
Most Unix subsytems only support system level operation. launchd distinguishes whether a process description is system wide or based on user login simply by where the file is found. A launchd plist file found in a LaunchDaemons directory will be loaded on system startup. One found in a LaunchAgents directory will load when a user logs in, and unload on logout. The syntax of the file will be identical in either case.
So, the launchd plist files (short for property lists) contain a set of key/value pairs describing what to run, and when to run it. Beyond this, launchd defines keys which tailor how the program is run, all of which are optional. These include specifying: user and group by either name or uig/gid; working directory, chroot directory, a dictionary of environment variables, CPU niceness, umask. Do you want to limit how much memory or stack it uses, prevent it from wiring system memory? Do you want limit the number of children it can spawn, or treat its IO requests as low priority as urgent? Keys are available for that.
So is this simpler or more complex? In the big picture I believe that this simplifies things tremendously. Launchd defines a tiny language for specifying how and when to run processes. It covers all the traditional triggers of init, rc files, cron, and inetd. It specifies the environmental and security issues of su/sudo, chroot, ulimit, umask, nice and at. It covers both system level startup/shutdown as well as user level login/logout.
Because of well chosen defaults, most launchd input files will be very short and to the point, only specifying the direct functionality they need. Adding just a few more key/value pairs can obviate the need for the majority of moderately complex rc and daemon startup files. Since launchd also obviates the need to daemonize, close files descriptors, fo
The only concern I have is how bloody ugly/unreadable the config files are. There's so much noise from the tags that one's hard pressed to read the entries. I don't care if there's an editor for it, when I have to do it by hand with a text editor the file format's fluff gets in the way.
That sounds like a complaint made up to have something to complain about.
The idea is that you *don't* edit plists by hand, but if you have to, you can.
So, under all normal circumstances, you do things via preference panes, plist editors, the "defaults" command, etc. But if things are hosed and all you have is a boot floppy or CD with vi on it, you *can* recover the system back to a fully operational state. And more to the point, launchd helps minimize the potential for being in such a hosed state.
All this is academic, of course. The question to ask is how often do people find OS X to be in a hosed state, where the system is unrecoverable without resorting to such extreme measures? And how often does this happen in Linux? The answer for OS X is essentially "never", and under Linux it's "every now and then".
So perhaps your trepidation is because you are used to having to fix a hosed Linux system by hand via a boot floppy?