Re: [svs-devel] possible file locking issue
Brought to you by:
renereucher
From: R. R. <ren...@ba...> - 2010-12-09 19:26:54
|
On Thursday 09 December 2010 06:18:15 pm Sebastien Caty wrote: > > Well, as you see, this is the problem with this deadlock: it happens > > so rarely > > (meanwhile) and unpredictably that it's extremely hard to reproduce. So > > I'm not sure what to look after... > > Yeah, I tried all sort of stupid things hopping to break SVS at some > point. Never did. So I kept it running on several not critical servers > and waited for it. > > Not obvious to understand what's going on. That's exactly the reason for my headache with this :)! > There shouldn't be more than one smbd alive for the same service at the same > time for the same user right? Well, there could theoretically be several connections, but in this case it's a result of the first hanging smbd process (8489) and a reconnect by the client. > 8489 is still running, well stuck on DIR > /envrn/migrt_unx/prodc/livrs-e/amlsourc/. Several others are now stuck > on the same DIR. Yeah, I know this... > No smoking gun in the logs so far.... Looks very similar to what I've seen. But, I see something else in your log which is strange.. the session ID doesn't change between the two processes: svs_clamav[8489]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: close: handle = 14633360, path = /envrn/migrt_unx/prodc/livrs-e/amlsourc/d25af1.aml, modified = no svs_clamav[8494]: D: connect: handle = 15925024, service = migrt_unx, user = warvi1, address = 10.103.100.157 They have the same session ID, but different handles and PIDs!? That shouldn't happen! I guess it's a Qt bug (and I already have a work-around in mind), however (and unfortunately), it doesn't look like the reason for the deadlock. Cheers. René -- René Reucher ren...@ba... http://www.batcom-it.net/ If anything can go wrong, it will. |