From: ldg@ulysium.net
Date: Fri Jul 11 2003 - 12:12:56 EDT
I little follow up on this issue, which I haven't yet resolved:
One suggestion was that cron may have a limit in the number of arguments in
the command line, so I looked a little closer at the dirclean doc and found
I could shrink the effective length a bit by combining a few things like
this:
/usr/sbin/dirclean -t +2 -o -k scb /tmp/ >/dev/null 2>&1
I also tried shrinking it further by using only one redirection, trying with
1 and then 2, but neither stopped the email from coming in and the same
content was in the email, so it seems the redirection may not be working at
all.
One other suggestion was to use a wrapper script, but I'd rather avoid that
if I can. After all there are other such commands in the crontab and they're
not doing this, and I don't see why I should wrap just one of them..
The /tmp location on that system is on its own advfs domain, and has the
quota.xxx files, so dirclean chokes on those every time, which is what is
reported by email.
I would like to figure out a way to have dirclean avoid touching those
files, but I don't think it can be configured that way.
So how do I make cron behave in it's expected way?
My original positing is below:
> I've tried to suppress the output from a couple of cron jobs, for example
> like this one:
>
> 20 4 * * * /usr/sbin/dirclean -t +2 -o -k s c b /tmp/ >/dev/null 2>&1
>
> and that still doesn't stop it.
> This is tru64 5.1b and that used to work on older versions, what's changed
> and how can I do this right?
-- Didier Godefroy mailto:dg@ulysium.net
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:49:27 EDT