Gegroet,
Sinds pleskupdate is er iets niet helemaal lekker met qmail. Hij start zonder probleem maar als ik kijk naar port 25 is er niemand die daar luistert. Iemand enig idee waar de bron van de elende zit?
Gegroet,
Sinds pleskupdate is er iets niet helemaal lekker met qmail. Hij start zonder probleem maar als ik kijk naar port 25 is er niemand die daar luistert. Iemand enig idee waar de bron van de elende zit?
Start je Qmail via het controlpanel, of via command line? Probeer Qmail op te starten via command line.
Bekijk daarnaast de Qmail log.
qmail-smtpd zal niet draaien. Deze wordt meestal apart gestart met behulp van tcpserver. Kijk eens in je init scripts.
als ik qmail restart krijg ik volgende in log:
May 10 19:47:00 Latoya qmail: qmail-send shutdown succeeded
May 10 19:47:00 Latoya qmail: Starting qmail: succeeded
maar is er ook nog iets van een debug modus voor meer details over qmail of is er nog een log van alleen qmail? dit haal ik uit messages log.
niet echt debug logging, wat geeft: ps aux |grep qmail-smtpd. Als dit niets geeft dan moet je zoals ik eerder al zei qmail-smtpd starten...
root 30749 0.0 0.0 3684 584 pts/1 R 19:55 0:00 grep qmail-smtpd
Met Plesk 7.5.x durf ik het even niet te zeggen, maar andere 7.x versies van plesk stuurt qmail aan via de xinetd.
In je /etc/xinet.d/ dir heb je als goed is iets dergelijks staan:
[root@ferengi xinetd.d]# cat smtp_psa
service smtp
{
socket_type = stream
protocol = tcp
wait = no
disable = no
user = root
instances = UNLIMITED
server = /var/qmail/bin/tcp-env
server_args = /var/qmail/bin/relaylock /var/qmail/bin/qmail-smtpd /var/qmail/bin/smtp_auth /var/qmail/bin/true /var/qmail/bin/cmd5checkpw /var/qmail/bin/true
}
(let wel, dit is van Plesk 7.1 )
Controleer eventueel of er op port 25 iets luisterd d.m.v. het commando:
# netstat -an | grep LISTEN
In de lijst die je dan krijgt zou je o.a. ook moeten hebben staan:
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
Dan weet je in elk geval of er *iets* luisterd naar de smtp port.
edit:// controleer eventueel of xinetd draait d.m.v. een:
# ps -ef | grep xinetd
Laatst gewijzigd door royen99; 10/05/05 om 20:00.
die draait dus niet... dan moet je hem starten Maar hoe je dat op een juiste manier met plesk doet weet ik niet, dus best even opzoeken waar plesk qmail start, het commando manueel uitvoeren en kijken waar het mis loopt
// edit: of een systeembeheerder inhuren
// edit2 (vorige post gelezen): xinetd draait misschien niet? Start die eens
daar is toch een probleem. Het deel wat jij net post komt grotendeels overeen met wat er staat op wat paden na. Echter, als ik kijk naar de open poorten ontbreekt 25 er gewoon....
Restart eventueel xinetd via:
# /etc/init.d/xinetd restart
en controleer de netstat -an output opnieuw. (hij zou er bij moeten staan).
Let wel dat in die smtp_psa file het item: "disable = no" moet staan OF de hele "disable =" weglaten. In elk geval NIET "disable = yes".
Na het (re)starten van xinetd ook even kijken in de /var/log/messages voor eventuele fouten van xinetd.
niks in de logs extra. Heb logs van xinetd op debug gezet. nog niks over mijn smtp. Port komt niet online. ondanks alle verwoede pogingen. Heb plesk opnieuw reboot gegeven. Iemand nog suggesties?
Staat smtp wel gemapped naar port 25 ?
# grep smtp /etc/services
Output moet bevatten:
smtp 25/tcp mail
Als je xinetd restart, dan krijg je als het goed is ook te zien hoeveel xinetd services aktief zijn (in /var/log/messages) een regel als bv:
<datum / tijd> <host> xinetd[16033]: Started working: 6 available services
Komt dat aantal overeen met het aantal enabled services van de /etc/xinetd.d directory ?
hmm. Nog gekker. grep smtp /etc/services toont wel degelijk smpt op 25 aan. maar zichtbaar is hij niet.
Xinetd laat in de logs niet zien hoe of wat na een restart
Dat is wel maf.
Wat ik denk is dat apf doorgedraaid is.
Als ik hem oproep krijg ik rare dingen.
Mogelijk is hij op de achtergrond stiekem toch mijn smtp aan het blocken.
Het probleem zit em dus meer in xinetd als qmail schat ik.
Bij het stoppen/starten/herstarten van xinetd dien je meldingen ervan te krijgen in je syslog.
Staat er iets dergelijks in je /etc/xinetd.conf :
defaults
{
instances = 60
log_type = SYSLOG authpriv
log_on_success = HOST PID
log_on_failure = HOST
cps = 25 30
}
includedir /etc/xinetd.d
Probeer anders ook eens de xinetd een sighup te geven, bij het ontvangen van dat signaal dient xinetd zijn config opnieuw in te lezen:
via:
# ps -efa | grep xinetd (kijk welk process is het is)
# kill -1 <process id van xinetd>
( een kill -1 staat gelijk aan een sighup )
allemaal gedaan. werkt ook niet.
Heb kill gegeven.