(Return to web page)

Post Comments

Comment Guidelines

All comments are moderated. The goal is not simply to eliminate obnoxious stuff, but to only allow useful on-topic discussions -- it's not a place to hang out. Moderation time is expected to be a day or two in most cases, but I do take vacations.

Your comments will be read by me, but they may not be posted. In particular, saying thanks or "you rock" or whatever is certainly appreciated, but I won't add it to the public comments unless there's useful information there for others. Comments that say "you suck" are much more likely to be posted, as long as a reason is given that's somewhat productive. Posting a comment is not a promise to keep it here forever, I may remove any or all comments at any time.

I may edit postings for simple and obvious errors, and I may remove profanity. Only listed HTML terms are allowed in messages. Name and email address will be fully stripped or quoted to prevent HTML tag usage and other possible abuses.

You can provide either a public or a private email address, or none at all. Private addresses are good if you want a personal response from me. I do not provide any automatic notification of new comments.

There is no re-editing after posting, however you can simply post again, and hopefully I'll notice this in moderating, and will post the latest version. If your post is already up, just add another post with any corrections, and in most cases I'll pub up both posts, rather than hand- correcting the original.

*Email addresses are scrambled and encoded in a non-mailto URL. People with javascript see a normal working email link, but robots (and people) without javascript see a URL with gibberish in it. This link is a sample with working javascript (clicking should bring up a mailer), and this link is appoximately how it looks without javascript (click to see how your address will look to people without javascript). If you view the source, you'll see they're all gibberish.

8 comments:

At 2009/01/26 14:09
Minor Daemon wrote:

Who the heck still uses cron? ;)
Honestly though, cron is supplied with the system, but it is basically an add-on. It seems to me it's up to the administrator to configure add-on software, for backward and forward compatibility, until the developer provides an update resolving any issues that might have cropped up -- if they so choose.

Creating a Launch Agent and script can provide login-time environment validation and remediation when required, no?

At 2009/01/26 14:31
wrote:

Apple claims that they support OS X as a standard Unix desktop replacement. In that context, cron can not be considered "add-on".
Yes, there are a few different kludgy ways I could get around this. But it shouldn't be my job to fix Apple's bugs.
tom

At 2009/08/29 18:53
Ryan Bowlby wrote:

Launchd in 10.5 replaced the "OnDemand" value within .plist job files with "KeepAlive". The new "KeepAlive" allows two options that help address explicit dependencies.

1. PathState - "Each key in this dictionary is a file-system path. If the value of the key is true, then the job will be kept alive as long as the path exists. If false, the job will be kept alive in the inverse condition. The intent of this feature is that two or more jobs may create semaphores in the file-system namespace."

2. NetworkState - " If true, the job will be kept alive as long as the network is up, where up is defined as at least one non-loopback interface being up and having IPv4 or IPv6 addresses assigned to them. If false, the job will be kept alive in the inverse condition."

So now you can configure crond to require the presence of /some/directory/ before being launched.

I guess the apple developers ventured from their ivory tower for a bit. I'm as surprised as you are. ;)

My site: www.ryanbowlby.com

At 2009/08/31 13:30
wrote:

I'm not sure if I was aware of those when I wrote this article. They don't seem sufficient (to me) to adequately address the issues, and specifically, I don't see how they can be used to delay cron startup until the needed directory service is running.
tom

At 2009/09/05 4:56
Ryan Bowlby wrote:

I agree these two directives are less than sufficient. They probably only continue supporting crond so as to remain POSIX compliant. I continue to use cron, creating a plist file for something as rudimentary as a scheduled task is a less than efficient use of time.

Is there any file/directory on the system that exists only after directory services has started? Such as a PID file or additional mounts.

At 2009/09/08 21:33
wrote:

I don't know of any files I could use. And things like pid files have the annoying habit of continuing to exist after the process or system has crashed, so in general, it wouldn't be a reliable method.
tom

At 2011/03/14 0:26
wrote:

good comments.
cron is lame.
the author of it is not to be trusted to code in the users' interests,
anymore than the launchd authors. it's all about the $$$ they get from corporations who haven't the foggiest idea what makes for reliable software.
i wrote a silly shell fucntion that takes a date or time period in any format, calculates the time to wait, sleeps then executes. simple.
no daemon wakeup nonsense. can be combined with nohup.
no resource competition issues like with at(1).
then later i discovered paul jarc (code.dogmap.org) wrote something like this in c called runwhen.
no one is perfect but djb and his followers have a much more solid approach to this stuff.
to take another example, the init on my os has grown from 18 lines to 80+ lines of code since the bsdi days.
these are very simple parts of the system that are have unnecesarily tweaked to the point of becoming a nusisance.
but adding features helps sell software and support, so...

At 2011/03/14 9:03
wrote:

I certainly appreciate the idea of keeping things simple. But as Einstein said, "Make things as simple as possible, but not simpler." A program which sleeps for a while and then runs something is not cron. It is not even the "at" command. The scheduling won't survive a reboot. Unless of course you think that "reliable" is just an unnecessary tweak.
And cron was written by different people over time, with the original version attributed to Brian Kernighan. I've never heard anyone say he's not to be trusted.
tom

End Comments

Return to web page.

At 2009/01/26 14:09 Minor Daemon wrote:	Who the heck still uses cron? ;) Honestly though, cron is supplied with the system, but it is basically an add-on. It seems to me it's up to the administrator to configure add-on software, for backward and forward compatibility, until the developer provides an update resolving any issues that might have cropped up -- if they so choose. Creating a Launch Agent and script can provide login-time environment validation and remediation when required, no?
At 2009/01/26 14:31 wrote:	Apple claims that they support OS X as a standard Unix desktop replacement. In that context, cron can not be considered "add-on". Yes, there are a few different kludgy ways I could get around this. But it shouldn't be my job to fix Apple's bugs. tom
At 2009/08/29 18:53 Ryan Bowlby wrote:	Launchd in 10.5 replaced the "OnDemand" value within .plist job files with "KeepAlive". The new "KeepAlive" allows two options that help address explicit dependencies. 1. PathState - "Each key in this dictionary is a file-system path. If the value of the key is true, then the job will be kept alive as long as the path exists. If false, the job will be kept alive in the inverse condition. The intent of this feature is that two or more jobs may create semaphores in the file-system namespace." 2. NetworkState - " If true, the job will be kept alive as long as the network is up, where up is defined as at least one non-loopback interface being up and having IPv4 or IPv6 addresses assigned to them. If false, the job will be kept alive in the inverse condition." So now you can configure crond to require the presence of /some/directory/ before being launched. I guess the apple developers ventured from their ivory tower for a bit. I'm as surprised as you are. ;) My site: www.ryanbowlby.com
At 2009/08/31 13:30 wrote:	I'm not sure if I was aware of those when I wrote this article. They don't seem sufficient (to me) to adequately address the issues, and specifically, I don't see how they can be used to delay cron startup until the needed directory service is running. tom
At 2009/09/05 4:56 Ryan Bowlby wrote:	I agree these two directives are less than sufficient. They probably only continue supporting crond so as to remain POSIX compliant. I continue to use cron, creating a plist file for something as rudimentary as a scheduled task is a less than efficient use of time. Is there any file/directory on the system that exists only after directory services has started? Such as a PID file or additional mounts.
At 2009/09/08 21:33 wrote:	I don't know of any files I could use. And things like pid files have the annoying habit of continuing to exist after the process or system has crashed, so in general, it wouldn't be a reliable method. tom
At 2011/03/14 0:26 wrote:	good comments. cron is lame. the author of it is not to be trusted to code in the users' interests, anymore than the launchd authors. it's all about the $$$ they get from corporations who haven't the foggiest idea what makes for reliable software. i wrote a silly shell fucntion that takes a date or time period in any format, calculates the time to wait, sleeps then executes. simple. no daemon wakeup nonsense. can be combined with nohup. no resource competition issues like with at(1). then later i discovered paul jarc (code.dogmap.org) wrote something like this in c called runwhen. no one is perfect but djb and his followers have a much more solid approach to this stuff. to take another example, the init on my os has grown from 18 lines to 80+ lines of code since the bsdi days. these are very simple parts of the system that are have unnecesarily tweaked to the point of becoming a nusisance. but adding features helps sell software and support, so...
At 2011/03/14 9:03 wrote:	I certainly appreciate the idea of keeping things simple. But as Einstein said, "Make things as simple as possible, but not simpler." A program which sleeps for a while and then runs something is not cron. It is not even the "at" command. The scheduling won't survive a reboot. Unless of course you think that "reliable" is just an unnecessary tweak. And cron was written by different people over time, with the original version attributed to Brian Kernighan. I've never heard anyone say he's not to be trusted. tom