[Clamav-users] Re: ClamAV return codes
Brian Bruns wrote: I'm sure this has probably been asked before, but I wasn't able to find it in the mailing list archives or the documentation - is there a list somewhere, either in the source code or in the docs, or on the web, which lists what each return code that clamscan gives back means? I've got someone asking about return code 128, and I've never seen it before. 128 means the program core-dumped. It's not a normal return code, those are documented at the end of man clamscan, it's a stopping/termination reason given by the OS. Just out of curiosity, in which OS are you seeing this? -- René Berber ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: ClamAV return codes
Brian Bruns wrote: Its Cygwin, so I'll have to diagnose this with my user, since I'm not seeing these problems on my end. That explains everything: Cygwin version 1.5.13-1 (the latest) changed the way it reports exit codes to Windows. Inside a Cygwin shell everything is normal (in your case the shell intercepts the 128 and shows a text message which is the usual way under Unix) but for Windows processes things changed, now exit codes are multiplied by 256 and core dumps or other problems are included in the exit code, which (at OS level) is composed of two parts, exit code:reason (that's two bytes, usually reason is 0 so exit code 1 is integer 256, and so on). I had to change cgFilterMessages (a CommunigatePro filter) when this Cygwin change started. If you use clamdwatch.pl under anything that is not a Cygwin shell you'll have to change the way exit codes are handled (actually you have to change clamdwatch.pl anyway since Cygwin's perl doesn't handle the line that sets the temporary file mod). -- René ___ http://lurker.clamav.net/list/clamav-users.html
[Clamav-users] Re: ClamAV return codes
Brian Bruns wrote: The issue with return codes in 1.5.13 was fixed in a 1.5.14 snapshot which is what this user is using. I know all about the return code issue, and was ready to fork the Cygwin source code to fix it if they didn't fix it themselves. With the latest snapshots, everything is returning the right codes again Strange, from Cygwin users' mail list it didn't seemed that anything was going to be changed on this issue. So, I still have the issue where I need to find out what is causing the dumps in ClamAV. Back to square one. I have noone else reporting this issue currently. I have the CommuniGate server running with a snapshot from back in January 29, sockets didn't work at all after that date (but that snapshot fixed the problem with all the port connections left open). On my development machine I have the 1.5.13 release with clamav-0.83 both compiled and downloaded from Cygwin, the socket problem was fixed in between. No problems at all with clamav (tested: clamd, freshclam, clamscan, and clamdscan) on both machines, and both use the dynamic library. The only way to see what is causing the core dump is running clamscan under gdb; a workaround is to install everything you need again. Latest cygwin snapshots are here if you need the latest DLL: http://www.cygwin.com/snapshots/ Those are too dangerous, I know, I've used snapshots and they fix something and usually break something else... well it's the same with the stable releases, not much testing is done. The fastest fix is usually to go back to an earlier version of whatever caused the problem (see the install log for a list of what has been changed lately). If you need a list of packages/versions that do work I can provide it. Regards. -- René Berber ___ http://lurker.clamav.net/list/clamav-users.html
