Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 30 Jun 2005 13:49:52 -0700
From:      Peter Wemm <peter@wemm.org>
To:        Francisco Reyes <lists@natserv.com>
Cc:        freebsd-amd64@freebsd.org
Subject:   Re: Crontab behavior in AMD64
Message-ID:  <200506301349.52913.peter@wemm.org>
In-Reply-To: <20050630154904.I65748@zoraida.natserv.net>
References:  <20050630114041.W64452@zoraida.natserv.net> <200506301034.38233.peter@wemm.org> <20050630154904.I65748@zoraida.natserv.net>

next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday 30 June 2005 12:51 pm, Francisco Reyes wrote:
> On Thu, 30 Jun 2005, Peter Wemm wrote:
> > I'm afraid its something else.  I do a lot of cron work on various
> > amd64 boxes and there's no differences compared to i386.
>
> Great for the info. At least is one less variable to consider.
>
> > So I'm afraid you're going to need to do a bit of detective work. 
> > You might also check /var/log/cron
>
> Just did.
> Lots of other entries/errors that I need to check, but the one
> related to the program I am trying to get run
>
> Jun 30 10:23:00 server05 /usr/sbin/cron[38466]: (hank) CMD
>    (/usr/home/hank/bin/tozoraida.sh)
> Jun 30 11:05:33 server05 crontab[38566]: (hank) LIST (hank)
> Jun 30 11:11:21 server05 crontab[38595]: (hank) BEGIN EDIT (hank)
> Jun 30 11:11:27 server05 crontab[38595]: (hank) END EDIT (hank)
> Jun 30 13:23:00 server05 /usr/sbin/cron[38869]: (hank) CMD
>   (/usr/home/hank/bin/tozoraida.sh)
>
>
> The program seems like it was called from cron.

Silly idea. put 'date >> /tmp/tozoraida.log' at the start of your script 
and make sure that it actually kicked off.

> Next, going to see if it's something related to Postfix..
> Although it would be pretty bad if a crontab would fail because of a
> call to the local smtp.

It shouldn't be anything inherently due to postfix, because that's what 
I use on most of my amd64 boxes.  Of course, something could have been 
messed up somehow.

The only thing I wonder is if perhaps there is a file descriptor leak or 
resource problem?

You could also try this from right before the script is due to run:

sysctl kern.ktrace.request_pool=16384
sysctl kern.ktrace.genio_size=128
ktrace -f /tmp/cron.trace -i -p 38869

and then you can use kdump -f /tmp/cron.trace and look for clues.
The output will be big though.  kdump can be told to look for particular 
processes in the combined trace file if that helps.

Be sure to run 'ktrace -C' to turn off any child processes that 
inherited trace mode or you'll run out of disk space very quickly.

Anyway, you should see exactly what error conditions lead to the 
problem.
-- 
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200506301349.52913.peter>