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."

Submitter is confused

[NewWazoo]

Based on what I've read about it, it's more a replacement for xinetd and the sysv init scripts than cron.

B

From the apple page:

[ravenspear]

Launchd provides faster startup through a unified framework for starting, stopping and managing daemons, and incorporates inetd, init, mach_init, System Starter and related services.

Re:From the apple page:

[netsrek]

So nothing like cron what-so-ever. Another great piece of Timothy's fact checking.

Before you jump the gun:

netstrek@computer: ~ $ cat /etc/crontab
# The periodic and atrun jobs have moved to launchd jobs
# See /System/Library/LaunchDaemons
#
# minute hour mday month wday who command

So yes, it is a cron replacement.

Re:From the apple page:

[De Lemming]

Parent did not state it was no replacement for cron, but it is "nothing like cron what-so-ever." It's actually a replacement for "init, rc, the init.d and rc.d scripts, SystemStarter, inetd and xinetd, atd, crond, and watchdog" (copy/paste from another post, this is all explained thoroughly in the Ars Technica article).

Re:From the apple page:

[Storlek]

It works the same way a limousine is nothing like a tricycle.

Re:From the apple page:

[Captain Irreverence]

So yes, it is a cron replacement.

On a related note, does anyone else think the phrase "cron job" sounds vaguely obscene? I can think of many a time I was doing a little system administration while purring "Come on, baby. Give me a cron job. You know you want to..."

Re:

[account_deleted]

Comment removed based on user account deletion

Re:Submitter is confused

[As Seen On TV]

The launchd service replaces (takes a deep breath) init, rc, the init.d and rc.d scripts, SystemStarter, inetd and xinetd, atd, crond, and watchdog.

Basically any task the needs to run on its own, rather than being manually started by a human being, can be handled by launchd.

Re:Submitter is confused

[As Seen On TV]

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.

Re:Submitter is confused

[JQuick]

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

Re:Submitter is confused

[MalachiConstant]

You know, I've read many of your posts and even if you are an actual employee of Apple you say "we" way too often. Unless you're Steve Jobs I find it hard to believe you're personally involved in all the projects you've insinuated yourself into.

We're all very impressed if you work for Apple, but the chest-thumping is getting a little tiresome.

Re:Submitter is confused - Mod parent offtopic.

[As Seen On TV]

We did open-source launchd. It's part of Darwin 8.

Re:As Seen On TV obviously needs attention ("we"??

[jkh]

Well, since you mention it.. If you're reading this, ASOTV, please drop me an email. Nobody's going to eat you, but we'd like to have a discrete word... Thanks.

Re:Submitter is confused

[revscat]

Maybe he does work with that team. If he works for Apple, the pronoun "we" is entirely correct.

There is no way to tell for sure, if course, but he seems as knowledgeable about this things as anyone around here. Yes, impostors happen. I just think we'd be better served arguing on what he says rather than on how he phrases it. Making an issue out of his usage of "we" seems a bit pedantic to me.

Re:Submitter is confused

[As Seen On TV]

The "get toasted" expression wasn't my choice of words. I was quoting. I would have said, instead, "what happens if, say, you fat-finger inittab while editing it."

The problem with traditional Unix configuration files is that they're not self-validating. A single typographical error can very easily result in an unbootable system. XML-based property lists reduce that possibility. They don't eliminate it entirely, of course; nothing could. But they reduce it.

They also open up the door for us to make the launch system self-repairing. Check out the changes to NSUserDefaults in Tiger to see what I mean there.

Re:Submitter is confused

[atverd]

The self validation looks ok for a side effect of XML, nothing more.

Boot time would be a big plus, but my TiBook G4 1Ghz/1GB still takes about 25 sec out of my life between gray screen and login prompt :)

The Property List Editor - you guys should be ashamed of this product, according to About window it wasn't touched since 2002, it's primitive, inconvenient and doesn't really help at all.

On other side - I love the idea to replace whole bunch of daemons, scripts and configs with one process and single fo

Re:Submitter is confused

[As Seen On TV]

The reason systems DON'T boot when /etc/intttab get's toasted is they SHOULDN'T boot with out the service it kicks off running.

That's a pretty radical retrograde interpretation of the facts. The reason system don't boot when inittab has an error in it is because init lacks any mechanism for recovering from config-file errors. We fixed that.

When inittab is toasted on one of my AIX servers, I simply boot off of the install CD or a backup tape(yes I can do that). I mount rootvg in maintenance mode, FIX inittab and then reboot. That simple.

So what you're saying here is that you don't like Apple because we're making your job obsolete? ;-)

Re:Submitter is confused

[A beautiful mind]

And you know, this blew it.

At first i thought, "cool, they replaced init and rc.d with something cleaner, yay, finally", but then i read this thread.

Those small programs are NOT doing the same thing, there is at least 3 categories and i don't like lumping them together:

• init, rc.d: system startup, levels
• inetd, xinetd: it(they) starts programs that provide Internet services, when a connection is initialized on a specific port over the network
• atd,crond: They execute commands/scripts at a scheduled give

Re:Submitter is confused

[As Seen On TV]

If I remember right, the cron daemon is included, but it doesn't run by default. I guess you could take the time to configure it, but you'd be way better off just firing off your tasks as LaunchDaemons instead.

Submitter is NOT confused

[jamezilla]

From the launchd.plist man page [apple.com]:

A daemon or agent launched by launchd SHOULD:
oo Launch on demand given criteria specified in the XML property list.

What does cron do? Launch programs! Clearly this means that launchd can be used to replace cron.

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.

Flexibility

[Anonymous Coward]

But can it be piped?

Not a cron replacement, a init replacement

[Anthony Liguori]

Simply referring to launchd as a cron replacement is a major understatement. launchd runs as the init process and according to TFA was primarily made to replace the /etc/rc.d scripts during startup.

This is somewhat understandable for something like OS X. Doing something simple like displaying a GUI detailing startup is terribly difficult with /etc/rc.d scripts (considering the length of pause an fsck would take--users would certainly assume there system hung during boot).

I'm not sure launchd is something you'd want in 99% of Linux installs but if you're looking for a end-to-end user-oriented desktop I can see how a technology like this is necessary.

I'm not sure Apple Gets It though. Why in the world would they use XML configs? Gesh.

Re:Not a cron replacement, a init replacement

[akac]

Because everything in OS X uses XML configs. A dang site better than Windows Registry or the thousands of permutations that Linux uses.

Re:Not a cron replacement, a init replacement

[GamblerZG]

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.

Re:Not a cron replacement, a init replacement

[evvk]

XML sucks for anything that humans might want to edit: configuration files and documents. It's only barely usable for protocol that, and for that it is rather bloated too. Configuration files should use a simple human-readable format. The .ini format, for example, is rather robust. Of couse, programs that support scripting probably should use the scripting language for configuration so there wont' be a zillion different ways to do things.

Re:Not a cron replacement, a init replacement

[Kent Recal]

I agree with parent.
I've had the misfortune to fiddle with XML config files (tomcat comes to mind). Give me a sane key=value scheme anyday.

Re:Not a cron replacement, a init replacement

[NoMaster]

XML sucks for anything that humans might want to edit

However, it's pretty damned good for the times where you want a machine to parse your config files and present them in a nice GUI format.

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 .ini or .cfg file by hand? Your MTA? Apache? Samba? BIND? Crontab? Inetd? Initd? IPFW/PF? If you're like me, you did it by hand-editing the first few times so you knew what was going on; since then you've used Webmin or Gnome/KDE's control-panel-like apps.

Re:Not a cron replacement, a init replacement

[cakoose]

XML is total crap for config files. At least its complexity is somewhat warranted when dealing with document-type data (like HTML or DocBook).

The problem is that XML's data model is fundamentally broken. Most programming language data structures use records, variants, and lists to organize data and this has worked well for years. XML gives you attributes (which cannot contain nested elements), and sub-elements that are matched accoriding to a regular expression. Stupid, stupid, stupid.

Re:XML plist configs are easy

[bussdriver]

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 par

Re:XML plist configs are easy

[cakoose]

If you can't figure out an xml plist config, then you are not smart enough to be in the shell.

1. It's not about figuring it out. Just because you can figure something out doesn't make it optimal or even non-crap.

You scared people clearly don't understand plist files and how they represent records and lists.

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.

{
Dogs = (
. {
. . Name = "Scooby Doo"
. . Age = 43
. . Colors = (Brown, Black)
. }
)
}

A natural XML equivalent would be a little more verbose:

<Config>
<Dogs>
. <Dog>
. . <Name>Scooby Doo</Name>
. . <Age>43</Age>
. . <Colors>
. . . <Color>Black</Color>
. . . <Color>Brown</Color>
. . </Colors>
. </Dog>
</Dogs>
</Config>

Using Apple's XML format, you'll get:

<dict>
<key>Dogs</key>
<array>
. <dict>
. . <key>Name</key>
. . <string>Scooby Doo</string>
. . <key>Age</key>
. . <integer>43</integer>
. . <key>Colors</key>
. . <array>
. . . <string>Brown</string>
. . . <string>Black</string>
. . </array>
. </dict>
</array>
</dict>

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.

• You can't validate semantic structure. (You can ensure that the file is a valid property list XML file, but you can't make sure that it contains launchd configuration info).
• DTD/Schema sensitive editors still wont help you out with semantic structure. It can auto-complete "key", "dict", etc. but it can't auto complete "Name", "Age", or "Color".

Re:Ahh yes.

[cortana]

More like, "it's a single, consistent format and therefore inherently better than anything else".

Re:Ahh yes.

[KiloByte]

In my opinion, XML is:

• really wasteful
• it takes a long time to parse
• inconsistent (like, the sometimes-freeform-sometimes-not issue)
• quite human-unreadable

Sure, it's better than .ini, but is it the best thing since sliced campers? No way.

Re:Ahh yes.

[KiloByte]

.ini has the serious disadvantage of not allowing for more than two levels of properties.

But don't worry. I've once used a mmapped structure to make sure the config gets preserved over crashed -- but fortunately, someone beat me back into the senses. Try to exceed _this_ level of brain-damage :p

Re:Ahh yes.

[Cid Highwind]

You move away from human readability/editability and into the realm where only a machine can fathom the format.

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 .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.

Re:Ahh yes.

[Just Some Guy]

You move away from human readability/editability and into the realm where only a machine can fathom the format.

You misspelled "also" as "only". Having a featureful editor than groks every single config file on my system, supports context-sensitive help for each possible option, and shows me what values are legal for all of them sounds like a Good Thing. Wouldn't you like an "etc-mode" for Emacs, or GEtcEditor, or KonfigEditor, or similar?

This should also be eagerly awaited by network administrators w

Re:Ahh yes.

[takis]

As far as I know, the parting of the Red Sea -if it happened at all- wasn't related to fileformats in any way :-)

Furthermore, you seem to miss the point about XML. There's huge differences between XML and .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 informati

Re:Not a cron replacement, a init replacement

[Anonymous Coward]

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?

Re:Not a cron replacement, a init replacement

[synx]

"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.

Re:Not a cron replacement, a init replacement

[Dulimano]

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!'

They did something similar with an even more important technology: file type metadata. Read the very good overview in the referenced Ars Technica article:

http://arstechnica.com/reviews/os/macosx-10.4.ars/ 11 [arstechnica.com]

Re:Not a cron replacement, a init replacement

[justins]

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!'

It should be noted that Sun's new startup system in Solaris was created via a considerably less inspired process. Divine grace was not involved. One guy wore a tie. Some of the engineers don't even drive hybrids. I'd steer clear of it, is what I'm saying.

Re:Not a cron replacement, a init replacement

[Senjutsu]

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?

Re:Not a cron replacement, a init replacement

[JohnsonWax]

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.

Re:Not a cron replacement, a init replacement

[As Seen On TV]

Because XML configuration files are self-validating.

The fundamental problem launchd was created to solve is system startup time. Twenty or thirty seconds to boot a freakin' laptop is just absurd. So we used launchd to get that down to four.

But beyond that, launchd also takes care of the problem of having six different types of configuration files, none of which are self-documenting or self-validating. A launchd configuration file can be validated and, if invalid (like somebody inserted a typographical error, or the file got truncated or something), discarded without interfering with system startup. That makes the system more resilient.

Re:Not a cron replacement, a init replacement

[Anthony Liguori]

The fundamental problem launchd was created to solve is system startup time. Twenty or thirty seconds to boot a freakin' laptop is just absurd. So we used launchd to get that down to four.

You can do parallel startup on most systems these days. Is there any reason why a daemon is necessary to improve startup time? Are shell scripts really that slow?

But beyond that, launchd also takes care of the problem of having six different types of configuration files, none of which are self-documenting or self-val

Re:Not a cron replacement, a init replacement

[As Seen On TV]

Is there any reason why a daemon is necessary to improve startup time?

The launchd service isn't a daemon. It's a replacement for init. And yes, it speeds things up considerably. Previously, every startup script required its own instance of a shell to be fired off. Now that middleman is removed. And it made things considerably faster and simpler.

But why XML over say something like INI or a much simplier format?

Because XML is self-validating, like I said. The contents of the file can be checked for consistency before being used for anything.

It also quickly becomes unreadable.

You don know that we're talking about property lists here, right? It's an XML-based format, but it's not totally free-form XML. You can't just plug in any valid XML and expect launchd to handle it. If the file doesn't validate against the property list schema, launchd will just ignore it.

Besides, we've been using property lists everywhere for five years now. Nobody's complained yet. ;-)

Re:Not a cron replacement, a init replacement

[crush]

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.

Re:Not a cron replacement, a init replacement

[JQuick]

The launchd source code is a collection of programs which span several related areas. In the broadest terms the contents of the distribution cover init, SystemStarter, and launchd.

Most people talking about launchd in the context of parallel system startup are actually talking about SystemStarter. Also note that the plist files which drive SystemStarter can be in one of two forms. The most common of these is the NeXT style textual plist format which is very human friendly and is not XML-like in structure or appearance.

As a replacement for aither BSD style or System 5 style rc scripts, SystemStarter is a definite improvement, both in terms of ease of use, speed, and reliability. The launchd subsystem uses XML formatted property lists. I am unsure whether NeXT style plists are supported for these.

Regardless, you were dismissive of launchd claiming that it was mere init replacement. You thought you were speaking about launchd but sound like you had only heard about SystemStarter.

launchd itself it a super-server which reads process definitions. These definitions can describe processes to be run using a set of predefined keys. Some examples of key value pairs are: Program/ (path to executable), or ProgramArguments/ (The array of strings to pass as arguments to the program). The interesting thing about launchd is that the predefined key/value space is so rich, and so well considered.

The keys span several related domains which Unix users associate with a number of different tools and data sources. Here are a list of some interesting areas covered.

like sudo or vixie cron the user and group under which to launch the program can be specified using any of { UserName, UID, GroupName, GID }

WorkingDirectory causes a chdir(2) before executing the job.
RootDirectory specieis a chroot(2) for the child process.

StdOutPath and StdErrPath can specify where to redirect output of the program.

OnDemand specifies whether to run only as needed or ensure that a server process should always be available, thus respawned.

Labels and Groups provide a way to refer to processes with greater specificity or to group related processes together for reporting or action using launchctl.

A set of time specific keywords cover a superset of at and cron time specification.

Soft and hard resource limits for the job can be tuned using keys that provide acces to all ulimit functionality (file descriptor file size, memory footprint, core size, etc.. Similarly the nice value can be specified to constrain CPU usage, and the *PriorityIO keys specify what priority the kernel should use for scheduling disk IO for this task.

The Socket Key defines an optional dictionary defining IPC behaviors controlling combinations of open/bind/connect/listen. (think inetd and xinetd). Beyond this you can also specify other things here like "Bonjour" to register this service with mDNSResponder. If a SockPathName is specified attempts to open a named unix domain socket will cause this program to launch.

If these are not enough, a launchd plist can start/stop a program when a watched file changes. When passed the path to a directory, the program can be started when the program is not running and the directory is not empty. Think about this one... A robust queue processing program might be simply:
#!/bin/sh
lockfile $SOMELOCKFILE
for file in *
do
process "$file"
done

WorkingDirectory and a watched directory path, along with whatever CPU/Disk IO/Memory/user/group are all handled by launchd. Similarly launchd ensures that the process runs when there is work to do, and is never launched unless there is work to do.

Finally, if the predefined keys and actions are insufficient you can call a small number of stubs implemented in Tcl to set either one shot timers or interval timers at which point the scripts is re-interpreted. You can pass messages to syslogd, start or stop jobs. A form of system introspection is also pr

Re:Not a cron replacement, a init replacement

[As Seen On TV]

There is no access layer that surrounds a plain text file.

In fact, there is. With Core Foundation, the process of unserializing a property list is atomic. The bytes are read from disk and validated. If and only if the file validates, the data structure is populated and returned by reference, all in one function call.

So yeah, property lists are self-validating.

You have to be DAMN sure that the file is easy to understand and edit by an admin, even if he only has "ed" over a serial connection available.

You mean like the universal, thoroughly documented and self-validating property list format, for example?

I'd much rather work with: TAG:VALUE

Great ... right up to the point where "TAG" has a colon in it, or whatever your delimiter. Or where "TAG" or "VALUE" needs to be in Japanese. Or where "VALUE" needs to be a container like a CFArray or a CFDictionary.

Or, for that matter, where "VALUE" needs to be of a specific type. If you're stuck with "TAG:VALUE" then you're kinda screwed when it comes to explicit type-checking, aren't you?

I can confidently write a program to validate and parse inittabs, but I don't know how to that with XML

You aren't expected to. Core Foundation does it for you. There's one function call to serialize a data structure and one function call to un-serialize it.

XML files, are difficult to read, difficult to edit, difficult to edit with programs, and poorly-defined.

Come on, now. Isn't that kind of a stupid statement? XML files are spectacularly easy to read, especially compared to the random mish-mash of configuration-file formats available on Unix. Editing is trivial, of course, because it's just text. More importantly, editing is trivial wherever you are, because the files are UTF-8 and not just ASCII. And calling a document that includes a machine-readable DTD for automatic validation inside it "poorly defined" borders on the farcical.

Some of us have been complaining since the NeXT days. :\

That's funny. Because there were no XML property lists in NEXTSTEP. They were added for Mac OS X.

Re:Not a cron replacement, a init replacement

[gstoddart]

Because XML configuration files are self-validating.

As opposed to all of those depressed, self-loathing DOC files out there?

Re:Not a cron replacement, a init replacement

[As Seen On TV]

1. There are not "more versions of XML" than there are of anything. There's exactly one version of XML.

1a. It doesn't matter, because we're not using whatever valid XML you decide to poop out. We're using Property List 1.0, which is a specific XML document type.

2. We're not forcing anybody to do anything. We're offering third parties a chance to use our innovation. If they don't want it, they don't have to take it.

2a. Nobody would ever use an XML parser to read a plist anyway. You just use the serialization/unserialization routines we've written into Core Foundation, which is also part of Darwin and therefore also open source. You turn a plist into a CFDictionary in about three lines of standard C code, counting error-checking.

Re:Not a cron replacement, a init replacement

[zorander]

I don't know this, but launchd (hopefully) does proper dependency-based concurrency, something that rc.d has lacked for a while. rc.d launches everything in order. What you really need is a dependency graph and then to traverse down it. Init will start first, then anything that directly depends on init. Once a process' dependencies are met, it starts. This is not a hard calculation (though I forget exactly which graph algorithm you use) and could vastly improve startup time. If they're experiencing vastly i

Makes booting DAMN fast

[the_2nd_coming]

the machine boots to a desktop (auto log in and all) in less than 15 seconds.

Re:Wait, wait, wait...

[As Seen On TV]

Actually, 15 seconds sounds really wrong to me.

To keep things simple, we divide the boot process into two halves: the hardware half and the software half. The hardware half involves power-on self-tests, and the time it takes varies wildly from computer type to computer type, or even from configuration to configuration. It takes longer to test 8 GB of RAM than 512 MB of RAM.

The software half begins with the grey Apple-logo screen turns blue and the progress window appears.

From the time that happens to the time the menu bar appears (via autologin) should be four seconds on a stock Mac OS X install with middle-of-the-road hardware (dual 1 GHz G4).

Re:Wait, wait, wait...

[Anonymous Coward]

It takes longer to test 8 GB of RAM than 512 MB of RAM.

Why the hell is the user forced to wait through the RAM test? All that has to be tested is the portion needed for booting, and the rest can proceed in the background, with RAM becoming incrementally available to the system as it finishes testing.

This takes a significant portion of the boot time, and is nothing but piss-poor lazy design. If you add all the minutes wasted over all the people who use the OS over its life, that's a hell of a lot o

Re:Wait, wait, wait...

[Paradise Pete]

If you add all the minutes wasted over all the people who use the OS over its life, that's a hell of a lot of man-hours.

Yeah, no kidding. I must boot at least once every few months or so, so pretty soon that's going to add up to...uh, a couple of minutes.

Re:Wait, wait, wait...

[As Seen On TV]

Is there a way to make Dashboard widgets sticky on the desktop?

You don't want them to. One of the benefits of the Dashboard layer is the fact that when the Dashboard isn't visible, the widgets are completely suspended, consuming no CPU cycles at all. If you put a widget on the screen outside the Dasboard layer --which of course you can do, if you run Dashboard in debug mode --it'll execute its run loop all the time, sucking up CPU cycles unnecessarily.

How to put widgets directly on your desktop

[socratic method]

There is a method for detaching Dashboard widgets described here [macosxhints.com].

This lets you keep as many widgets as you want on your desktop, and they don't jump back into the Dashboard every time you display it.

The one remaining annoyance is that they float above all of your other windows. Hopefully there will be a hack for this soon.

Re:Wait, wait, wait...

[As Seen On TV]

In all fairness, it sounds like you're the one who's ignoring the elephant in the room. If it's taking five minutes for your laptop to pass POST, you need to take it in for repair. It's obviously got a hardware problem.

This sentence no verb?

[Anonymous Coward]

I have nothing to contribute to this discussion, except for my opinion on how ambiguous headlines are. For example, "Does launched beat cron?" has the following possible meanings (yes, I see it's launchd, but listen):
1) Does as a verb, launchd as n, beat as v, cron as n. That is, a question whether or not the thing "launchd" beats the thing "cron".
2) Does as a verb, launched as adj, Beat as n, cron as v. That is, a question whether or not thing Beat, which has been launched, crons. (Well, "croon" is a verb, so maybe "cron" is too).
3) Does as a noun, launched as v, beat as adj, cron as n. That is, a statement that female deer have launched "Beat cron" -- cron that has been beaten, perhaps.
Any others?

Previous message no content?

[QuietLagoon]

Any others?

No, you've covered them all.

Also check out Solaris SMF

[Wesley Felter]

Sun came up with (at first glance) a similar thing called Service Management Facility [sun.com] in Solaris 10.

As long as it doesn't break the fundamentals...

[yorick]

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.

Did anyone else initially think

[Aexia]

that the submitter simply couldn't spell or capitalise correctly?

"Does launchd Beat cron?"

What is that? Some new form of AOL speak?

Re:Did anyone else initially think

[One Childish N00b]

While confusing, the styling of the article title is correct - it's just the combination of capitalisation as is normal for titles with the names of the commands all being in lower-case. UNIX commands are case-sensitive, thus there is no commad called 'Cron', only 'cron', and it's good journalistic form to spell names for things with correct case, even if (in this example) it does make things a little confusing/AOL-ish

Less Compatible?

[imemyself]

Isn't half the attraction to OS X for geeks how its not that much different from Linux or BSD from the console? And that many/most Linux/BSD scripts and apps would work with just a few, if any changes? I don't see how making it more different really helps it. Not trying to be a troll, but I got to assume if all or most the other Unixes work with what launchd replaced just fine, that OS X could as well.

Re:Less Compatible?

[revscat]

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."

Re:Less Compatible?

[NMerriam]

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.

Re:Less Compatible?

[BoydWaters]

> ...USC Berkeley...

Awesome. One incorrect letter -- the most succinct way of pissing off Northern Californians and Southern Californians I've yet encountered.

Re:Less Compatible?

[drsmithy]

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.

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.

XML?

[Anonymous Coward]

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.

Re:XML?

[lewiz]

Not being able to use cut/sed/"etc." is your only reason that launchd is bad?

Let's put it this way... how long would it take to come up with some simple awk script that will facilitate the use of cut/sed/etc. on XML files? Now, how much longer do you think it would take to address all of issues launchd addresses?

Re:XML?

[jonabbey]

Python and Perl have perfectly robust XML i/o libraries these days. I don't think I'd mind very much writing the extra ten lines of Python code required to interface with XML, particularly if the transformation I want to do to the config file is simpler in terms of XML than it would be in terms of sed, etc.

Re:XML?

[moof1138]

Apple also includes command line tools such as 'defaults' for editing plists so that you can edit them and make sure that you wind up with a valid plist in the end. There's a new tool in Tiger, but I can't recall

Perl on OS X also includes the ObjC bridge which can be used to easily read a plist in as a hash. From there it is easy to edit it and then dump it back out.

So in Mac OS X there are tools to easily read and modify the plists. If porting launchd to another platform, then making comparable tools

SYSV.. bah. BSD-style is the way to go.

[rice_burners_suck]

I thought this was a replacement for the big messy SYSV-style init scripts.

Speaking of which, back in about 1995, I think it was, I installed my first Linux distro that I actually used on a daily basis. It was an early version of SuSE linux. Anyway, as I scratched deeper and deeper under the surface, I came to the conclusion that the init system was a mess... the entire system's functionality was implemented as piles upon piles of shell scripts, organized neatly into a whole bunch of directories, and activated according to their name and whatnot. This seemed kind of dumb, actually, because it meant that startup, shutdown, and switching runmodes were a lot less efficient than necessary, and also because you'd have to search through a zillion (that's a big number) scripts to find what you need.

A few years later, in 1999 or so, I tried FreeBSD for the first time. (Here it comes, I'm gonna be modded troll for starting another BSD- vs. SYSV-style init script war...) There, the functionality is still implemented in scripts, but there was a much more sane system. There is one script that is the same across all FreeBSD installs of that version. Then, there's the script you get to customize if you want. There's one more file, and that's where you simply give yes or no answers, or provide other data, in the form of environment variables that influence the running of those two scripts. It's so simple, and works quite quickly. Also, since you really only mess with one file, and two if you modify the script, it's much easier to find where things are. It's more efficient, from many standpoints.

So I don't blame Apple for getting rid of that SYSV stuff. It might have been cool back in the day, but it has lost its luster.

Re:SYSV.. bah. BSD-style is the way to go.

[harlows_monkeys]

A few years later, in 1999 or so, I tried FreeBSD for the first time. (Here it comes, I'm gonna be modded troll for starting another BSD- vs. SYSV-style init script war...) There, the functionality is still implemented in scripts, but there was a much more sane system. There is one script that is the same across all FreeBSD installs of that version. Then, there's the script you get to customize if you want. There's one more file, and that's where you simply give yes or no answers, or provide other data, in the form of environment variables that influence the running of those two scripts. It's so simple, and works quite quickly. Also, since you really only mess with one file, and two if you modify the script, it's much easier to find where things are. It's more efficient, from many standpoints.

The main problem with that is it presumes that you have a human doing all the messing with that one file.

The SysV approach is much more friendly to programs, such as installers and uninstallers, and configuration managers, that wish to make changes, or that wish to start and stop individual daemons other than at startup or shutdown.

Re:SYSV.. bah. BSD-style is the way to go.

[Guido von Guido]

Also, in many cases you don't have to directly edit all those files. For instance, you can chkconfig on many distributions to turn on and off services at boot time. (Or whatever it is Sun uses in Solaris 10 now, not that I've had a chance to play with it much yet.)

It's also easier to test startup and shutdown scripts. For instance, if I want to test the foo startup script, I just run "/etc/init.d/foo start" (or "service foo start" on some distributions). With the BSD-style startup scripts, I have to add i

*sigh*

[cbiffle]

This thread, so far, seems to be filled mostly with "Ah! Someone's doing something differently than UNIX has for 30 years! My knee is jerking!" So I feel I should respond.

launchd is neat. It's not simply a different way of doing the same things, it lets you do different things.

Like automatically evaluating dependencies between daemons, starting them in the right order, and running them in parallel if needed. FreeBSD's the only other OSS system I've ever seen do this; Gentoo does the dependencies but not the parallel startup. (Which is annoying while it's, say, trying to get an address from a nonexistent DHCP server.) Long story short, it dramatically reduces boot time, while eliminating dependency hacks like runlevels and numbered scripts. (Not that BSD had them.)

For those of you who posted without reading the manpage (or administering an OSX system), it also lets you do init-style startup tasks on a per-user basis. You can configure it to start daemons and other processes on the behalf of users as the log in, and shut them down -- gracefully, not by TERM; KILL -- when the user logs out.

Anyone who's ever dealt with the myriad of hacks to get ssh-agent in place will understand why this is good.

There's a lot of resentment these days toward anyone who does something that's perceived as "not the UNIX way." Change is the only way to innovation, people; perhaps the UNIX way is broader than you thought?

Re:*sigh*

[enthused i swear]

Gentoo will do parallel startup, though it is not set to by default:

Modify your /etc/conf.d/rc file thusly:

# Set to "yes" if you want the rc system to try and start services
# in parallel for slight speed improvement.

RC_PARALLEL_STARTUP="yes"

Not just MacOS X: Solaris has similar concept

[Darren.Moffat]

Solaris 10 has something very similar to launchd called SMF: Service Management Framework. It doesn't replace cron but it does replace init.d and inetd. It also provides backwards compatibility so that existing init.d scripts and run and existing inetd entries are migrated to SMF on upgrade.

SMF also does dependancy checks and auto matic restart on failure (or some other conditions). It also uses XML for its configuration but imports that into an SQlite database so that it doesn't need to reparse the XML on every service restart or system boot.

For more information on SMF in Solaris see the links in the main architect/developers blog [sun.com].

See also

[mattbee]

daemontools [cr.yp.to] and the free-er clone runit [smarden.org] which both give you the advantages of a non-linear system startup process, automatic service restarting, no need to write daemon-ising code in each program etc. Each author also has common tools to use with these service supervision programs to ensure network-based daemons don't need to write network code: ucspi-tcp [cr.yp.to] and ipsvd [smarden.org] respectively.

Brave Deian owners can apt-get install runit-run which will start your system with /sbin/runit instead of init from then on; we tend to use it on top of the existing init scripts.

And the system that's had such a sensible service supervision system since the year dot? Windows NT and its service control manager. Of course you could argue a centrally-controlled daemon restarter is much more of a priority when you expect your daemons to crash more :-)

cron still there

[Chanc_Gorkon]

Ye Olde cron is still there and running. My Bashpodder script still runs on Tiger. As for launchd, I am going to have to read up on that. Sounds interesting.

Are there schedulers better then cron? You bet. As a scheduler for home use, cron is fine. We are currently trying to find a ore robust replacement for cron that will attempt to correct things before reattempting a script and with dependency checking. When I used to be a operator on a DOS/VSE based mainframe, our scheduler had a dependcy check that would hold jobs from running at thier assigned time if the previous job did not finish and other things like that. It had very robust logging to. No e-mails to root. I could just run a report. There are schedulers that come close to this on UNIX but cron is a very basic scheduler that is flexible which is a saving grace.

launchd replaces cron?

[DaveGillam]

I'm not an expert, but from what I read of the XML files, launchd seems more of a wrapper program than a replacement for cron. Translated: ProgramArguments = /usr/sbin/cron; QueueDirectories = /var/cron/tabs; ps -wwax|grep cron # shows two cron processes in memory; So launchd takes the place of init, and starts up cron, with the proper arguments. Cron then takes care of its own.

It's about time. Linux needs something similar

[Nelson]

Cron and init and rc.X work fine, I'm not a hater. However I do think it's time to move forward. I like what Sun is doing with SMF and this is Apple's cut at it.

Basically, cron needs higher resolution, that's my only beef with it. It also seems like to do anything facny with cron you end up writing a program to do it and it's not that uncommon to do that.

The startup scripts need an all together different kind of overhaul. I've been working on Linux appliances for over 6 years now, without exception, it seems like someone ends up writing some kind of "health script" that is kicked off by cron every minute or a few or is a daemon in it's own right that watches for things to crash or not be running and then it restarts them. I've seen it in a production set-top box based on Linux where we essentially wrote our own init and had it treat some processes special and 5 different software appliances. Fact of life is software crashes from time to time. These scripts then do something else, like ping the gateway or something stupid to check if the network went down before they do what it is that they do. To make matters worse, they are always written in Perl by some guy who doesn't know Bourne shell to write a good startup script in the first place; that's the part that chaps me. Rather than contaminate the system with all this extra shit we should just have an easily extensible and configurable system process starter and monitor and it shouldn't require scripting to do anything advanced.

• Use XML for configuration, it's easy to parse, it's here to stay and I think it's a little bit better than the columns of a crontab because it's more verbose.
• Have variable restart behavior, restart, restart and restart dependancies, reboot, just let processes die, etc..
• Have dependancies (start the database before the shit that inserts data in to it, even though it shouldn't matter, it does) and start them in the right order.
• Kill dependencies when I kill a process
• Smart killing, if something doesn't gracefully go down, 9 it down.
• Have some kind of health monitoring call back, at a time I specify, execute a program that will check to see if a process is okay.
• Once all this is done, maybe support something like soft cycling, kill everything down to single user mode and then bring it all back.
• Variable dependency notification, if I restart my database allow me to do nothing to dependant processes, restart them, or HUP them, or something I define.
• Full featured logging.
• At some configurable interval, sniff out all of the XML configs in this "next gen startup proc" config directory, like every 5 minutes just check for changes and if needed, start something new up.
• Allow for user to be specified in the config
• Allow for end users to have thier own daemons defined by files in their home directories.
• Then finally, allow for cron like behavior and run tranient tasks with all the flexibility of cron.
• Proc specific ulimits would be nice also...
• And some form of runlevel logic still.
• And startup and kill in parallel if allowed by the depends...
• And it should have a template for common daemon type things I should just provide a startup command, arguments, a user to run it as, and a run level.

There are probably some things I forgot, it's really not that much, I could see bangin' this out in Python or java in not that much code. My thinking is that instead of checking for a PID file or grepping through ps outout to provide "status" you query a running process and it tells you your proc is up and running. Yeah yeah, I know, shit shouldn't crash and whatever. I've just seen such a shitty job of this stuff being done over and over and even on fairly stock installs of major linux distributions I've seen service

Open Source? Where's the source?

[__aaahtg7394]

Apple has open sourced the thing, and is apparently hoping all the unix kids will take a look.

I've been poking around at Apple's Open Source page [apple.com] and fail to see launchd, SystemStartup, or anything else thereabouts. Does anybody have a URL for this, or know of the specifics of getting the source? It looks like promising technology, and I'd love to get my hands on a copy to play with. I would also hate to think that we're being strung along with promises of an Open system that turns out to be only partially open (like the recent KHTML/Safari issue).

Re:Open Source? Where's the source?

[Eridius]

It's part of Darwin. Try this page: http://www.opensource.apple.com/darwinsource/10.4/ [apple.com]

auto dependency checking and parallel start

[metoc]

launchd is also capable of automatically checking for dependencies and scheduling services to startup in the correct order. It can even start services in parallel which speeds up the boot process.

does launchd beat cron?

[ni5mo]

according to googlefight...

no! [googlefight.com]

Re:my observation...

[kaiser423]

yea, it really seems to clean up a lot of things. Like being able to tell that the service or process shutdown, instead of just sending bigger and badder kill messages.

Looks like a nice clean API that has some nice message passing structure in it. I also kind of like the magic dealing with auto-resolving dependencies and starting programs in parallel if possible.

From the sound of it, it just seems cleaner in the back-end. Much less knowing specific Unix tricks or gotchas, and more of it just working and giving you the proper interfaces.

Re:Er, what?

[mark_lybarger]

did you RTFA? launchd seems to be a system wide super program launcher. startup, timed, event driven (plug in a usb memory stick and get a pop up window asking what you want to do).

from reading the article, launchd sounds like a viable technology to replace quite a few convoluted system on my linux machines.

Re:Is it really usable by the Open Source Communit

[antifoidulus]

Uh, the code is licensed under the BSD model. So Apple will get in trouble as well if there is patent trouble.
I know making the statement, "boo patents!" on /. will get you modded up automatically, but come on people....

Re:No thanks.

[ip_fired]

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.

Re:No thanks.

[thasmudyan]

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)...

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 /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!

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.

Re:Against the UNIX philosophy

[MrDomino]

cron, init, et al. were all doing basically the same thing: starting up processes. Quite frankly, I think this system is great; I'm no Apple-head, but I have to confess that *nix boot-up can be nightmarish. On a server that's rebooted maybe once or twice a year, this is acceptable, but on a laptop, something more substantial is needed. launchd seems to provide this, and while it may do separate tasks and violate the "UNIX philosophy" to some extent, there are cases when having a unified tool for separate bu

Re:I did RTFA, now tell me WTF it does

[klui]

Your reply sounds like it comes from a geek, or perhaps wannabe geek. Well, just check out the source and tell us. http://www.opensource.apple.com/darwinsource/10.4/ launchd-106 [apple.com]

Re:ugh

[As Seen On TV]

There have been several comments along these lines. I don't understand them at all.

The launchd configuration files are property lists, which are serialized Core Foundation data structures. They consist of key-value pairs. They map directly to data structures in memory. The code for parsing them is used all over the place in Mac OS X, and is very old. It dates all the way back to the first development in the late 1990s. It's highly optimized, and it's reused over and over and over and over again.

The second advantage to plists is that they're self-validating. When a program tries to load a plist, if the file doesn't validate against the PropertyList-1.0 DTD, nothing happens. An error is returned, and the program (in this case, launchd) moves on. No chance of a corrupt file producing unexpected results.

The third advantage is that we ship a handy property-list editor with our operating system. This makes it easy for developers to create and modify plists.

Finally, plists are always in UTF-8 format. That's vitally important for us, because our system is fully localized. We have to be able to launch services with names that don't fit into the ASCII/Latin-1 character set. Using plists ensures that we can do that, and gives us that capability for free.

The question here is, why would anybody want to invent their own proprietary ASCII-only, non-validating file format for something as important as system startup control?

Re:ugh

[As Seen On TV]

Does it have to be XML?

Well ... to put it bluntly ... yeah. Look, you and many other commenters here act like we just made up a whole new XML document type just for launchd. I have no problem with people who want to raise valid concerns, but would it kill you to learn thing one about Mac OS X first?

The format we're talking about here is what we call a "property list," a serialized data structure that's written out to disk in XML format. Here's an example. This is the launchd config file for KernelEventAgent, an important Mac OS X system service.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>com.apple.KernelEventAgent</string>
<key>ProgramArguments</key>
<array>
<string>/usr/sbin/KernelEventAgent</string>
</array>
<key>OnDemand</key>
<false/>
<key>ServiceIPC</key>
<false/>
</dict>
</plist>

This files are generated by the serialization functions in Core Foundation. You create a data structure, in this case a CFDictionary. Then you populate it with objects. In this example, that's four key-value pairs. The keys are "Label," "ProgramArguments," "OnDemand" and "ServiceIPC." The values are a CFString, a CFArray of CFStrings (with just one object in this case), and two CFBooleans. Then you issue one function call to serialize that property list to XML and another to write it to disk as a file.

Of course, in this particular case you wouldn't go through that trouble. But the important part is the other part of the process. You make one function call, passing it a path to a file, and you get back a de-serialized Core Foundation data structure, all type-checked and everything. If at any point the property list fails --if it fails in the XML validation or the static type checking --then you get back null and an error. All atomic, no muss, no fuss.

That's what launchd does. All clear now?

And shipping one of those implies there's difficulty in editing or reading the configs manually.

Look at it and you tell me. How daunted are you?

If you're building better solutions, maybe you can architect them to work well for most unixes?

We're releasing launchd, we're releasing Core Foundation, the property list format is both wide-ass open and fully documented in many different places. What else do you want?

Re:ugh

[node 3]

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?

Re:Apple's plist format

[Jeremy Erwin]

MacOSX programs make frequent use of NSDictionary, a Objective C collection class [apple.com]. There's also a C version, known as CFDictionary [apple.com]. It's worth noting that most of the relevant C interfaces, known collectively as "CoreFoundation" are open source [apple.com]

The CoreFoundation interface to MacOSX's built in XML parser is described here [apple.com].

Re:Re-post

[sean23007]

Hmm. So you think that this XML-based solution is bad because XML makes everything slooow. Interesting. Especially considering the fact that launchd reduces boot time from a minute to under 15 seconds. While XML itself might make some things slower, in this case it allows for processes to be launched concurrently on startup, rather than one at a time. The overhead of parsing an XML file is minimal compared to the speed gains launchd allows.

Pack up your anti-XML trolling and bring it elsewhere. It has some

Re:how can it automatically know dependencies?

[sean23007]

The programmer or administrator is responsible for putting that information in the XML file. That's why they're using XML. It allows for more data to be available. Where it (init) used to basically be a list of programs to launch, it (launchd) is now a system whereby a collection of programs are launched. It is much more flexible, and since it can launch programs concurrently, much faster as well.