Thread: [svs-devel] Bug ID #3115268
Brought to you by:
renereucher
From: R. R. <ren...@ba...> - 2010-11-22 14:59:21
|
Hi list! I've just committed a small (but important) change to SVN to allow for correct codec-handling when using non-ASCII characters in file names. See this tracker bug for details: https://sourceforge.net/tracker/?func=detail&aid=3115268&group_id=317999&atid=1337312 I'd like to release a new version soon as this bug is easily exploitable. So if you find the time, please test and let me know your results! Thanks, René -- René Reucher ren...@ba... http://www.batcom-it.net/ "You can write a small letter to Grandma in the filename." -- Forbes Burkowski, Computer Science 454 |
From: Sebastien C. <sc...@dc...> - 2010-11-23 17:52:03
|
Works for me > Hi list! > > I've just committed a small (but important) change to SVN to allow > for correct > codec-handling when using non-ASCII characters in file names. > > See this tracker bug for details: > https://sourceforge.net/tracker/?func=detail&aid=3115268&group_id=317999&atid=1337312 > > I'd like to release a new version soon as this bug is easily exploitable. So > if you find the time, please test and let me know your results! > > Thanks, René > -- > René Reucher > ren...@ba... > http://www.batcom-it.net/ > > "You can write a small letter to Grandma in the filename." > -- Forbes Burkowski, Computer Science 454 > > ------------------------------------------------------------------------------ > Beautiful is writing same markup. Internet Explorer 9 supports > standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3. > Spend less time writing and rewriting code and more time creating great > experiences on the web. Be a part of the beta today > http://p.sf.net/sfu/msIE9-sfdev2dev > _______________________________________________ > svs-devel mailing list > svs...@li... > https://lists.sourceforge.net/lists/listinfo/svs-devel > > |
From: R. R. <ren...@ba...> - 2010-11-23 18:14:03
|
On Tuesday 23 November 2010 06:51:55 pm Sebastien Caty wrote: > Works for me Thanks for testing, Sebastien! The bug-reporter also confirmed the fix is working for him. I'll likely release the new version on Thursday as I don't have enough time to do it now... Thanks, René -- René Reucher ren...@ba... http://www.batcom-it.net/ "If we were meant to fly, we wouldn't keep losing our luggage." |
From: Sebastien C. <sc...@dc...> - 2010-11-23 18:15:34
|
Hi, I've hit a problem on some servers that are under heavier samba use. I have no proof at all so far that SVS in causing this but I'm investigating. Since logging level was fairly low, I don't know how this happened but the end result is a directory gets locked. A user cannot open this directory (explorer freeze). The user close explorer and tries to open it again on the same directory. Each time a user does this on the locked directory, another smbd process is spawned and stalled in fnctl F_SETLKW. So it's waiting forever for a lock to be released. Only way to make it work again is to kill all stalled smbd process. This is the first time I've seen this happen since upgrading from samba 3.0 to samba 3.5.6 and SVS. I don't know how to reproduce this yet. Right now I have disabled SVS and waiting a week see if it happens again. If not, I'll enable SVS again but with more debug logging. I don't know why I end up with many machine connection for the same user. I've also enabled reset on zero VC to make samba close all previous process from the same IP. But even with the reset, I've seen samba get stuck with many smbd all waiting for a lock. Might be some wierd race condition/deadlock. |
From: R. R. <ren...@ba...> - 2010-11-23 18:27:59
|
Oh, hi again :)! On Tuesday 23 November 2010 07:15:27 pm Sebastien Caty wrote: > I've hit a problem on some servers that are under heavier samba use. I > have no proof at all so far that SVS in causing this but I'm > investigating. Since logging level was fairly low, I don't know how > this happened but the end result is a directory gets locked. A user > cannot open this directory (explorer freeze). The user close explorer > and tries to open it again on the same directory. Each time a user > does this on the locked directory, another smbd process is spawned and > stalled in fnctl F_SETLKW. So it's waiting forever for a lock to be > released. Only way to make it work again is to kill all stalled smbd > process. I've seen this before... but not since 0.1.1 was released. > This is the first time I've seen this happen since upgrading from > samba 3.0 to samba 3.5.6 and SVS. I don't know how to reproduce this > yet. Right now I have disabled SVS and waiting a week see if it > happens again. If not, I'll enable SVS again but with more debug > logging. No, it's probably really caused by SVS. Samba will just respawn a new session (and yet another new session)... which is why you may end up in a number of stalled SMBD processes. But that's hard to reproduce, I know... well, if it's still there, I have to try to find it. > I don't know why I end up with many machine connection for the same > user. You only have one active connection, but the SMBD processes hang. > I've also enabled reset on zero VC to make samba close all > previous process from the same IP. But even with the reset, I've seen > samba get stuck with many smbd all waiting for a lock. > > Might be some wierd race condition/deadlock. Yeah, most probably a deadlock. Give me time to study it... also, please let me know your svs.ini. I may not find the time for it this week, but I'll do it ASAP. Thanks, René -- René Reucher ren...@ba... http://www.batcom-it.net/ Health is merely the slowest possible rate at which one can die. |
From: Sebastien C. <sc...@dc...> - 2010-11-23 19:00:49
|
2 active CPU (others are disabled due to licensing limitation) [SVS] maxParallelScans=2 maxCachedResults=10000 statisticsLogInterval=60000 statisticsLogThreadUtil=true clamdscanCommand=clamdscan postScanSleep=100 infectAction=none quarantineDirectory=/tmp/viruses scanOnOpen=true scanOnClose=true turboMode=true maxScannerHeartbeatAge=0 maxQueuedRequests=32 waitPendingScans=true SLES9 : clamav-0.95.1-0.1 SLES10 : clamav-0.96.1-29.1 Some share are also available by NFS and I use kernel oplocks. It occured 3 times on 2 production server and once on a dev server. I can do some testing on the dev server. It's annoying but I can live with it there if it can help to reproduce the error. Sebastien > Oh, hi again :)! > > On Tuesday 23 November 2010 07:15:27 pm Sebastien Caty wrote: >> I've hit a problem on some servers that are under heavier samba use. I >> have no proof at all so far that SVS in causing this but I'm >> investigating. Since logging level was fairly low, I don't know how >> this happened but the end result is a directory gets locked. A user >> cannot open this directory (explorer freeze). The user close explorer >> and tries to open it again on the same directory. Each time a user >> does this on the locked directory, another smbd process is spawned and >> stalled in fnctl F_SETLKW. So it's waiting forever for a lock to be >> released. Only way to make it work again is to kill all stalled smbd >> process. > I've seen this before... but not since 0.1.1 was released. > >> This is the first time I've seen this happen since upgrading from >> samba 3.0 to samba 3.5.6 and SVS. I don't know how to reproduce this >> yet. Right now I have disabled SVS and waiting a week see if it >> happens again. If not, I'll enable SVS again but with more debug >> logging. > No, it's probably really caused by SVS. Samba will just respawn a new session > (and yet another new session)... which is why you may end up in a number of > stalled SMBD processes. > > But that's hard to reproduce, I know... well, if it's still there, I have to > try to find it. > >> I don't know why I end up with many machine connection for the same >> user. > You only have one active connection, but the SMBD processes hang. > >> I've also enabled reset on zero VC to make samba close all >> previous process from the same IP. But even with the reset, I've seen >> samba get stuck with many smbd all waiting for a lock. >> >> Might be some wierd race condition/deadlock. > Yeah, most probably a deadlock. Give me time to study it... also, please let > me know your svs.ini. > > I may not find the time for it this week, but I'll do it ASAP. > > Thanks, René > -- > René Reucher > ren...@ba... > http://www.batcom-it.net/ > > Health is merely the slowest possible rate at which one can die. > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > svs-devel mailing list > svs...@li... > https://lists.sourceforge.net/lists/listinfo/svs-devel > > |
From: Sebastien C. <sc...@dc...> - 2010-12-09 15:52:56
|
Hi Rene! Took a while but I've got a stalled/locked samba right now. Looking at the logs see if I can figure out how it happened. If there's some trace/info that could help let me know, I didn't kill samba yet. Sebastien > Oh, hi again :)! > > On Tuesday 23 November 2010 07:15:27 pm Sebastien Caty wrote: >> I've hit a problem on some servers that are under heavier samba use. I >> have no proof at all so far that SVS in causing this but I'm >> investigating. Since logging level was fairly low, I don't know how >> this happened but the end result is a directory gets locked. A user >> cannot open this directory (explorer freeze). The user close explorer >> and tries to open it again on the same directory. Each time a user >> does this on the locked directory, another smbd process is spawned and >> stalled in fnctl F_SETLKW. So it's waiting forever for a lock to be >> released. Only way to make it work again is to kill all stalled smbd >> process. > I've seen this before... but not since 0.1.1 was released. > >> This is the first time I've seen this happen since upgrading from >> samba 3.0 to samba 3.5.6 and SVS. I don't know how to reproduce this >> yet. Right now I have disabled SVS and waiting a week see if it >> happens again. If not, I'll enable SVS again but with more debug >> logging. > No, it's probably really caused by SVS. Samba will just respawn a new session > (and yet another new session)... which is why you may end up in a number of > stalled SMBD processes. > > But that's hard to reproduce, I know... well, if it's still there, I have to > try to find it. > >> I don't know why I end up with many machine connection for the same >> user. > You only have one active connection, but the SMBD processes hang. > >> I've also enabled reset on zero VC to make samba close all >> previous process from the same IP. But even with the reset, I've seen >> samba get stuck with many smbd all waiting for a lock. >> >> Might be some wierd race condition/deadlock. > Yeah, most probably a deadlock. Give me time to study it... also, please let > me know your svs.ini. > > I may not find the time for it this week, but I'll do it ASAP. > > Thanks, René > -- > René Reucher > ren...@ba... > http://www.batcom-it.net/ > > Health is merely the slowest possible rate at which one can die. > > ------------------------------------------------------------------------------ > Increase Visibility of Your 3D Game App & Earn a Chance To Win $500! > Tap into the largest installed PC base & get more eyes on your game by > optimizing for Intel(R) Graphics Technology. Get started today with the > Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. > http://p.sf.net/sfu/intelisp-dev2dev > _______________________________________________ > svs-devel mailing list > svs...@li... > https://lists.sourceforge.net/lists/listinfo/svs-devel > > |
From: R. R. <ren...@ba...> - 2010-12-09 16:16:52
|
On Thursday 09 December 2010 04:52:48 pm Sebastien Caty wrote: > Took a while but I've got a stalled/locked samba right now. Looking at > the logs see if I can figure out how it happened. If there's some > trace/info that could help let me know, I didn't kill samba yet. 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... I didn't yet find the time to (try to) reproduce it myself. Had a lot of work to do lately (at work & home), and worked on another project in the tiny spare time. Fortunately, my holiday begins in a week :). And I should also find some time for SVS at the next weekend, I suppose. Until then, if you find something useful, I'd greatly appreciate any input! It would be nice if we could fix it before Christmas... every good project needs its X-mas release! :-) Thanks, René -- René Reucher ren...@ba... http://www.batcom-it.net/ |
From: Sebastien C. <sc...@dc...> - 2010-12-09 17:18:24
|
> 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. This is what I gather so far : 9:07:35 : First access to a share from user A, smbd PID 8489 svs_clamav[8489]: D: connect: handle = 14633360, service = migrt_unx, user = warvi1, address = 10.103.100.157 svs_clamav[8489]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: I: starting session: service = migrt_unx, user = warvi1, client address = 10.103.100.157 svs_clamav[8489]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: open: handle = 14633360, path = /envrn/migrt_unx/prodc/livrs-e/amlsourc/d25af1.aml, modified = no svs_clamav[8489]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: thread manager: synchronous scan request: object enqueued for scanning: file = /envrn/migrt_unx/prodc/livrs-e/amlsourc/d25af1.aml svs_clamav[8489]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: thread manager: processing scan queue: queued requests = 1 svs_clamav[8489]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: thread manager: processing scan queue: assigning work to scanner 0: file = /envrn/migrt_unx/prodc/livrs-e/amlsourc/d25af1.aml svs_clamav[8489]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: scanner thread 0: starting virus scan: file = /envrn/migrt_unx/prodc/livrs-e/amlsourc/d25af1.aml svs_clamav[8489]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: thread manager: processing scan queue: no queued requests svs_clamav[8489]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: scanner thread 0: finished virus scan: file = /envrn/migrt_unx/prodc/livrs-e/amlsourc/d25af1.aml, result = 0 (clean) svs_clamav[8489]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: thread manager: synchronous scan request: object contained in result cache: file = /envrn/migrt_unx/prodc/livrs-e/amlsourc/d25af1.aml, result = clean svs_clamav[8489]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: close: handle = 14633360, path = /envrn/migrt_unx/prodc/livrs-e/amlsourc/d25af1.aml, modified = no Immediatly after the handle close, another service is created. Same user, same share : svs_clamav[8494]: D: connect: handle = 15925024, service = migrt_unx, user = warvi1, address = 10.103.100.157 svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: I: starting session: service = migrt_unx, user = warvi1, client address = 10.103.100.157 svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: open: handle = 15925024, path = /envrn/migrt_unx/prodc/livrs-e/amlsourc/menrorgn.aml, modified = no svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: thread manager: synchronous scan request: object enqueued for scanning: file = /envrn/migrt_unx/prodc/livrs-e/amlsourc/menrorgn.aml svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: thread manager: processing scan queue: queued requests = 1 svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: thread manager: processing scan queue: assigning work to scanner 0: file = /envrn/migrt_unx/prodc/livrs-e/amlsourc/menrorgn.aml svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: scanner thread 0: starting virus scan: file = /envrn/migrt_unx/prodc/livrs-e/amlsourc/menrorgn.aml svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: scanner thread 0: finished virus scan: file = /envrn/migrt_unx/prodc/livrs-e/amlsourc/menrorgn.aml, result = 0 (clean) svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: thread manager: synchronous scan request: object contained in result cache: file = /envrn/migrt_unx/prodc/livrs-e/amlsourc/menrorgn.aml, result = clean svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: close: handle = 15925024, path = /envrn/migrt_unx/prodc/livrs-e/amlsourc/menrorgn.aml, modified = no svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: D: disconnect: handle = 15925024 svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: I: session statistics: scanned objects = 1 (clean = 1, infected = 0, failed scans = 0), cache hit ratio = 1.0, cache fill level = 0.0% svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: I: session statistics: thread activations = 1 (t[0] = 100.0%, t[1] = 0.0%) svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: I: monitoring thread: ended svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: I: scanner thread 0: ended svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: I: scanner thread 1: ended svs_clamav[8494]: {9a2acd23-c85c-4113-9c4c-194d8699fadc}: I: session ended This one does disconnect and is never seen again. But smbd 8489 is always there, getting request. Other new services, like 8494 show up at the same time. There shouldn't be more than one smbd alive for the same service at the same time for the same user right? It's just a matter of time before a deadlock occurs. Which it does a bit later. 8489 is still running, well stuck on DIR /envrn/migrt_unx/prodc/livrs-e/amlsourc/. Several others are now stuck on the same DIR. No smoking gun in the logs so far.... |
From: Sebastien C. <sc...@dc...> - 2010-12-09 17:28:45
|
I was wondering, could waitPendingScans cause this? |
From: R. R. <ren...@ba...> - 2010-12-09 19:07:24
|
On Thursday 09 December 2010 06:28:37 pm Sebastien Caty wrote: > I was wondering, could waitPendingScans cause this? No. It was added later and has nothing to do with it... I've seen this with and without waitPendingScans. However, you can disable it, of course (I do not recommend it, though). The multiple starts of smbd processes is something that Samba does on its own. You can't stop it from doing so, because the client is actually the one that's issuing reconnects over and over again (unless you stop it)... So, whatever might be causing it particularly, when Samba detects a "hanging" connection, it leaves a "looping" SVS (smbd) process "hanging around" (the process uses some CPU). All subsequently started SVS / smbd connections will then be "locked". I'm pretty sure it's something in my code that's initially causing it (a deadlock in the first process the rest is just a follow-up), but it's most likely (well, I'd prefer to say definitely) not the waitPendingScans-feature :)! Thanks, René -- René Reucher ren...@ba... http://www.batcom-it.net/ BLISS is ignorance |
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. |
From: R. R. <ren...@ba...> - 2010-12-09 19:54:58
|
On Thursday 09 December 2010 08:26:21 pm R. Reucher wrote: > 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)... FYI: I've committed a small change to SVN which (I hope) should fix this... but I've never seen this on my test system before, so I'm not absolutely sure. I'm now initializing the random generator's seed with the current time when the session starts. That SHOULD make QUuid::createUuid() generate unique IDs in all cases. The documentation says that there's a VERY small chance to get the same UUID twice, but I think it depends on the random generator in the background. Have fun, René -- René Reucher ren...@ba... http://www.batcom-it.net/ Confidence is the feeling you have before you understand the situation. |
From: Sebastien C. <sc...@dc...> - 2010-12-09 20:53:50
|
>> 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. The more I read on SMB the more my head hurts. Different behavior depending on what windows version is running. Anyway, yeah having several connection from the same client is possible and not a bug. To help with some problem I did have (smbd hanging around to long) I have enabled reset on zero VC. It closes all connection from the same IP when VC=0, but it seems not all connection from XP are VC=0. Unfortunatly, if there is a deadlock it will not shutdown the process so it doesn't help for this. Since killing all deadlocked smbd I have this that came back : Dec 9 13:56:53 l500aplicdl01 svs_clamav[16019]: {266a4b5c-365a-4e92-aacb-3ea6db5ba124}: I: starting session: service = migrt_unx, user = warvi1, client address = 10.103.100.157 Dec 9 13:56:53 l500aplicdl01 svs_clamav[16024]: {266a4b5c-365a-4e92-aacb-3ea6db5ba124}: I: starting session: service = migrt_unx, user = warvi1, client address = 10.103.100.157 Both are running fine at the moment. No other smbd for this user. > 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. Never saw that, guess I'm staring at the screen too hard :P BTW, this is on SLES9. QT 4.5.3 |
From: R. R. <ren...@ba...> - 2010-12-10 16:28:37
|
On Thursday 09 December 2010 09:53:43 pm Sebastien Caty wrote: > The more I read on SMB the more my head hurts. Different behavior > depending on what windows version is running. Not only that... the VFS interface changes very often (nearly on every minor release). Too often if you ask me. I would understand if they did minor changes every now and then, and major ones on every major Samba release (2.x.x vs. 3.x.x vs. 4.x.x)... but that's the way it is :)! Also, the VFS API documentation is completely outdated and unclear -- you have to find things out yourself in major parts. Well, at least there are some VFS examples (which are up-to-date). > Anyway, yeah having several connection from the same client is possible and > not a bug. Correct. > To help with some problem I did have (smbd hanging around to long) I have > enabled reset on zero VC. It closes all connection from the same IP > when VC=0, but it seems not all connection from XP are VC=0. > Unfortunatly, if there is a deadlock it will not shutdown the process > so it doesn't help for this. And it's no solution anyway... but there's hope! I may have found the reason for the deadlocks. I'm currently testing it with a pattern that did hang in the past (Qt 4.7.1 build tree)... and I'm really pushing it hard :). If I'm not completely wrong, the deadlock only occurs on reads (opens), and there's actually some code in my sync-scan routine that could potentially cause a deadlock by re-requesting synchronous scans (too often). Since the monitoring thread already takes care for pending scan requests and re- initiates them on demand, there's no need to do the same in SVSThreadManager::syncScan() anyway. So I've removed that code and made the monitoring-thread check more often (100 times a second, it was 10 times before). This produces just a very small overhead while at the same time being a bit faster than before (from a user's / application's perspective). And... at least for me up until now... it seems to also avoid the deadlock. This is the corresponding change-log entry (SVN rev. 87): - imp: sync-cans no longer process the request queue themselves, they only put a scan request on the queue and let the monitoring thread take care of it (this should also fix the rare deadlocks which were seen by some users) Fingers crossed :)! Session UUID: > Never saw that, guess I'm staring at the screen too hard :P Hehe! It's not really important for now because I only use it to distinguish between log-output from different sessions (just 'grep' the session ID in /var/log/messages), but it will be required to be unique for other features later, so I need to make sure it really works as expected. Would be nice if you could keep an eye on it as well! > BTW, this is on SLES9. QT 4.5.3 My setup: openSUSE 11.3 (x86_64), Qt 4.6.3, ClamAV 0.96.5, Samba 3.4 BTW, please post (more) complete logs next time if possible... something like this would be nice (output attached to the mail): # grep <session-ID> /var/log/messages | bzip2 > session.log.bz2 Thanks! Have fun, René -- René Reucher ren...@ba... http://www.batcom-it.net/ Anything is good and useful if it's made of chocolate. |
From: R. R. <ren...@ba...> - 2010-12-10 18:08:18
|
Update: all my tests with the latest code went fine so far. About 100000 scans (50% read / 50% write). Quite a number of the files were large archives (ZIPs, RARs, tgz's and tbz's), which really stressed clamd hard, but it remained stable and did not lock! I guess I can't do much more to challenge it :)... but I'll do some more tests at the weekend. Have fun, René -- René Reucher ren...@ba... http://www.batcom-it.net/ |
From: Sebastien C. <sc...@dc...> - 2010-12-10 19:57:53
|
> This is the corresponding change-log entry (SVN rev. 87): > > - imp: sync-cans no longer process the request queue themselves, they only > put a scan request on the queue and let the monitoring thread take care of > it (this should also fix the rare deadlocks which were seen by some users) Great, I'm going to push this latest version on a bunch of servers and have a good look. > Fingers crossed :)! Indeed! > My setup: openSUSE 11.3 (x86_64), Qt 4.6.3, ClamAV 0.96.5, Samba 3.4 SLES9 SP3, QT 4.5.3, ClamAV 0.95.3, Samba 3.5.6 SLES10 SP2, QT 4.7.1, ClamAV 0.96.5, Samba 3.5.6 Also Tru64 5.1B-5, Samba 3.5.6 but there's no QT and ClamAV....well I never tried. I'm already lucky enough that samba can still be compiled. > BTW, please post (more) complete logs next time if possible... something > like this would be nice (output attached to the mail): > > # grep <session-ID> /var/log/messages | bzip2 > session.log.bz2 Sure, no problem. I also have samba logging at level 3 > > Thanks! I owe you a nice beer! Sebastien |
From: René R. <ren...@ba...> - 2010-12-10 22:50:45
|
Am 10.12.2010 20:58, schrieb Sebastien Caty: > Also Tru64 5.1B-5, Samba 3.5.6 but there's no QT and ClamAV....well I > never tried. I'm already lucky enough that samba can still be compiled. Hmmm, you only need the QtCore and QtTest modules... and Qt includes a tru64-cxx mkspec, so there's a chance at least :)! Cheers, René |
From: Sebastien C. <sc...@dc...> - 2010-12-14 15:32:23
|
> It's not really important for now because I only use it to > distinguish between > log-output from different sessions (just 'grep' the session ID in > /var/log/messages), but it will be required to be unique for other features > later, so I need to make sure it really works as expected. Would be nice if > you could keep an eye on it as well! Looks good now. I have a few users with 2 smbd process. Both process used to have the same SVS ID, now they don't. |
From: R. R. <ren...@ba...> - 2010-12-14 16:01:15
|
On Tuesday 14 December 2010 04:32:15 pm Sebastien Caty wrote: > > It's not really important for now because I only use it to > > distinguish between > > log-output from different sessions (just 'grep' the session ID in > > /var/log/messages), but it will be required to be unique for other > > features later, so I need to make sure it really works as expected. Would > > be nice if you could keep an eye on it as well! > > Looks good now. I have a few users with 2 smbd process. Both process > used to have the same SVS ID, now they don't. Thanks for having a look at it... yeah, the reason probably is that the system where this happened has no /dev/urandom (right?), and in this case, QUuid::createUuid() falls back to using the pseudo random generator (no real entropy, so it produces the same sequence of "random" numbers if unseeded)... the simple work around is to set the random seed to the current time. There's still a very small potential that the same numbers are reproduced for a later session, but not within a "normal" time frame... Have fun, René -- René Reucher ren...@ba... http://www.batcom-it.net/ Cahn's Axiom: When all else fails, read the instructions. |
From: Sebastien C. <sc...@dc...> - 2010-12-14 16:10:32
|
> Thanks for having a look at it... yeah, the reason probably is that > the system > where this happened has no /dev/urandom (right?) Nope, they all have /dev/urandom and working. |
From: R. R. <ren...@ba...> - 2010-12-14 16:14:27
|
On Tuesday 14 December 2010 05:10:26 pm Sebastien Caty wrote: > > Thanks for having a look at it... yeah, the reason probably is that > > the system > > where this happened has no /dev/urandom (right?) > > Nope, they all have /dev/urandom and working. Hmmm... OK. Well, I was refering to this statement from the Qt documentation: QUuid QUuid::createUuid() On any platform other than Windows, this function returns a new UUID with variant QUuid::DCE and version QUuid::Random. If the /dev/urandom device exists, then the numbers used to construct the UUID will be of cryptographic quality, which will make the UUID unique. Otherwise, the numbers of the UUID will be obtained from the local pseudo-random number generator (qrand(), which is seeded by qsrand()) which is usually not of cryptograhic quality, which means that the UUID can't be guaranteed to be unique. http://doc.qt.nokia.com/4.7/quuid.html#createUuid Cheers, René -- René Reucher ren...@ba... http://www.batcom-it.net/ |
From: R. R. <ren...@ba...> - 2010-12-14 16:20:51
|
On Tuesday 14 December 2010 05:13:43 pm R. Reucher wrote: > Well, I was refering to this statement from the Qt documentation: > > QUuid QUuid::createUuid() > On any platform other than Windows, this function returns a new UUID with > variant QUuid::DCE and version QUuid::Random. If the /dev/urandom device > exists, then the numbers used to construct the UUID will be of > cryptographic quality, which will make the UUID unique. Otherwise, the > numbers of the UUID will be obtained from the local pseudo-random number > generator (qrand(), which is seeded by qsrand()) which is usually not of > cryptograhic quality, which means that the UUID can't be guaranteed to be > unique. > http://doc.qt.nokia.com/4.7/quuid.html#createUuid Oh, the Qt 4.3 - 4.6 docs say just this about it: Returns a new UUID of DCE variant, and Random type. The UUIDs generated are based on the platform specific pseudo-random generator, which is usually not a cryptographic-quality random number generator. Therefore, a UUID is not guaranteed to be unique cross application instances. http://doc.qt.nokia.com/4.3/quuid.html#createUuid So, /dev/urandom support was added in Qt 4.7. Every earlier version uses only the pseudo-random number generator. Cheers, René -- René Reucher ren...@ba... http://www.batcom-it.net/ Money is the root of all wealth. |
From: Sebastien C. <sc...@dc...> - 2010-12-14 16:28:13
|
> Oh, the Qt 4.3 - 4.6 docs say just this about it: > > Returns a new UUID of DCE variant, and Random type. The UUIDs generated are > based on the platform specific pseudo-random generator, which is > usually not a > cryptographic-quality random number generator. Therefore, a UUID is not > guaranteed to be unique cross application instances. Ahhhhh and I'm using QT 4.5.3 on SLES9 where this happened. |
From: R. R. <ren...@ba...> - 2010-12-14 17:36:46
|
On Tuesday 14 December 2010 05:28:06 pm Sebastien Caty wrote: > > Oh, the Qt 4.3 - 4.6 docs say just this about it: > > > > Returns a new UUID of DCE variant, and Random type. The UUIDs generated > > are based on the platform specific pseudo-random generator, which is > > usually not a > > cryptographic-quality random number generator. Therefore, a UUID is not > > guaranteed to be unique cross application instances. > > Ahhhhh and I'm using QT 4.5.3 on SLES9 where this happened. Yeah, that explains it at least. The work around should be fine, though. BTW, and back on the topic... I've had no more hangs whatsoever since that related change from last Friday. And I meanwhile did a great number of additional tests... so I'm quite confident now that it's finally clean! Cheers, René -- René Reucher ren...@ba... http://www.batcom-it.net/ Someone will try to honk your nose today. |