Rocco Scappatura wrote:
>>> It was probably filling up gradually and you didn't notice.
>>> Or there was a repeated failure, and you weren't monitoring the log.
>>>
>>>> 2) Is there a safe way to reloading amavisd-new?
>>> One way to do it is to:
>>> amavisd stop
>>> rm -rf /var/amavis/scan
>>> mkdir /var/amavis/scan
>>> chown vscan:vscan /var/amavis/scan
>>> amavisd start
>>>
>> I still have some trouble with reloading/restarting amavisd-new.
>> Basically, I have a cronjob to update amavisd-new:
>>
>> sa-update --gpgkey 6C6191E3 --channel sought.rules.yerp.org
>> --channel updates.spamassassin.org && /usr/sbin/rcamavisd reload
>>
>> where on reloading my startup script behaves as follow:
>>
>> reload)
>> echo -n "Reloading amavisd-new: "
>> ${prog} -c ${prog_config_file} reload
>> rc_status -v
>> ;;
>>
>> Doing so I have the problem that temporary RAM filesystem fills up
> from
>> time to time, and Postfix+Amavisd-new stops to work.
>>
>> On the contrary I could define cronjob as follow:
>>
>> sa-update --gpgkey 6C6191E3 --channel sought.rules.yerp.org
>> --channel updates.spamassassin.org && /usr/sbin/rcamavisd restart
>>
>> where on restarting my startup script behaves as follow:
>>
>> restart)
>> $0 stop
>> sleep 2
>> /usr/local/bin/delete_amavis_tmp.sh
>> rm -rf /var/amavis/scan/*
>> $0 start
>> ;;
>>
>> But doing so I have the problem of defferrals in postfix because it
>> could not connect to the amavisd socket:
>>
>> status=deferred (delivery temporarily suspended: connect to
>> 127.0.0.1[127.0.0.1]: Connection refused)
>>
>> So it is necessary that I reload postifix so that it could connect to
>> the new amavisd-new socket so that all continues to work.
>>
>> My question is: should I use reload or restart or is there a better
> way
>> to manage this situation? Moreover, could I avoid to reload postfix?
>> The
>> aim is clearly to make relaible the automatic job so that I could stay
>> quit wherever I'm out of office.
>
> Any news? Have someone experienced with similar issue?
>
> rocsca
>
You have a few choices for this...
- insure that your ram drive is big enough that it's unlikely
to fill up, else don't use a ram drive.
- do nothing. Postfix will start sending mail to amavis again
after a few minutes. It may be useful to adjust the
queue_run_delay, minimal_backoff_time and maximal_backoff_time
values, especially if you have postfix 2.3 or earlier.
# main.cf
queue_run_delay = 300s
minimal_backoff_time = 240s
maximal_backoff_time = 1000s
http://www.postfix.org/postconf.5.html#queue_run_delay
http://www.postfix.org/postconf.5.html#minimal_backoff_time
http://www.postfix.org/postconf.5.html#maximal_backoff_time
- For *occasional* use, run "postfix flush" to restart
delivery to all destinations. Flushing postfix is bad for
performance (but not as bad as "postfix reload") so shouldn't
be done on a regular basis.
- see the mitigation recipes at
http://www.postfix.org/QSHAPE_README.html#backlog
This works best with postfix 2.5 and newer.
--
Noel Jones
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
AMaViS-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/amavis-user
AMaViS-FAQ:http://www.amavis.org/amavis-faq.php3
AMaViS-HowTos:http://www.amavis.org/howto/
