Próbuję uruchomić Postfiks na moim serwerze, ale wciąż pojawia się następujący błąd /var/log/mail.log
:
postfix / master [5041]: fatal: bind 0.0.0.0 port 25: Adres już używany
Przeszukałem i znalazłem tę doskonałą odpowiedź Oli (dotyczącą tego właśnie pytania), w której zalecane jest, aby zasadniczo pozbyć się mojego serwera z pakietów sendmaila, aby uniknąć konfliktów, a następnie ponownie zainstalować Postfix, który z kolei zainstaluje własną markę sendmaila. Niestety nie rozwiązało to całkowicie problemu (zobacz poniżej, jak to zrobić).
Postępowałem zgodnie z instrukcjami i przeprowadziłem następującą kontrolę, na którą otrzymałem zachęcającą odpowiedź:
$ dpkg -S `which sendmail`
postfix: /usr/sbin/sendmail
Jednak kiedy ponownie zacząłem postfix, dostałem ten sam błąd.
Zgodnie z przypadkiem Oli, szukałem procesu, który blokował port 25 z następującymi:
$ sudo netstat -pel | grep smtp
tcp 0 0 localhost.localdom:smtp *:* LISTEN root
35704126 27626/sendmail: MTA
Ale tutaj jest mylące: następnie szukałem procesu, 27626
ale powiedziano mi:
dpkg-query: nie znaleziono ścieżki pasującej do wzorca 27626
połączeń .
Podciągnąłem htop i udało mi się znaleźć powyższy PID związany z następującą komendą:
sendmail: MTA: przyjmowanie połączeń
Potem próbował zabić proces z obu killall sendmail
i killall 27626
i stawała się no process found
.
Problemem jest (poza oczywistym), że nie wiem, jak interpretować te ustalenia. Wyczyściłem serwer sendmaila, więc mogę tylko założyć, że własna wersja sendmaila po poprawce przejmuje port? Nie wiem nawet, czy to ma sens.
W każdym razie, jeśli ktokolwiek mógłby mnie postawić prosto na ten temat lub przynajmniej zadać kilka interesujących pytań diagnostycznych, byłbym wdzięczny.
Jeśli jest to przydatne, używam virtualmin na serwerze do zarządzania kilkoma różnymi domenami, a także korzystam z wordpress.
Z góry bardzo dziękuję!
W odpowiedzi na prośbę zamieściłem ps -ef
poniżej
root@upsmart:~# ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 Jan12 ? 00:00:00 init
root 2 1 0 Jan12 ? 00:00:00 [kthreadd/20017]
root 3 2 0 Jan12 ? 00:00:00 [khelper/20017]
root 68 1 0 Jan12 ? 00:00:00 upstart-udev-bridge --daemon
root 75 1 0 Jan12 ? 00:00:00 /sbin/udevd --daemon
root 110 1 0 Jan12 ? 00:00:00 /usr/sbin/sshd -D
root 130 75 0 Jan12 ? 00:00:00 /sbin/udevd --daemon
root 131 75 0 Jan12 ? 00:00:00 /sbin/udevd --daemon
root 175 1 0 Jan12 ? 00:00:00 upstart-socket-bridge --daemon
116 205 1 0 Jan12 ? 00:00:03 dbus-daemon --system --fork --activation=upstart
root 385 1 0 Jan12 ? 00:00:00 /usr/sbin/dovecot -F -c /etc/dovecot/dovecot.conf
root 386 1 0 Jan12 ? 00:00:04 cron
mysql 410 1 0 Jan12 ? 00:08:06 /usr/sbin/mysqld
dovecot 441 385 0 Jan12 ? 00:00:00 dovecot/anvil
root 442 385 0 Jan12 ? 00:00:00 dovecot/log
root 444 385 0 Jan12 ? 00:00:00 dovecot/config
syslog 445 1 0 Jan12 ? 00:00:08 /sbin/syslogd -u syslog
bind 474 1 0 Jan12 ? 00:00:12 /usr/sbin/named -u bind
clamav 844 1 0 Jan12 ? 00:01:34 /usr/sbin/clamd
clamav 951 1 0 Jan12 ? 00:03:27 /usr/bin/freshclam -d --quiet
list 969 1 0 Jan12 ? 00:00:00 /usr/bin/python /usr/lib/mailman/bin/mailmanctl -s -q start
list 970 969 0 Jan12 ? 00:01:03 /usr/bin/python /var/lib/mailman/bin/qrunner --runner=ArchRunner:0:1 -
list 971 969 0 Jan12 ? 00:01:10 /usr/bin/python /var/lib/mailman/bin/qrunner --runner=BounceRunner:0:1
list 972 969 0 Jan12 ? 00:01:03 /usr/bin/python /var/lib/mailman/bin/qrunner --runner=CommandRunner:0:
list 973 969 0 Jan12 ? 00:01:07 /usr/bin/python /var/lib/mailman/bin/qrunner --runner=IncomingRunner:0
list 974 969 0 Jan12 ? 00:01:01 /usr/bin/python /var/lib/mailman/bin/qrunner --runner=NewsRunner:0:1 -
list 976 969 0 Jan12 ? 00:01:05 /usr/bin/python /var/lib/mailman/bin/qrunner --runner=OutgoingRunner:0
list 978 969 0 Jan12 ? 00:01:06 /usr/bin/python /var/lib/mailman/bin/qrunner --runner=VirginRunner:0:1
list 980 969 0 Jan12 ? 00:00:00 /usr/bin/python /var/lib/mailman/bin/qrunner --runner=RetryRunner:0:1
root 1410 1 0 Jan12 ? 00:00:00 /usr/sbin/saslauthd -a pam -m /var/spool/postfix/var/run/saslauthd -r
root 1413 1410 0 Jan12 ? 00:00:00 /usr/sbin/saslauthd -a pam -m /var/spool/postfix/var/run/saslauthd -r
root 2034 1 0 Jan12 ? 00:00:09 /usr/bin/perl /usr/share/usermin/miniserv.pl /etc/usermin/miniserv.con
proftpd 2054 1 0 Jan12 ? 00:00:07 proftpd: (accepting connections)
root 2096 1 0 Jan12 ? 00:00:13 /usr/bin/perl /usr/share/webmin/miniserv.pl /etc/webmin/miniserv.conf
root 2173 1 0 Jan12 ? 00:00:15 /usr/sbin/console-kit-daemon --no-daemon
root 2241 1 0 Jan12 ? 00:00:07 /usr/lib/policykit-1/polkitd --no-debug
root 4895 1 0 03:15 ? 00:00:00 /usr/sbin/xinetd -dontfork -pidfile /var/run/xinetd.pid -stayalive -in
www-data 6494 30181 0 03:41 ? 00:00:06 /usr/sbin/apache2 -k start
www-data 6497 30181 0 03:42 ? 00:00:06 /usr/sbin/apache2 -k start
www-data 6499 30181 0 03:42 ? 00:00:06 /usr/sbin/apache2 -k start
www-data 6500 30181 0 03:42 ? 00:00:07 /usr/sbin/apache2 -k start
root 9477 30027 0 05:09 pts/5 00:00:00 sudo ps -ef
root 9478 9477 0 05:09 pts/5 00:00:00 ps -ef
root 27626 1 0 02:44 ? 00:00:00 sendmail: MTA: accepting connections
root 27902 110 0 02:51 ? 00:00:01 sshd: root@pts/4
root 27998 27902 0 02:51 pts/4 00:00:01 -bash
root 29931 110 0 02:59 ? 00:00:03 sshd: root@pts/5
root 30027 29931 0 02:59 pts/5 00:00:00 -bash
root 30181 1 0 03:00 ? 00:00:02 /usr/sbin/apache2 -k start
www-data 30183 30181 0 03:00 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 30636 30181 0 03:06 ? 00:00:13 /usr/sbin/apache2 -k start
Odpowiedzi:
Ten sam problem wystąpił na Ubuntu 16.04.01 LTS. Wystąpił następujący komunikat dziennika
/var/log/mail.log
i poczta wychodząca nie mogła zostać wysłana:Podczas próby zabicia sendmaila otrzymałem następujące dane wyjściowe:
Następujące polecenia działały dla mnie (nie trzeba restartować serwera):
źródło
Miałem ten sam problem i przestałem wysyłać pocztę, restartowałem postfiks i ponownie uruchom sendmaila za pomocą następujących poleceń:
Wszystko wróciło dobrze.
źródło
Cóż, odpowiedź jest głęboko niezadowalająca, ale po kilku godzinach pracy nad tym dzisiaj zrestartowałem serwer i teraz działa postfiks. Dzięki wszystkim, którzy udzielili trochę wglądu.
źródło
Po prostu zabij proces sendmaila i spróbuj ponownie:
lub
źródło
no process found
. Zaktualizuję pytanie o tę odrobinę informacji.killall sendmail
nie znalazłem dla mnie żadnych procesów, aleps aux | grep sendmail
pokazałem jeden uruchomiony, a zabicie przez jego PID rozwiązało problem. Został wymieniony jako,sendmail: MTA:[...]
więc domyślam się, że proces demona został ponownie oznakowany, ale pod inną nazwą. Niestety w tej chwili nie mogę dalej badać.Dla mnie rozwiązaniem było
sudo killall sendmail-mta
źródło
Możesz użyć
fuser
polecenia (jako root), aby uzyskać listę wszystkich procesów nasłuchujących na porcie 25 i zabić je.źródło