Troubles when restarting amavis

nerbrume at free.fr nerbrume at free.fr
Tue Feb 13 09:32:20 CET 2018


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