Auf allen Computern funktioniert Sendmail einwandfrei, bis auf einem.
Alle haben genau das gleiche Setup für den /etc/mail-Konfigurationsordner. Ich habe rsync verwendet, um sicherzustellen, dass sie alle übereinstimmen.
Normalerweise funktioniert dieser Befehl einwandfrei ...
sendmail -t < meine-email-datei.eml
Aber auf diesem einen Computer (alle laufen unter Ubuntu 20.04) bleibt der Prozess einfach hängen.
Ich habe "sendmail -t" ausprobiert, mit dem ich eine E-Mail direkt von der Kommandozeile aus verfassen kann. Ich drücke STRG+D und nichts passiert. Ich habe versucht, den Befehl "mail[email geschützt]" und konnte verfassen, aber als ich zur CC:-Zeile kam, blieb es hängen. Durch Drücken von STRG+Z konnte ich aussteigen und die E-Mail wurde schließlich gesendet.
Was führt dazu, dass sendmail/mail am Dateiende hängen bleibt?
Es scheint keine Möglichkeit zu geben, es vollständig zu deinstallieren und neu zu installieren. Ich habe „apt-get purge sendmail“ ausprobiert und das System sagt, es sei deinstalliert, aber wenn ich sendmail in die Befehlszeile eingebe, gelange ich immer noch in den Texteditormodus und sende immer noch E-Mails. Und „whereis sendmail“ zeigt es immer noch in /usr/sbin an.
Ich kann einfach nicht herausfinden, was hier los ist. Warum bleibt es bei EOF hängen? Und warum nur auf diesem einen Computer?
Danke!
---- UPDATE ---- Ich weiß wirklich nicht, wie man die Strace-Ausgabe liest, aber es wurde vorgeschlagen. Die Ausgabe sieht auf allen Maschinen größtenteils gleich aus, wobei dieser Teil das Ende ist ...
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/dev/log"}, 110) = 0
sendto(3, "<18>May 6 12:27:19 sendmail[265"..., 120, MSG_NOSIGNAL, NULL, 0) = 120
write(2, "Program mode requires special pr"..., 69Program mode requires special privileges, e.g., root or TrustedUser.
) = 69
alarm(0) = 0
rt_sigprocmask(SIG_UNBLOCK, [ALRM], [], 8) = 0
getpid() = 26521
setuid(1000) = 0
exit_group(78) = ?
+++ exited with 78 +++
Aber auf dem einen Computer, der hängen bleibt, bleiben die Dinge hier bei clock_nanosleep stehen, was auf den anderen nicht der Fall ist.
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 3
connect(3, {sa_family=AF_UNIX, sun_path="/dev/log"}, 110) = 0
sendto(3, "<18>May 6 12:27:57 sendmail[688"..., 100, MSG_NOSIGNAL, NULL, 0) = 100
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=60, tv_nsec=0},
Hier sind einige Informationen zu Sendmail auf diesem Server:
$ which sendmail
/usr/sbin/sendmail
$ ls -l $(which sendmail)
lrwxrwxrwx 1 root root 26 Feb 3 15:51 /usr/sbin/sendmail -> /etc/alternatives/sendmail
$ ls -l /etc/alternatives/sendmail
lrwxrwxrwx 1 root root 30 May 6 06:39 /etc/alternatives/sendmail -> /usr/libexec/sendmail/sendmail
Der Endpunkt auf anderen Servern endet bei /usr/lib/sm.bin/sendmail, aber ich bin nicht sicher, warum der Laptop mit dem Problem bei libexec/sendmail endet, da auf allen Ubuntu 22.04 läuft.
Antwort1
Ich bin gerade mit der gleichen 60-Sekunden-Verzögerung durch dieses Wurmloch gerutscht.
Ich hatte kein syslogd, aber nach der Installation erschien dies in /var/log/messages
May 12 17:52:43 myhost mail.crit sendmail[6955]: My unqualified host name (myhost) unknown; sleeping for retry
May 12 17:52:47 myhost mail.crit sendmail[6960]: My unqualified host name (myhost) unknown; sleeping for retry
May 12 17:52:52 myhost mail.crit sendmail[6974]: My unqualified host name (myhost) unknown; sleeping for retry
Versuchen Sie, den Hostnamen (und /etc/hosts) in einen FQDN – myhost.localdomain oder etwas Ähnliches – zu ändern.