Hacker News new | past | comments | ask | show | jobs | submit login

I'm genuinely confused as to why launchd isn't part of this conversation. It is definitely a replacement for cron (and init) and seems to be a pretty good one. I haven't done an extensive comparison between it and cron, but it has definitely been easy to use and worked well for me. It is very flexible and you use it by laying out exactly what you want it to do in XML.



I had issues in the past with scheduling processes in launchd. It's been a while, but I remember having these issues at least two OS revisions after Apple initially launched it. (The issue was related to starting a process and having launchd restart the process if it died. There were options to toggle this but it wasn't working for me, and I was reading the Apple developer docs on launchd.)

Also, I personally don't feel that using XML as a config file format is necessarily an improvement over what cron offers now. (I know that I'm skipping the fact that 'XML is self-validating,' but I don't really find a lack of a self-validating config file to be a major issue with cron)


One of the biggest gotchas I found was that launchd bails if the process takes less than 60 seconds to run. Putting a "sleep 60" at the tail of the script fixed a lot of problems for me.

At first I was kind of upset that this condition was there, but in retrospect it might have been a very wise design choice to stop runaway triggers.


Now that you mention it, I remember that quirk. I had an issue with not being able to disable that quirk when running a scheduled process. launchd would stop scheduling a process that was scheduled to run every 5 minutes if one of the runs took less than 60 seconds. It really irked me because this 60-second-rule only makes sense when you are talking about re-spawning a constantly running process, and should not affect the behaviour of processes running on a schedule.

> At first I was kind of upset that this condition was there, but in retrospect it might have been a very wise design choice to stop runaway triggers.

It doesn't really stop runaway triggers if all of the scripts have a 'sleep 60' at the end of them. And if you are concerned about runaway triggers you could always make the rule something like "bail if the process dies after <60s more than once in a 2-minute period" or similar since there are legitimate processes out there that take less than 60 seconds to run.


Well, I didn't say it was perfect. =)




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: