nv-l

RE: [nv-l] Weird Poblem of the Week

2004-05-18 11:27:00
Subject: RE: [nv-l] Weird Poblem of the Week
From: "Barr, Scott" <Scott_Barr AT csgsystems DOT com>
To: <nv-l AT lists.us.ibm DOT com>
Date: Tue, 18 May 2004 10:16:54 -0500
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.......


From: owner-nv-l AT lists.us.ibm DOT com [mailto:owner-nv-l AT lists.us.ibm DOT com] On Behalf Of John M Gatrell
Sent: Tuesday, May 18, 2004 10:03 AM
To: nv-l AT lists.us.ibm DOT com
Subject: Re: [nv-l] Weird Poblem of the Week


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.
<Prev in Thread] Current Thread [Next in Thread>