Does launchd Beat cron? 798
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."
Re:my observation... (Score:5, Interesting)
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.
Less Compatible? (Score:3, Interesting)
Re:Ahh yes. (Score:3, Interesting)
- really wasteful
- it takes a long time to parse
- inconsistent (like, the sometimes-freeform-sometimes-not issue)
- quite human-unreadable
Sure, it's better thanJust like SMF (Score:2, Interesting)
Re:Makes booting DAMN fast (Score:2, Interesting)
Besides, what I'd be interested in is how this compares to Sun's SMF (System Managament Facility), which is also supposed to be a replacement for the SysV init system.
Re:Ahh yes. (Score:1, Interesting)
Re:Not a cron replacement, a init replacement (Score:3, Interesting)
Re:Wait, wait, wait... (Score:3, Interesting)
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 of man-hours.
Re:Not a cron replacement, a init replacement (Score:3, Interesting)
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.
launchd running jobs at wrong time? (Score:2, Interesting)
Has anyone else seen this? Any ideas?
Comment removed (Score:3, Interesting)
Re:Re-post (Score:3, Interesting)
Pack up your anti-XML trolling and bring it elsewhere. It has some good uses. I very much doubt that you'd be happier with it if they used some proprietary, non-readable format instead of XML since it would save them all of 0.025 more seconds on boot.
Re:SYSV.. bah. BSD-style is the way to go. (Score:4, Interesting)
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.
It's about time. Linux needs something similar (Score:5, Interesting)
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
Open Source? Where's the source? (Score:3, Interesting)
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).
As Seen On TV is a Troll (Score:0, Interesting)
Mods: How the hell is pointing out the obvious -Flamebait?
Re:Submitter is confused (Score:5, Interesting)
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:*sigh* (Score:2, Interesting)
We created it as--as the name should tell you--something like System V Init for z/VM. The traditional method of starting service machines under VM is to put a bunch of AUTOLOG statements in the PROFILE EXEC of the AUTOLOG1 user. This is, yes, even cruder than System V.
The motivation was basically to give a more flexible and familiar startup system to people running multiple Linux images under z/VM, who understand Linux but don't want to deal with CMS and would rather just approach z/VM purely as a hypervisor.
SYSVINIT uses runlevels, which are like System V runlevels except arbitrarily named, and which define a list of services that should start in each runlevel. Each service can in turn list other services that must be running before it can start, and other services that should have been shut down before it can exit.
The system builds a dependency graph from this information, and starts whatever it can in parallel. Basically, I grew annoyed at the inability of System V Init to do real contingent startup processing, and so I fixed that part of it.
It also provides well-defined APIs so that the services you write can respond appropriately and do graceful shutdowns or configuration reloads. Failing that, it is able to do the moral equivalent of TERM; wait some (user configurable) number of seconds; KILL.
I like to think it's pretty slick, but then I wrote it. The underlying operating system is most definitely non-free, but this tool is free (speech and beer; it's released under the Artistic License).
Go to http://sinenomine.net/vm/s5i [sinenomine.net] and get it if you're interested. You have to register with the site to get to the download section, but registration's free.
A future development--not there yet--is the ability to submit commands from an external (non-VM) machine. This is going to involve NJE-over-TCP, and should let you control your VM services from any old TCP-networked workstation, assuming you're running RSCS on the VM box and have defined a link to the workstation. This ought to make life *really* easy for people wanting to control Virtual Penguin Farms from their desktops, without requiring them to be good at VM system administration.
No, it's not as slick as launchd, but it does at least provide real dependency tracking and contingent service startup.
Adam
Re:Submitter is confused (Score:5, Interesting)
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:Wait, wait, wait... (Score:3, Interesting)
Re:Submitter is confused (Score:3, Interesting)
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 format. Even though XML is rather misanthropic format, if it's system wide this is still very big advantage. If you would just make some nice and human friendly XML editor with integrated support for all Apple's plist types, help, search and so on - this would be nice.
auto dependency checking and parallel start (Score:3, Interesting)
Apple's plist Format (was Re:ugh) (Score:2, Interesting)
Apple's plist stuff is an abuse of XML. All those keys should have been XML elements so that I can actually validate the configuration using a DTD or a schema, not just the key/value structure.
It's also maddening to use XPath on a plist. I once needed to use Apple's iTunes export format to programmatically recover from a disk failure. The plist format made it difficult to get at the information associated with each file that I was missing.
Re:Submitter is confused (Score:3, Interesting)
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:
I would welcome launchd as a replacement for the first, but replacing all those things, all three categories is not only has no advantages (i think only init needs fixing, cron and xinetd is good as it is) , but potentially bloats the whole thing. Let's see, if we combine the three categories, we deal with a lot of things at once: scheduling, networking, system runlevels, dependencies.
Re:No thanks. (Score:0, Interesting)
You can alter this behaviour by editing the startup scripts appropriately. Please read the manual on how to do this.
Alternatively, buy a Macintosh where your limited experience in the real world of Linux will make you some sort of God. You never know, your ego may increase to be only slightly smaller than mine.
Re:Submitter is confused (Score:1, Interesting)
For coders and system admins the issue is obviously not at what conceptual level these functions can be abstracted as similar, but their functional overlap. Offhand I see very little functional overlap between three types of programs (init, cron and inetd) beyond "they all start and stop programs." It's entirely possible that combining superficially similar functions only results is greater complexity in their implementation.
Also I think you are conflating two issues when you toss in the consolidation of program configuration. It's not obvious to me that such consolidating overlaps well with starting and stopping programs.
Re:Submitter is confused (Score:3, Interesting)
You mean the UserName key? Sure, I suppose it's possible that some mechanical process could alter the bits on the disk so that the value for the UserName key becomes "root" instead of "littlebilly." But it's not very likely, is it?
Basically the gist is, if there's an error isn't it more secure to abort entirely rather than possibly run something the wrong way?
There's a difference between refusing to fire off a given task defined by a (truncated, whatever) config file and leaving the computer in an unbootable state. If inittab were to be truncated, your computer would fail to book. With launchd, you never have to worry about that.
Re:Not a cron replacement, a init replacement (Score:3, Interesting)
I'm more accustomed to the definition that a daemon is a server, like ftpd or named. It's just the terminology that I learned years ago, and it's stuck with me ever since.
But if you want to throw that out, I'm cool. Yes, launchd is a daemon, in that it's not a user-interactive program.
Re:Not a cron replacement, a init replacement (Score:3, Interesting)
The fact is that for any non trivial application configuration will become so complex as to resemble a language (see exim for example). In my opinion those config files should simply be python or ruby or something.
As Seen On TV obviously needs attention ("we"??) (Score:3, Interesting)
You're not him.
I know the guy who has been working on launchd for over two years now.
You're not him.
I know the guys who work on the BSD Technology Team.
You're not any of them.
So what I want to know is, where do you get off using "we" every time you open your mouth about Apple? You didn't write it. You didn't think of it. I doubt you could do either. The credit isn't yours, and I have a feeling that Corporate Security is bearing down upon your desk in the QA department right about now.
If I were you I'd shut my trap and cover my ass.
-- AC
Re:XML plist configs are easy (Score:1, Interesting)
I will admit that I wasn't the clearest. However, if you use XML as you suggested. Then for each version of your program which adds preferences you need a new DTD in order for you to fully validate. Since a program should be able to handle all versions of its preferences. You now need to check against multiple DTDs.
If I turn off the validator... well that seems to go counter to your desire to validate against the DTD.
The application in question is lame. There is no separation of preferences storage and application specific details so it is completely aware of the program domain. Need to add a new preference? You have to add it to the raw code that reads/writes preferences (2 places in that program).
I highly suspect the program doesn't handle new versions of the program reading older preferences or the like.
I admit that if the storage was at least an isolated component, it could spit out arbitrary XML. But it would be a lot harder to find the right DTD.
Side question: Hmm, does an XML DTD itself even state what a value of a field should be, or is it always tags about strings? The property list DTD at least has a description for each value of whether it's a string, array, int, hash (dictionary), or boolean.
I decided to go with an Apple Property List in a cross-platform program, without using Apple's Preferences API, because I wanted better preferences than a memory dump. (what my program had been doing.) Because I wanted them human readable. And because I wanted room for growth without having to flex the DTD for every internal and external release of the program.
Basically, I saw what the other program was doing and desperately wanted to avoid what it had done and I was willing to make an isolated storage layer. Property lists fit what I needed out of my storage layer (application shouldn't care about how preferences are stored, preferences shouldn't care what is stored.) And as an added bonus, because of the ubiquity of property lists on MacOS X, there are already tools to work not just with XML, but explicitly with Property Lists.
I'm no XML God, but just a young programmer. And what Apple was doing with the property lists made a heck of a lot more sense than anything else I had seen. And most likely much more sense than anything I could design as well.