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."
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.
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.
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.
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 "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.
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?
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 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.
I know the guy who does the Darwin releases.
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