I believe the truncate works in the same fashion as the
utility provided by NetView. While it is possible that snmpCollect is writing
to a file that truncate is trying to trim, I find it hard to understand how it
would do that to the 7300+ files in the directory. One file I understand,
all files, I don't understand. I am not aware of the files being deleted at
all, but maybe that's how truncate works (deletes the old one and writes a new
one). The cron job does not stop/start snmpCollect.
Hm.... doesn't solaris have a limit of 8192 file handles
per process? Hm.......
Just how is the truncate being
done. Could there be a race condition?
You could have snmpCollect writing to a file that has
been deleted, while a file of the same
name is left visible for you to look at. If your truncate cron job
also restarts snmpCollect
then that
would explain the recovery the next day.
John
Gatrell.