[ic] clustering with nfs - file locking problems with fcntl
db at kavod.com
Tue Nov 4 18:34:27 EST 2003
* Joshua Rusch <josh at strongwords.org> [2003-11-04 17:00]:
> Has there ever been a permanent solution to errors such as this:
> fnet /fnet/ord/checkout_login.html Runtime error: Could not fcntl_lock file:
> Interrupted system call
> when using Perl 5.8.1?
> Our perl was built from scratch with no threads.
> We're on RedHat 9
> One suggestion I've found is to hack the locking function to loop a few
> times before giving up.
> This is going to be a busy site, and we don't want to implement this
> particular hack. We were still able to get the error with only 4 of us
> trying to click around the site after experimenting with a few loops.
> The only other possible solution I've found was to downgrade to perl 5.6.1
> (but this was back when 5.8.0 was current)
> Is this the only way?
> Any help would be greatly appreciated. I'm still trying to get the site I've
> been working on launched, and this is the only thing holding us back at this
> point. We've already moved sessions over to mysql (thanks dan browning for
> having that page up with the instructions for that), and it didn't reduce
> the errors we've been getting.
> We're using 4.9.8 with SessionFile.pm patched to fix the incorrect
> fcntl_lock and fcntl_unlock lines.
One thing that might help debugging is to find out what file it's trying to lock
(is it a counter, or a different temporary file?).
Someone else identified some locking issues with the Counter module, so if that
is where you are having trouble, then that module probably needs some work.
Aside from all that, are you sure that you really need to share the files
via NFS? A much faster clustering model is one that doesn't require shared
sessions or temp space.
One easy way to do this is to enable persistence in your load balancer. If it
has Level-7 persistence, then you are done; if it is only IP-level, then you may
need to account for proxies.
All the trouble you are going through is only for a totally brain-dead
load-balancer (which does have it's benefits, despite my name-calling).
If you need additional assistance, please contact me off-list.
Dan Browning, Kavod Technologies, <db at kavod.com> 360.843.4074x217
6700 NE 162nd Ave, Ste 611-210, Vancouver, WA. Random Fortune:
There is no time like the present for postponing what you ought to be doing.
More information about the interchange-users