Troubles when restarting amavis

nerbrume at free.fr nerbrume at free.fr
Wed Feb 14 09:15:42 CET 2018


Hello,

Small update on my troubles, as I encountered them again today. (While I 
didn't had time to "fix" the duplicate amavis service symlink in 
/run/systemd/generators.local)

- as expected, netstat doesn't saw anything listening on 10024 (test was 
done 4H after the restart failure).

- as explained before, systemd "see" two amavis services : 
amavisd-new.service and amavis.service. Both were in the "active 
(exited)" state after the crash. On issuing systemctl restart amavis, 
both are now "active (running)". Could it be that systemd, afterall, 
totally handles the symlink, seeing it as a mere "alias" ?

- I never saw two crashes in such a short time (only three days). 
However, since about a week, the machine is doing heavy video encoding, 
which harnesses most of the CPU power. This might be pointing to some 
kind of race condition.

Given the above, I guess I'm going to redo my config, and see where it 
leads.

N

Le 13/02/2018 09:32, nerbrume at free.fr a écrit :
> Hi,
> 
> Thanks for the pointers, my comments below.
> 
>> # netstat -tulpn | grep ":10024"
>> when this error occurs is most likely revealing that amavis is running
>> on this port. But still knowing is knowing, guessing is guessing.
> 
> You're right, I will check that next time. However, as I usually
> discover the issue hours later, I guess that whoever that is blocking
> 10024 will have terminated by then.
> 
>> Actually systemd is running a generator to interpret /etc/init.d/* and
>> dynamically creates .service files, which are executed. The generator
>> is somewhere at /lib/systemd/system-generators/systemd-sysv-generator
>> and it's results should be at /run/systemd/generator.late/* .
> 
> D'oh, of course.
> There is quite a lot going on in /run/systemd/generator.late/, here
> are the amavis files
>> ls -l /run/systemd/generator.late/amavis*
> /run/systemd/generator.late/amavisd-new.service -> amavis.service
> /run/systemd/generator.late/amavisd-snmp-subagent.service
> /run/systemd/generator.late/amavis-mc.service
> /run/systemd/generator.late/amavis.service
> /run/systemd/generator.late/amavis-snmp-subagent.service ->
> amavisd-snmp-subagent.service
> 
> amavis.service is the one launching /etc/init.d/amavisd-new, but the
> amavisd-new.service -> amavis.service softlink is VERY suspicious.
> This is confirmed by :
>> systemctl list-unit-files | grep amavis
> amavis-mc.service                                                      
> generated
> amavis-snmp-subagent.service                                           
> generated
> amavis.service                                                         
> generated
> amavisd-new.service                                                    
> generated
> amavisd-snmp-subagent.service                                          
> generated
> 
> So it would appear I have 2 amavis instances running, no wonder they
> eventually fight over the port. (the same goes for the snmp agent...)
> I'll try to disable one of them (time to fully understand how this
> auto-generation is exactly done, and why this softlink is created...),
> and report here, but probably in one month or two, given the rarity of
> the bug..
> 
>> Btw. you have an interesting configuration, as I thought amavisd is
>> it's own spamd daemon (using perl API) and therefore process spamd
>> isn't needed at all.
> 
> Indeed, now that you mention it, I thought that the only service
> launched should have been amavis (this is, after all, the only one
> speaking to postfix), with spamassassin being called/launched as
> needed.
> The original configuration was done on Debian 6, and migration might
> have gone awry (I'm looking at you, systemd).
> If aforementioned services cleanup does not work, I guess I'll redo my
> configuration from scratch.
> 
> Thanks for the help !
> 
> N


More information about the amavis-users mailing list