Newsgroup: it.comp.os.linux.sys
Titolo: lentezza avvio postfix

Torno sulla straordinaria velocit� del mio server mail..
Stamani vado in sala per cambiare un controller. Spengo l'mx (server 
virtuale ma era staccata la parte HA), faccio la modifica e riavvio.
Dall'avvio del server alla partenza di postfix passano svariati minuti 
(postfix 2.8.2):
Aug 22 08:43:41 mx milter-clamc[1999]: interface-name=
mx.tosnet.it
 
interface-ip=91.102.48.7
Aug 22 08:55:29 mx postfix/postfix-script[4663]: starting the Postfix mail 
system
 
12 minuti in cui il server stava eseguendo i controlli per il postfix start..
la coda era di una 50a di email quindi non pu� essere quello.
 
Un altro server con configurazione simile (utenti reali e non del db), 
appoggiato sullo stesso host � partito dopo 2 minuti dal boot dell'intero 
sistema, quindi ci ha messo sicuramente meno.
 
Cosa fa alla partenza postfix per fargli perdere tutto questo tempo?
 
 
 
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
 
www.robyt.eu
 
 

 12 minuti in cui il server stava eseguendo i controlli per il postfix start..
 
dns?
 


No, il dns � stato il primo che ho fatto riparirte e comunque il secondario 
era su.
 
Ho provato adesso a fare uno stop/start e ci ha messo 21 secondi.
Sembra quasi una lentezza della san (quando rallenta ci sono molti processi 
marcati D e load sale parecchio) ma � a comune con altri server (sempre 
virtuali e sullo stesso host) e quelli van bene.


 la coda era di una 50a di email quindi non può essere quello.
 
Come fai a dire che è colpa di postfix ?
 
Se (e solo se) il milter non lo fa partire postfix, in mezzo ci può stare 
altra roba che parte, o no ?
 


perché milter parte al volo (e viene usato da un altro server senza 
problemi), è il postfix start che si ferma.
Un top mi fa vedere il comando di check in stato D


 Un top mi fa vedere il comando di check in stato D
 
Non ne ho idea, sinceramente.
 
Ma io procederei così:
1) se hai aggiornato postfix da una versione obsoleta, controlla il 
master.cf
: magari hai dimenticato qualcosa
 
2) se hai cambiato il controller, "controlla" se per caso non ci fosse 
una ricostruzione del raid in corso. 12 minuti sono tantini ma se hai i 
dischi carichi, tutto può succedere. 
Soprattutto se al boot hai quei nuovi sistemi per fare lo start parallelo 
dei demoni.
 
Max

 Max


 dns?
 
Rilancio: hai qualcosa relativo a Avahi installato? A me una cosa del genere 
capita quando cambio il nome ad una macchina ed ho 'sta merda installata
 
Enrico


c'� avahi (la centos lo installa..) e se lo tolgo mi toglie per dipendenza 
un tal systemtap: mai coverto


 12 minuti in cui il server stava eseguendo i controlli per il postfix start..
 
ma scusa, possibile che nei log (info warn e err) non ci sia nulla? In 
genere in questi casi i log sono molto prolissi.

 wrote:

Niente di niente.
la sequenza di start è
clamd
milter vari
dovecot
postfix
 
I primi partono tranquilli, postfix ci ha messo quel tempo li
Aug 22 08:43:44 mx milter-limit[2008]: LibSnert/1.73.17 Copyright 1996, 2010 
by Anthony Howe. All rights reserved.
Aug 22 08:43:44 mx milter-limit[2008]: libmilter version 2 (4)
Aug 22 08:43:44 mx milter-limit[2008]: Sleepycat Software: Berkeley DB 
4.3.29: (July 12, 2010)
Aug 22 08:48:13 mx milter-link[2004]: 00056 NOQUEUE: black listed URL host 
central.temoteo.net
 by surbl.blocked.rbl.
Aug 22 08:55:28 mx milter-link[2004]: 00154 NOQUEUE: black listed URL host 
diagnosticinfo.com
 by surbl.blocked.rbl.
Aug 22 08:55:29 mx postfix/postfix-script[4663]: starting the Postfix mail 
system
 
 
i 2 NOQUEUE sono richeste fatte dall'altro server
L'unica cosa che ho visto è che c'era il processo postfix-check in D ed il 
load del server è salito un po' (niente di chè, circa 3 ma era a 0.1)


 postfix
 
e se lo lanci in verbose mode?
 
http://www.postfix.org/DEBUG_README.html
 

 wrote:

al prossimo riavvio provo (se ce la faccio domani che yum mi ha segnalato un 
upgrade del kernel)


 
 
 
niente di niente...
Qui parte con i controlli
Aug 29 08:34:00 mx postfix[2050]: dict_register: mail_dict 1
Aug 29 08:34:00 mx postfix[2050]: dict_update: config_directory = /etc/postfix
Aug 29 08:34:00 mx postfix[2050]: dict_update: relay_domains = 
$transport_maps
 
 
qui finisce
Aug 29 08:34:00 mx postfix[2050]: mac_parse: no
Aug 29 08:34:00 mx postfix[2050]: dict_eval: const  no
 
e poi dopo 2 minuti parte
Aug 29 08:36:04 mx postfix/postfix-script[2995]: starting the Postfix mail 
system
 
L'unica cosa anomala è che vedo 2 comandi di partenza
 
Aug 29 08:36:04 mx postfix/postfix-script[2996]: starting the Postfix mail 
system
Aug 29 08:36:04 mx postfix/postfix-script[2995]: starting the Postfix mail 
system
Aug 29 08:36:04 mx postfix/master[2998]: fatal: open lock file pid/master.pid: 
unable to set exclusive lock: Resource temporarily unavailable
Aug 29 08:36:04 mx postfix/master[2997]: daemon started -- version 2.8.2, 
configuration /etc/postfix
 
 
Ma di comandi postfix start in rc.local ce n'è uno solo..


 Ma di comandi postfix start in rc.local ce n'è uno solo..
 
rc.local?
 
ahem...
 
chkconfig --list postfix 
 
e verifica cosa c'è in rcX.d dove X è il tuo runlevel
 
vado a memoria visto che uso una derivata di centos che non usa chkconfig 
e non uso postfix :-)
 
S.
 


rc.local perché è compilata a manina e quei programmi li metto li
Non è in chkconfig comunque


 in chkconfig comunque
 
giovane (Cit.)
 
ti compili a manina postfix su una centos? ti piace farti del male?
 
S.


No, non mi piace farmi male.
Ma a occhio la versione di centos di postfix non supporta l'autenticazione 
sasl fornita da dovecot, nei pacchetti non ci sono le dipendenze di pgsql 
(che io uso per gli utenti) e comunque dovevo migrare velocemente un server 
basato su slack, quindi la ricompilazione era l'unica cosa veloce da fare
