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."
But can it be piped?
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.
/etc/rc.d scripts (considering the length of pause an fsck would take--users would certainly assume there system hung during boot).
This is somewhat understandable for something like OS X. Doing something simple like displaying a GUI detailing startup is terribly difficult with
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.
the machine boots to a desktop (auto log in and all) in less than 15 seconds.
I am the Alpha and the Omega-3
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?
Sun came up with (at first glance) a similar thing called Service Management Facility in Solaris 10.
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.
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.
that the submitter simply couldn't spell or capitalise correctly?
"Does launchd Beat cron?"
What is that? Some new form of AOL speak?
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.
Before you jump the gun:
So yes, it is a cron replacement.
i don't read slashdot anymore.
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).
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
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."
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.
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.
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?
No, you've covered them all.
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.
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).
We're all very impressed if you work for Apple, but the chest-thumping is getting a little tiresome.
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.
Gorkman
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 .
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?
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..."
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.
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
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.
Lack of eloquence does not denote lack of intelligence, though they often coincide.
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.
We did open-source launchd. It's part of Darwin 8.
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.
It's part of Darwin. Try this page: http://www.opensource.apple.com/darwinsource/10.4/
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?
> ...USC Berkeley...
Awesome. One incorrect letter -- the most succinct way of pissing off Northern Californians and Southern Californians I've yet encountered.
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.
according to googlefight...
no!
Well
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.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?
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
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.
- Jordan Hubbard co-founder, the FreeBSD Project. Director, UNIX Technology. Apple Computer