Le Lundi 12 Ao�t 2002 17:39, Mike Gerdts a �crit : > On Mon, 2002-08-12 at 10:54, David Collier-Brown wrote: > > Fredrik Ohrn wrote: > > > OK, I'll try 30 instead of the default 300. But I don't expect it to > > > help, in this case it seems that it's the smbd process that blows up, > > > not the client. > > > > Ok, I was afraid of that! > > > > Blown SMBDs are Bad Things (:-)) > > I have run into this same problem from time to time with 2.2.2. I was > hoping that the upgrade to 2.2.5 that I did yesterday would fix it... > > On the surface, it appears as though a panic action program that does > lock scrubbing would be useful. I envision a standalone program that > takes a filename and pid as an argument. If it encouters a lock > belonging to the given pid, it removes the lock from the database. > > Perhaps if the program is given only one argument (the lock file) it > traverses the tdb checking to see if each pid mentioned is alive. > > What would this break? > > Mike
I thought that this was already done internally at start of the new smbd for a client ? It scans the locking.tdb to get rid of old locks. I still think the code that deals with theses locks is to be reviewed deeply. As I showed in a post concerning fifo files, it appears locks are not always handled at the correct moment... Pascal
