Thanks to Richard, Paul, and Jason (at HP). Workarounds suggested are to
redirect output from the cron job to /dev/null, grep the output to remove
these messages, or to touch the quota files to update them. Jason at HP
stated
Tom, this is a known issue being worked by HP Tru64 UNIX Development &
Engineering. A fix will appear in a future patch kit or OS version.
I will probably go with the workaround of filtering the output with grep
for now until dirclean is fixed.
Tom
=================================================================
Tom Ackenhusen tackenhu_at_fnal.gov
Business Systems Technical Services
Fermi National Accelerator Laboratory Batavia, IL, USA
Tom Ackenhusen
11/20/2002 01:23 PM
To: tru64-unix-managers_at_ornl.gov
cc:
Subject: dirclean cron job encountering errors with quota.group and quote.user
after 5.1A upgrade
We just upgraded one of our AlphaServers from 4.0F to 5.1A. Since the
upgrade, we receive nightly messages from a root cron job stating:
dirclean: Cannot unlink /tmp/quota.user: Permission denied
dirclean: Cannot unlink /tmp/quota.group: Permission denied
*************************************************
Cron: The previous message is the standard output
and standard error of the following crontab command:
/usr/sbin/dirclean -t +2 -o -k s /tmp/
This problem was introduced by the fact the 5.1A adds a new crontab entry
for root (actually, 4 entries using dirclean, but only one is causing this
problem) of the form:
20 4 * * * /usr/sbin/dirclean -t +2 -o -k s /tmp/
I believe a contributing factor to this problem is the fact we use a
dedicated filesystem for /tmp - so /tmp is the root of the filesystem and
therefore contains quota.user and quota.group files.
Short of either not having /tmp be the root of the filesystem, disabling
this cleanup cron job, or rewriting this cron entry to use find and rm or
some such, is there any way of getting "dirclean" to not mess with these
quota files? Would just touching the files (updating the timestamps and
thereby making them no longer meet the trimming criteria) work - I realize
this would have to be done a periodic basis.
Thanks,
Tom
=================================================================
Tom Ackenhusen tackenhu_at_fnal.gov
Business Systems Technical Services
Fermi National Accelerator Laboratory Batavia, IL, USA
Received on Wed Nov 20 2002 - 21:09:57 NZDT