OSX specific crontab problems
Geico Caveman
I have two jobs listed in my crontab. Both these jobs run without a
hitch when executed by hand on Terminal (please keep that in mind when
you read what is written below). I am using the full paths of the
commands (so duplicity is /opt/local/bin/duplicity).
Both jobs are bash scripts executed by the same user.
Job 1 gets executed properly on the specified time and leaves an error
message (see below).
Job 2 aborts with some errors, and leaves the same following error in
/var/log/system.log:
Dec 10 11:47:00 vortex com.apple.launchd[1] (0x10d130.cron[1325]):
Could not setup Mach task special port 9: (os/kern) no access
The corresponding cron entry is syntactically correct (which is why its
even leaving this message).
What do you think is missing ?
Not that it probably matters, but identical scripts (with somewhat
different paths as arguments defined as variables) run without problem
on my linux boxes (by hand and by crontab).
On OSX, the problematic one runs fine by hand and chokes when in crontab.
With regards.
Jolly Roger
Geico Caveman <spammers...@spam.invalid> wrote:
> Hello
>
> I have two jobs listed in my crontab. Both these jobs run without a
> hitch when executed by hand on Terminal (please keep that in mind when
> you read what is written below). I am using the full paths of the
> commands (so duplicity is /opt/local/bin/duplicity).
>
> Both jobs are bash scripts executed by the same user.
>
> Job 1 gets executed properly on the specified time and leaves an error
> message (see below).
>
> Job 2 aborts with some errors, and leaves the same following error in
> /var/log/system.log:
>
> Dec 10 11:47:00 vortex com.apple.launchd[1] (0x10d130.cron[1325]):
> Could not setup Mach task special port 9: (os/kern) no access
That's a message that has been with us for ages. It isn't an indication
that anything is wrong though, and should be ignored.
> The corresponding cron entry is syntactically correct (which is why its
> even leaving this message).
>
> What do you think is missing ?
>
> Not that it probably matters, but identical scripts (with somewhat
> different paths as arguments defined as variables) run without problem
> on my linux boxes (by hand and by crontab).
>
> On OSX, the problematic one runs fine by hand and chokes when in crontab.
What error message do you see when Job 2 aborts?
--
Send responses to the relevant news group rather than email to me.
E-mail sent to this address may be devoured by my very hungry SPAM
filter. Due to Google's refusal to prevent spammers from posting
messages through their servers, I often ignore posts from Google
Groups. Use a real news client if you want me to see your posts.
JR
Bob Harris
Geico Caveman <spammers...@spam.invalid> wrote:
I would suggest running a cron job that contains the following
commands
date >/tmp/tmp.cron
id >>/tmp/tmp.cron
printenv >>/tmp/tmp.cron
This should tell you what your environment looks like, and if you
compare this to your interactive environment, this might indicate
what your cron jobs are missing.
Warren Oates
Bob Harris <nospam....@remove.Smith-Harris.us> wrote:
>
> I would suggest running a cron job that contains the following
> commands
>
> date >/tmp/tmp.cron
> id >>/tmp/tmp.cron
> printenv >>/tmp/tmp.cron
>
> This should tell you what your environment looks like, and if you
> compare this to your interactive environment, this might indicate
> what your cron jobs are missing.
Cron needs to be told who it's working for. My jobs read in my .bashrc:
/Users/warren/.bash_profile && warren_home.sh
Reads in my environment and runs a script that backs up my home
directory (every 6 hours at 10 past the hour (not displayed)).
--
Very old woody beets will never cook tender.
-- Fannie Farmer