-- Lars Hecking <lhecking@...> is rumored to have mumbled =
on Samstag, 2. M=E4rz 2002 15:26 Uhr +0000 regarding Re: [AMaViS-user]=20
Problems with amavisd-snapshot-20020220:
thank you very much for your reply.
>> One is a problem with sophie that I've already reported to Vanja. For no
>> discernible reason sophie has crashed once with rather devastating
>> results: sendmail refuses to accept mail in that case. The logfile
> Which Sophie version?
> (Did Vanja reply? I sent him a patch a few months ago, but he never got
> back to me.)
Yes, he replied. I've provided him with a truss log, but that was just a=20
few hours ago. FYI, here's the crash:
Received signal #18, SIGCLD [caught]
siginfo: SIGCLD CLD_EXITED pid=3D8004 status=3D0x0000
waitid(P_ALL, 0, 0xFFBEEB88, WEXITED|WTRAPPED|WNOHANG) Err#10 ECHILD
sigprocmask(SIG_UNBLOCK, 0xFFBEF0F8, 0x00000000) =3D 0
Received signal #14, SIGALRM [default]
*** process killed ***
He has just released a 1.18 update with the following changes:
- RUNAS_USER added to sophie.h - Sophie can now run as user other
than root (default is 'mail' on Linux - check the file please).
NOTE: Make sure user the Sophie is running as does have read
privileges to directory and files which needs to be scanned.
Otherwise, you will get -1 response.
- setpriority() removed. It was not as useful as one would expect ;)
- eicar.com is now created from Makefile, instead of being bundled
in tarfile (Thanks to Lars Hecking for neat Makefile entry)
- Old SYSLOG_FACILITY defines changed to SYSLOG_LEVEL (to avoid
confusion). SYSLOG_FACILITY set to LOG_MAIL. Thanks to Klaus Muth
- Added support for 10 new configuration keywords/options, which
can be found in Engine 2.9
- SOPHIE_TIMEOUT (in sophie.c) increased from 30 to 90 (seconds)
Some people did have problems with Sophie (scanning) terminating
while scanning big attachments.
I'm not sure if any of this is relevant to the problem on hand.
>> My milter line in sendmail.cf looks like this:
>> Xmilter-amavis, S=3Dlocal:/var/amavis/amavis-milter.sock, F=3DT,
>> If I were to leave out the "F=3DT" part, would that in this instance =
>> the mail to go through unfiltered? What if amavisd or amavis-milter
> Yep. See my posting "milter and the F=3D equate" on Feb 6.
OK, that's what I thought, but I wasn't sure. I suppose that my superiors=20
would rather have virii go through than have users complain about "Please=20
try again later" messages, but I'll have to consult them.
>> Finally, during my tests with the inittab entry for sophie I have killed
>> sophie forcibly a few times. I'm not sure if that is the reason, but
>> there are quite a few directories in /var/amavis that contain mail that
>> has been there for longer than the actual scanning could account for.
>> Is it safe to say that this mail hasn't been delivered?
> Your mail logs are the final judge of that.
> Hhm, I thought that were are now catching all errors nicely, and we
> should never see leftover directories. Marc, I think the logic of
> introducing rmdir_flat() into do_exit() is flawed: once we get to
> do_exit(), we always and definitely want to delete the temp dir, with
> everything in it.
Well, the comments in the source indicate that this is mainly a safeguard=20
against inadvertently doing a rmdir_recursively() on / in case of=20
>> If this can happen so easily, wouldn't it be a good idea for amavis to
>> offer some kind of "queue runner"?
> I thought of this before, in relation to Rainer's smtp-input patch, but
> I think that this would make things significantly more complicated than
> they are now.
That's for sure. Maybe I can come up with something. It doesn't have to be=20
part of amavis proper...
Zentrum f=FCr angewandte Informatik - Universit=E4tsweiter Service
Cologne University -- Universit=E4t zu K=F6ln