the client does a stat,
then a clean open, so that shouldn't be the issue.
i'll try doug's suggest of a fclose and fsync.

On Jan 14, 2012, at 8:59 PM, John Stoffel wrote:

>>>>>> "Andrew" == Andrew Hume <[email protected]> writes:
> 
> Andrew> no doubt this is old hat, but this is the first its bitten me.
> 
> Andrew> i have a process that rewrites a file periodically. other
> Andrew> programs periodically check that file to see if its changed,
> Andrew> and if so, reread the file.  the actual method is (within a C
> Andrew> program, with liberties)
> 
> Andrew>       fopen("file!", "w")
> Andrew>       write stuff
> Andrew>       fclose()
> Andrew>       system("mv file! file")
> 
> Andrew> this works nearly all the time, except now (just as we go into
> Andrew> production), i am getting alot of "Stale NFS file handle"
> Andrew> errors when the other processes attempt to reread the
> Andrew> file. using google, one finds this commonly occurs when the
> Andrew> file is, amongst other things, renamed (which is what the mv
> Andrew> does).
> 
> Andrew> all this is running on wretched linux (RHEL6), so i am about
> Andrew> to abandon all hope.  but maybe someone can offer another way
> Andrew> to publish a file. maybe there is some NFS-specific dance that
> Andrew> is supposed to work.
> 
> Let me guess, your client programs do something like this:
> 
>    fd = open(file,O_RDONLY);
>    last = 0
>    while (1) {
>        fstat(fd,&status);  
>        if (status->mtime > last) {
>           last = status->mtime;
>           lseek(fd, 0, SEEK_SET);
>           read_into_memory(fd);
>           kick_some_thread();
>        }
>        sleep(15);
>    }
> 
> And I bet the problem is that the file referenced by the fd has gone
> away, due to your 'mv' above.  I think you need to close and then
> re-open the file PATH, and see how that works for you.
> 
> But hey, you don't show us how your client code works.  
> 
> John


------------------
Andrew Hume  (best -> Telework) +1 623-551-2845
[email protected]  (Work) +1 973-236-2014
AT&T Labs - Research; member of USENIX and LOPSA




_______________________________________________
Tech mailing list
[email protected]
https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech
This list provided by the League of Professional System Administrators
 http://lopsa.org/

Reply via email to