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.
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