Moin,
ich habe hier einen Rechner mit opensuse 12.3, der beim booten einfach den Postfix nicht mitstarten will. Der Rechner fährt normal hoch, ein "systemctl status postfix.service" sagt aber nur: postfix.service - Postfix Mail Transport Agent Loaded: loaded (/etc/systemd/system/postfix.service; enabled) Active: inactive (dead) CGroup: name=systemd:/system/postfix.service
journalctl -u postfix.service sagt gar nichts....
In der Ausgabe von journalctl findet sich auch nichts...
Nachstarten von postfix geht problemlos.
# systemctl status postfix.service postfix.service - Postfix Mail Transport Agent Loaded: loaded (/etc/systemd/system/postfix.service; enabled) Active: active (running) since Tue, 2015-08-11 19:44:16 CEST; 33s ago Process: 3348 ExecStartPost=/etc/postfix/system/cond_slp register (code=exited, status=0/SUCCESS) Process: 3342 ExecStartPost=/etc/postfix/system/wait_qmgr 60 (code=exited, status=0/SUCCESS) Process: 3262 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS) Process: 3259 ExecStartPre=/etc/postfix/system/update_postmaps (code=exited, status=0/SUCCESS) Process: 3256 ExecStartPre=/etc/postfix/system/update_chroot (code=exited, status=0/SUCCESS) Process: 3250 ExecStartPre=/etc/postfix/system/config_postfix_marco (code=exited, status=0/SUCCESS) Process: 3246 ExecStartPre=/bin/echo Starting mail service (Postfix) (code=exited, status=0/SUCCESS) Main PID: 3341 (master) CGroup: name=systemd:/system/postfix.service â 3341 /usr/lib/postfix/master â 3343 pickup -l -t fifo -u â 3344 qmgr -l -t fifo -u â 3349 cleanup -z -t unix -u â 3358 trivial-rewrite -n rewrite -t unix -u â 3359 pipe -n uucp -t unix flags=Fqhu. user=uucp argv=/usr/uti/sbsmtp $nexthop $sender $recipient
Jemand ne Ahnung wie man das am besten debuggen kann? systemctl ist immernoch ziemliches Neuland....
Gruß
Daniel
Hallo Liste, hallo Herr Spannbauer,
Am 11.08.2015 um 19:45 schrieb Daniel Spannbauer:
Moin,
ich habe hier einen Rechner mit opensuse 12.3, der beim booten einfach den Postfix nicht mitstarten will. Der Rechner fährt normal hoch, ein "systemctl status postfix.service" sagt aber nur: postfix.service - Postfix Mail Transport Agent Loaded: loaded (/etc/systemd/system/postfix.service; enabled) Active: inactive (dead) CGroup: name=systemd:/system/postfix.service
journalctl -u postfix.service sagt gar nichts....
In der Ausgabe von journalctl findet sich auch nichts...
Nachstarten von postfix geht problemlos.
mir (ebenfalls systemd Neuling) würde da ein
systemctl enable postfix.service
einfallen. Ein ähnliches Problem hatte ich mit amavis. Gruß Rainer
Am 11.08.2015 um 20:17 schrieb Rainer Gubanski:
Hallo Liste, hallo Herr Spannbauer,
Am 11.08.2015 um 19:45 schrieb Daniel Spannbauer:
Moin,
ich habe hier einen Rechner mit opensuse 12.3, der beim booten einfach den Postfix nicht mitstarten will. Der Rechner fährt normal hoch, ein "systemctl status postfix.service" sagt aber nur: postfix.service - Postfix Mail Transport Agent Loaded: loaded (/etc/systemd/system/postfix.service; enabled) Active: inactive (dead) CGroup: name=systemd:/system/postfix.service
journalctl -u postfix.service sagt gar nichts....
In der Ausgabe von journalctl findet sich auch nichts...
Nachstarten von postfix geht problemlos.
mir (ebenfalls systemd Neuling) würde da ein
systemctl enable postfix.service
einfallen. Ein ähnliches Problem hatte ich mit amavis. Gruß Rainer
Schau mal ob es Abhängigkeiten sind z. B. habe ich einen NFS-Share wenn der nicht da ist, dann startet postfix nicht. Da gibt es ein file dort stehe diese Dinge drin. Leider kann ich hier gerade nicht nachschauen.
Ingo
Am Dienstag, 11. August 2015, 21:08:06 schrieb Ingo:
Am 11.08.2015 um 20:17 schrieb Rainer Gubanski:
Hallo Liste, hallo Herr Spannbauer,
Am 11.08.2015 um 19:45 schrieb Daniel Spannbauer:
Moin,
ich habe hier einen Rechner mit opensuse 12.3, der beim booten einfach den Postfix nicht mitstarten will. Der Rechner fährt normal hoch, ein "systemctl status postfix.service" sagt aber nur: postfix.service - Postfix Mail Transport Agent Loaded: loaded (/etc/systemd/system/postfix.service; enabled) Active: inactive (dead) CGroup: name=systemd:/system/postfix.service
journalctl -u postfix.service sagt gar nichts....
In der Ausgabe von journalctl findet sich auch nichts...
Nachstarten von postfix geht problemlos.
mir (ebenfalls systemd Neuling) würde da ein
systemctl enable postfix.service
einfallen. Ein ähnliches Problem hatte ich mit amavis. Gruß Rainer
Schau mal ob es Abhängigkeiten sind z. B. habe ich einen NFS-Share wenn der nicht da ist, dann startet postfix nicht. Da gibt es ein file dort stehe diese Dinge drin. Leider kann ich hier gerade nicht nachschauen.
Ingo
wie /wo kann man eine Abhängigkeit von NFS denn ausdrücken? Ich bräuchte das für apache.
Bye Jürgen
Am 11.08.2015 um 21:08 schrieb Ingo:
Am 11.08.2015 um 20:17 schrieb Rainer Gubanski:
Hallo Liste, hallo Herr Spannbauer,
Am 11.08.2015 um 19:45 schrieb Daniel Spannbauer:
Moin,
ich habe hier einen Rechner mit opensuse 12.3, der beim booten einfach den Postfix nicht mitstarten will. Der Rechner fährt normal hoch, ein "systemctl status postfix.service" sagt aber nur: postfix.service - Postfix Mail Transport Agent Loaded: loaded (/etc/systemd/system/postfix.service; enabled) Active: inactive (dead) CGroup: name=systemd:/system/postfix.service
journalctl -u postfix.service sagt gar nichts....
In der Ausgabe von journalctl findet sich auch nichts...
Nachstarten von postfix geht problemlos.
mir (ebenfalls systemd Neuling) würde da ein
systemctl enable postfix.service
einfallen. Ein ähnliches Problem hatte ich mit amavis. Gruß Rainer
Schau mal ob es Abhängigkeiten sind z. B. habe ich einen NFS-Share wenn der nicht da ist, dann startet postfix nicht. Da gibt es ein file dort stehe diese Dinge drin. Leider kann ich hier gerade nicht nachschauen.
Ich hab leider in keinem Log was gefunden. Wüsste auch nicht das ich irgendeine Datei auf nem NFS-Share hätte.... Bei "Requires" ist ein remote-fs.target eingetragen, der Postfix sollte also eh erst nach den NFS-Mounts gestartet werden...
Gruß
Daniel
Am 12.08.2015 um 08:45 schrieb Daniel Spannbauer:
Am 11.08.2015 um 21:08 schrieb Ingo:
Am 11.08.2015 um 20:17 schrieb Rainer Gubanski:
Hallo Liste, hallo Herr Spannbauer,
Am 11.08.2015 um 19:45 schrieb Daniel Spannbauer:
Moin,
ich habe hier einen Rechner mit opensuse 12.3, der beim booten einfach den Postfix nicht mitstarten will. Der Rechner fährt normal hoch, ein "systemctl status postfix.service" sagt aber nur: postfix.service - Postfix Mail Transport Agent Loaded: loaded (/etc/systemd/system/postfix.service; enabled) Active: inactive (dead) CGroup: name=systemd:/system/postfix.service
journalctl -u postfix.service sagt gar nichts....
In der Ausgabe von journalctl findet sich auch nichts...
Nachstarten von postfix geht problemlos.
mir (ebenfalls systemd Neuling) würde da ein systemctl enable postfix.service
einfallen. Ein ähnliches Problem hatte ich mit amavis. Gruß Rainer
Schau mal ob es Abhängigkeiten sind z. B. habe ich einen NFS-Share wenn der nicht da ist, dann startet postfix nicht. Da gibt es ein file dort stehe diese Dinge drin. Leider kann ich hier gerade nicht nachschauen.
Ich hab leider in keinem Log was gefunden. Wüsste auch nicht das ich irgendeine Datei auf nem NFS-Share hätte.... Bei "Requires" ist ein remote-fs.target eingetragen, der Postfix sollte also eh erst nach den NFS-Mounts gestartet werden...
Genau das war es bei mir. Ich habe auch nichts für den Postfix auf dem NFS-Share und trotzdem musste ich den Eintrag "remote-fs.target" rausnehmen. Danach ging es dann. Ich habe es damals so aufgeschrieben:
Falls postfix nicht automatisch startet
/usr/lib/systemd/system/postfix.service entfernen von remote-fs.target bei requires und after
Gruß Ingo
Am 08/12/2015 um 09:43 AM schrieb Ingo:
Am 12.08.2015 um 08:45 schrieb Daniel Spannbauer:
Am 11.08.2015 um 21:08 schrieb Ingo:
Am 11.08.2015 um 20:17 schrieb Rainer Gubanski:
Hallo Liste, hallo Herr Spannbauer,
Am 11.08.2015 um 19:45 schrieb Daniel Spannbauer:
Moin,
ich habe hier einen Rechner mit opensuse 12.3, der beim booten einfach den Postfix nicht mitstarten will. Der Rechner fährt normal hoch, ein "systemctl status postfix.service" sagt aber nur: postfix.service - Postfix Mail Transport Agent Loaded: loaded (/etc/systemd/system/postfix.service; enabled) Active: inactive (dead) CGroup: name=systemd:/system/postfix.service
journalctl -u postfix.service sagt gar nichts....
In der Ausgabe von journalctl findet sich auch nichts...
Nachstarten von postfix geht problemlos.
mir (ebenfalls systemd Neuling) würde da ein systemctl enable postfix.service
einfallen. Ein ähnliches Problem hatte ich mit amavis. Gruß Rainer
Schau mal ob es Abhängigkeiten sind z. B. habe ich einen NFS-Share wenn der nicht da ist, dann startet postfix nicht. Da gibt es ein file dort stehe diese Dinge drin. Leider kann ich hier gerade nicht nachschauen.
Ich hab leider in keinem Log was gefunden. Wüsste auch nicht das ich irgendeine Datei auf nem NFS-Share hätte.... Bei "Requires" ist ein remote-fs.target eingetragen, der Postfix sollte also eh erst nach den NFS-Mounts gestartet werden...
Genau das war es bei mir. Ich habe auch nichts für den Postfix auf dem NFS-Share und trotzdem musste ich den Eintrag "remote-fs.target" rausnehmen. Danach ging es dann. Ich habe es damals so aufgeschrieben:
Falls postfix nicht automatisch startet
/usr/lib/systemd/system/postfix.service entfernen von remote-fs.target bei requires und after
Naja, wäre das dann nicht ein Bug? Keine Ahnung ob das VErhalten nicht doch irgendwie logisch und gewollt ist. Und ist das bei neueren Versionen auch noch so?
Gruß
Daniel
Am 12.08.2015 um 10:00 schrieb Daniel Spannbauer:
Am 08/12/2015 um 09:43 AM schrieb Ingo:
Am 12.08.2015 um 08:45 schrieb Daniel Spannbauer:
Am 11.08.2015 um 21:08 schrieb Ingo:
Am 11.08.2015 um 20:17 schrieb Rainer Gubanski:
Hallo Liste, hallo Herr Spannbauer,
Am 11.08.2015 um 19:45 schrieb Daniel Spannbauer:
Moin,
ich habe hier einen Rechner mit opensuse 12.3, der beim booten einfach den Postfix nicht mitstarten will. Der Rechner fährt normal hoch, ein "systemctl status postfix.service" sagt aber nur: postfix.service - Postfix Mail Transport Agent Loaded: loaded (/etc/systemd/system/postfix.service; enabled) Active: inactive (dead) CGroup: name=systemd:/system/postfix.service
journalctl -u postfix.service sagt gar nichts....
In der Ausgabe von journalctl findet sich auch nichts...
Nachstarten von postfix geht problemlos.
mir (ebenfalls systemd Neuling) würde da ein systemctl enable postfix.service
einfallen. Ein ähnliches Problem hatte ich mit amavis. Gruß Rainer
Schau mal ob es Abhängigkeiten sind z. B. habe ich einen NFS-Share wenn der nicht da ist, dann startet postfix nicht. Da gibt es ein file dort stehe diese Dinge drin. Leider kann ich hier gerade nicht nachschauen.
Ich hab leider in keinem Log was gefunden. Wüsste auch nicht das ich irgendeine Datei auf nem NFS-Share hätte.... Bei "Requires" ist ein remote-fs.target eingetragen, der Postfix sollte also eh erst nach den NFS-Mounts gestartet werden...
Genau das war es bei mir. Ich habe auch nichts für den Postfix auf dem NFS-Share und trotzdem musste ich den Eintrag "remote-fs.target" rausnehmen. Danach ging es dann. Ich habe es damals so aufgeschrieben:
Falls postfix nicht automatisch startet
/usr/lib/systemd/system/postfix.service entfernen von remote-fs.target bei requires und after
Naja, wäre das dann nicht ein Bug? Keine Ahnung ob das VErhalten nicht doch irgendwie logisch und gewollt ist. Und ist das bei neueren Versionen auch noch so?
Ich habe das bei 13.1. ob das ein Bug ist kann ich nicht sagen. Es ist für mich auch nicht recht nachvollziehbar. Und für einen Bugreport hatte ich zu wenig Infos, da es nur auf einem System so war. Und ich auch nicht verstanden habe war das geschieht.
Ingo
Am 08/12/2015 um 10:43 AM schrieb Ingo:
Am 12.08.2015 um 10:00 schrieb Daniel Spannbauer:
Am 08/12/2015 um 09:43 AM schrieb Ingo:
Am 12.08.2015 um 08:45 schrieb Daniel Spannbauer:
Am 11.08.2015 um 21:08 schrieb Ingo:
Am 11.08.2015 um 20:17 schrieb Rainer Gubanski:
Hallo Liste, hallo Herr Spannbauer,
Am 11.08.2015 um 19:45 schrieb Daniel Spannbauer: > Moin, > > ich habe hier einen Rechner mit opensuse 12.3, der beim booten einfach > den Postfix nicht mitstarten will. > Der Rechner fährt normal hoch, ein "systemctl status postfix.service" > sagt aber nur: > postfix.service - Postfix Mail Transport Agent > Loaded: loaded (/etc/systemd/system/postfix.service; > enabled) > Active: inactive (dead) > CGroup: name=systemd:/system/postfix.service > > journalctl -u postfix.service sagt gar nichts.... > > In der Ausgabe von journalctl findet sich auch nichts... > > Nachstarten von postfix geht problemlos. mir (ebenfalls systemd Neuling) würde da ein systemctl enable postfix.service
einfallen. Ein ähnliches Problem hatte ich mit amavis. Gruß Rainer
Schau mal ob es Abhängigkeiten sind z. B. habe ich einen NFS-Share wenn der nicht da ist, dann startet postfix nicht. Da gibt es ein file dort stehe diese Dinge drin. Leider kann ich hier gerade nicht nachschauen.
Ich hab leider in keinem Log was gefunden. Wüsste auch nicht das ich irgendeine Datei auf nem NFS-Share hätte.... Bei "Requires" ist ein remote-fs.target eingetragen, der Postfix sollte also eh erst nach den NFS-Mounts gestartet werden...
Genau das war es bei mir. Ich habe auch nichts für den Postfix auf dem NFS-Share und trotzdem musste ich den Eintrag "remote-fs.target" rausnehmen. Danach ging es dann. Ich habe es damals so aufgeschrieben:
Falls postfix nicht automatisch startet
/usr/lib/systemd/system/postfix.service entfernen von remote-fs.target bei requires und after
Naja, wäre das dann nicht ein Bug? Keine Ahnung ob das VErhalten nicht doch irgendwie logisch und gewollt ist. Und ist das bei neueren Versionen auch noch so?
Ich habe das bei 13.1. ob das ein Bug ist kann ich nicht sagen. Es ist für mich auch nicht recht nachvollziehbar. Und für einen Bugreport hatte ich zu wenig Infos, da es nur auf einem System so war. Und ich auch nicht verstanden habe war das geschieht.
Ingo
Also....gerade mal einen Server geändert und neu gebootet....es ist die Ursache allen Übels.... rmote-ds.target aus dem After und Requires raus, schon gehts.
Bin über ein weiteres Problem gestolpert: Beim runterfahren wird das Netzwerk abgedreht bevor alle NFS-Mounts ausgehängt sind. Ein Shutdown dauert so ewig, ich breche meist schon vorher mit einem Reset ab.
Hat dafür auch einer ne Lösung?
Gruß
Daniel
Am 08/12/2015 um 07:49 PM schrieb Daniel Spannbauer:
Am 08/12/2015 um 10:43 AM schrieb Ingo:
Am 12.08.2015 um 10:00 schrieb Daniel Spannbauer:
Am 08/12/2015 um 09:43 AM schrieb Ingo:
Am 12.08.2015 um 08:45 schrieb Daniel Spannbauer:
Am 11.08.2015 um 21:08 schrieb Ingo:
Am 11.08.2015 um 20:17 schrieb Rainer Gubanski: > Hallo Liste, hallo Herr Spannbauer, > > Am 11.08.2015 um 19:45 schrieb Daniel Spannbauer: >> Moin, >> >> ich habe hier einen Rechner mit opensuse 12.3, der beim booten einfach >> den Postfix nicht mitstarten will. >> Der Rechner fährt normal hoch, ein "systemctl status postfix.service" >> sagt aber nur: >> postfix.service - Postfix Mail Transport Agent >> Loaded: loaded (/etc/systemd/system/postfix.service; >> enabled) >> Active: inactive (dead) >> CGroup: name=systemd:/system/postfix.service >> >> journalctl -u postfix.service sagt gar nichts.... >> >> In der Ausgabe von journalctl findet sich auch nichts... >> >> Nachstarten von postfix geht problemlos. > mir (ebenfalls systemd Neuling) würde da ein > systemctl enable postfix.service > > einfallen. Ein ähnliches Problem hatte ich mit amavis. > Gruß > Rainer Schau mal ob es Abhängigkeiten sind z. B. habe ich einen NFS-Share wenn der nicht da ist, dann startet postfix nicht. Da gibt es ein file dort stehe diese Dinge drin. Leider kann ich hier gerade nicht nachschauen.
Ich hab leider in keinem Log was gefunden. Wüsste auch nicht das ich irgendeine Datei auf nem NFS-Share hätte.... Bei "Requires" ist ein remote-fs.target eingetragen, der Postfix sollte also eh erst nach den NFS-Mounts gestartet werden...
Genau das war es bei mir. Ich habe auch nichts für den Postfix auf dem NFS-Share und trotzdem musste ich den Eintrag "remote-fs.target" rausnehmen. Danach ging es dann. Ich habe es damals so aufgeschrieben:
Falls postfix nicht automatisch startet
/usr/lib/systemd/system/postfix.service entfernen von remote-fs.target bei requires und after
Naja, wäre das dann nicht ein Bug? Keine Ahnung ob das VErhalten nicht doch irgendwie logisch und gewollt ist. Und ist das bei neueren Versionen auch noch so?
Ich habe das bei 13.1. ob das ein Bug ist kann ich nicht sagen. Es ist für mich auch nicht recht nachvollziehbar. Und für einen Bugreport hatte ich zu wenig Infos, da es nur auf einem System so war. Und ich auch nicht verstanden habe war das geschieht.
Ingo
Also....gerade mal einen Server geändert und neu gebootet....es ist die Ursache allen Übels.... rmote-ds.target aus dem After und Requires raus, schon gehts.
Bin über ein weiteres Problem gestolpert: Beim runterfahren wird das Netzwerk abgedreht bevor alle NFS-Mounts ausgehängt sind. Ein Shutdown dauert so ewig, ich breche meist schon vorher mit einem Reset ab.
Hat dafür auch einer ne Lösung?
Kann mal einer das Solved wegmachen.....*zefix* So langsam heul ich....Server neu gebooted und Tage später kriegt man dann irgendwann mit das der Postfix nicht läuft.... Keine Meldung im Log, nichts... Weitere Ideen wie man soetwas debuggen kann? Es muss doch irgendwo rauszufinden sein warum der Postfix nicht startet....
Gruß
Daniel
Genau das war es bei mir. Ich habe auch nichts für den Postfix auf dem NFS-Share und trotzdem musste ich den Eintrag "remote-fs.target" rausnehmen. Danach ging es dann. Ich habe es damals so aufgeschrieben:
Falls postfix nicht automatisch startet
/usr/lib/systemd/system/postfix.service entfernen von remote-fs.target bei requires und after
Naja, wäre das dann nicht ein Bug? Keine Ahnung ob das VErhalten nicht doch irgendwie logisch und gewollt ist. Und ist das bei neueren Versionen auch noch so?
Ich habe das bei 13.1. ob das ein Bug ist kann ich nicht sagen. Es ist für mich auch nicht recht nachvollziehbar. Und für einen Bugreport hatte ich zu wenig Infos, da es nur auf einem System so war. Und ich auch nicht verstanden habe war das geschieht.
Ingo
Also....gerade mal einen Server geändert und neu gebootet....es ist die Ursache allen Übels.... rmote-ds.target aus dem After und Requires raus, schon gehts.
Bin über ein weiteres Problem gestolpert: Beim runterfahren wird das Netzwerk abgedreht bevor alle NFS-Mounts ausgehängt sind. Ein Shutdown dauert so ewig, ich breche meist schon vorher mit einem Reset ab.
Hat dafür auch einer ne Lösung?
Kann mal einer das Solved wegmachen.....*zefix* So langsam heul ich....Server neu gebooted und Tage später kriegt man dann irgendwann mit das der Postfix nicht läuft.... Keine Meldung im Log, nichts... Weitere Ideen wie man soetwas debuggen kann? Es muss doch irgendwo rauszufinden sein warum der Postfix nicht startet....
So, Ursache gefunden...Lösung leider noch nicht: Sep 02 16:48:34 fry systemd[1]: Found ordering cycle on remote-fs-pre.target/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to nss-lookup.target/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to named.service/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to ldap.service/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to remote-fs.target/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to owncloud_all.mount/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to remote-fs-pre.target/start Sep 02 16:48:34 fry systemd[1]: Breaking ordering cycle by deleting job nss-lookup.target/start Sep 02 16:48:34 fry systemd[1]: Deleting job postfix.service/start as dependency of job nss-lookup.target/start
Wie krieg ich denn so einen Knoten entwirrt? Ein Standard-Vorgehen um so einen Fehler zu finden....gibts sowas?
Gruß
Daniel
On Wed, 2 Sep 2015 17:11, Daniel Spannbauer wrote: [snip]
So, Ursache gefunden...Lösung leider noch nicht: Sep 02 16:48:34 fry systemd[1]: Found ordering cycle on remote-fs-pre.target/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to nss-lookup.target/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to named.service/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to ldap.service/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to remote-fs.target/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to owncloud_all.mount/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to remote-fs-pre.target/start Sep 02 16:48:34 fry systemd[1]: Breaking ordering cycle by deleting job nss-lookup.target/start Sep 02 16:48:34 fry systemd[1]: Deleting job postfix.service/start as dependency of job nss-lookup.target/start
Wie krieg ich denn so einen Knoten entwirrt? Ein Standard-Vorgehen um so einen Fehler zu finden....gibts sowas?
Ursache liegt im remote-fs.target zweig wahrscheinlich in "owncloud_all.mount" oder remote-fs-pre.target.
OK, überlege mal, was (in Deiner installation) alles wirklich von postfix benutzt wird: ldap? remote-fs(owncloud,nfs,cifs)?
In der Datei "/usr/lib/systemd/system/postfix.service" findest Du unter "Requires=" eine Liste was Postfix "maximal" will.
Vorgabe: Requires=var-run.mount nss-lookup.target network.target remote-fs.target syslog.target time-sync.target
Gehen wirs mal durch: "var-run.mount" macht sinn, ist auch kein problem (s.o.) "nss-lookup.target" ist einfach NACH den Netzwerk die Namensauflöung, sollte kein Problem sein. "network.target" klar, mail muß raus und rein, notwendig "remote-fs.target" nur notwendig wenn die $MAIL nicht local auf der platte liegt (nfs, cifs, owncloud) "syslog.target" macht sinn, ist auch kein problem (s.o.) "time-sync.target" macht sinn, ist auch kein problem (s.o.)
Hier in Deinem fall speziell, frage dich ob bei Dir die Mail auf einem nicht lokalen Pfad landet.
Falls die mail auf lokaler Platte landet, kopiere postfix.service nach /lib/systemd/system/ [code] cp -p /usr/lib/systemd/system/postfix.service /lib/systemd/system/ [/code] und bearbeite die Datei mit 'nem Text-editor (root-rechte!) Beim bearbeiten entferne alle Vorkommen von "remote-fs.target" in den "Requires=" und "After=" Zeilen
Danach den soft link unter "/etc/systemd/system/" richten. normaler weise im Unterverzeichnis "multi-user.target.wants" [code] rm /etc/systemd/system/multi-user.target.wants/postfix.service ln -s /lib/systemd/system/postfix.service /etc/systemd/system/multi-user.target.wants/postfix.service ls -l /etc/systemd/system/multi-user.target.wants/postfix.service [/code]
Der link sollte nun nach "/lib/systemd/system/postfix.service" zeigen. [code] systemctl daemon-reload systemctl reenable postfix.service systemctl start postfix.service [code] ... um sicher zu gehen
Test weise System neu booten (besser ist das, als später noch 'ne üble Überraschung beim Neustart.
Funkts nun ohne Fehler?
- Yamaban.
Am 09/02/2015 um 06:38 PM schrieb Yamaban:
On Wed, 2 Sep 2015 17:11, Daniel Spannbauer wrote: [snip]
So, Ursache gefunden...Lösung leider noch nicht: Sep 02 16:48:34 fry systemd[1]: Found ordering cycle on remote-fs-pre.target/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to nss-lookup.target/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to named.service/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to ldap.service/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to remote-fs.target/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to owncloud_all.mount/start Sep 02 16:48:34 fry systemd[1]: Walked on cycle path to remote-fs-pre.target/start Sep 02 16:48:34 fry systemd[1]: Breaking ordering cycle by deleting job nss-lookup.target/start Sep 02 16:48:34 fry systemd[1]: Deleting job postfix.service/start as dependency of job nss-lookup.target/start
Wie krieg ich denn so einen Knoten entwirrt? Ein Standard-Vorgehen um so einen Fehler zu finden....gibts sowas?
Ursache liegt im remote-fs.target zweig wahrscheinlich in "owncloud_all.mount" oder remote-fs-pre.target.
OK, überlege mal, was (in Deiner installation) alles wirklich von postfix benutzt wird: ldap? remote-fs(owncloud,nfs,cifs)?
In der Datei "/usr/lib/systemd/system/postfix.service" findest Du unter "Requires=" eine Liste was Postfix "maximal" will.
Vorgabe: Requires=var-run.mount nss-lookup.target network.target remote-fs.target syslog.target time-sync.target
Gehen wirs mal durch: "var-run.mount" macht sinn, ist auch kein problem (s.o.) "nss-lookup.target" ist einfach NACH den Netzwerk die Namensauflöung, sollte kein Problem sein. "network.target" klar, mail muß raus und rein, notwendig "remote-fs.target" nur notwendig wenn die $MAIL nicht local auf der platte liegt (nfs, cifs, owncloud) "syslog.target" macht sinn, ist auch kein problem (s.o.) "time-sync.target" macht sinn, ist auch kein problem (s.o.)
Hier in Deinem fall speziell, frage dich ob bei Dir die Mail auf einem nicht lokalen Pfad landet.
Falls die mail auf lokaler Platte landet, kopiere postfix.service nach /lib/systemd/system/ [code] cp -p /usr/lib/systemd/system/postfix.service /lib/systemd/system/ [/code] und bearbeite die Datei mit 'nem Text-editor (root-rechte!) Beim bearbeiten entferne alle Vorkommen von "remote-fs.target" in den "Requires=" und "After=" Zeilen
Danach den soft link unter "/etc/systemd/system/" richten. normaler weise im Unterverzeichnis "multi-user.target.wants" [code] rm /etc/systemd/system/multi-user.target.wants/postfix.service ln -s /lib/systemd/system/postfix.service /etc/systemd/system/multi-user.target.wants/postfix.service ls -l /etc/systemd/system/multi-user.target.wants/postfix.service [/code]
Der link sollte nun nach "/lib/systemd/system/postfix.service" zeigen. [code] systemctl daemon-reload systemctl reenable postfix.service systemctl start postfix.service [code] ... um sicher zu gehen
Test weise System neu booten (besser ist das, als später noch 'ne üble Überraschung beim Neustart.
Funkts nun ohne Fehler?
- Yamaban.
Hallo,
alles, was remote-fs war, ist schon rausgeflogen (in einem der vorherigen Mails zu diesem Thema),
momentan siehts also so aus: [Unit] Description=Postfix Mail Transport Agent Requires=var-run.mount nss-lookup.target network.target syslog.target time-sync.target After=var-run.mount nss-lookup.target network.target syslog.target time-sync.target After=amavis.service mysql.service cyrus.service ldap.service openslp.service ypbind.service Before=mail-transfer-agent.target Conflicts=sendmail.service exim.service
remote-fs-pre muss also aus einer der Units aus Requires oder After kommen (wobei es ja ums "Ordering" geht, tippe also eher auf eine Unit aus "After")
Die klappere ich gerade ab. Aber es muss doch allegemein in vorhgehen geben wie man soetwas löst.
Gruß
Daniel
Ingo schrieb:
Am 12.08.2015 um 08:45 schrieb Daniel Spannbauer:
[...]
Ich hab leider in keinem Log was gefunden. Wüsste auch nicht das ich irgendeine Datei auf nem NFS-Share hätte.... Bei "Requires" ist ein remote-fs.target eingetragen, der Postfix sollte also eh erst nach den NFS-Mounts gestartet werden...
Genau das war es bei mir. Ich habe auch nichts für den Postfix auf dem NFS-Share und trotzdem musste ich den Eintrag "remote-fs.target" rausnehmen. Danach ging es dann. Ich habe es damals so aufgeschrieben:
Falls postfix nicht automatisch startet
/usr/lib/systemd/system/postfix.service entfernen von remote-fs.target bei requires und after
Nur eine Überlegung:
Von der Logik her könnte ich mir vorstellen, dass "after" OK ist, für den Fall, *dass* "remote-fs" verwendet wird. "require" bedeutet ja, dass erst das Target "remote-fs" aktiv sein muss, bevor postfix gestartet wird. Wenn "remote-fs" nicht benötigt wird, würde es nie aktiv, und daher würde "postfix" in dem Fall nie aktiviert.
Das würde jedoch IMO nicht gleich erklären, warum sich der postfix-Service später manuell starten läßt, wie es beim OP der Fall war, es sei denn, das Target "remote-fs" ist dann zu dem Zeitpunkt doch aktiv.
Martin
Am 08/12/2015 um 10:46 AM schrieb Martin Burnicki:
Ingo schrieb:
Am 12.08.2015 um 08:45 schrieb Daniel Spannbauer:
[...]
Ich hab leider in keinem Log was gefunden. Wüsste auch nicht das ich irgendeine Datei auf nem NFS-Share hätte.... Bei "Requires" ist ein remote-fs.target eingetragen, der Postfix sollte also eh erst nach den NFS-Mounts gestartet werden...
Genau das war es bei mir. Ich habe auch nichts für den Postfix auf dem NFS-Share und trotzdem musste ich den Eintrag "remote-fs.target" rausnehmen. Danach ging es dann. Ich habe es damals so aufgeschrieben:
Falls postfix nicht automatisch startet
/usr/lib/systemd/system/postfix.service entfernen von remote-fs.target bei requires und after
Nur eine Überlegung:
Von der Logik her könnte ich mir vorstellen, dass "after" OK ist, für den Fall, *dass* "remote-fs" verwendet wird. "require" bedeutet ja, dass erst das Target "remote-fs" aktiv sein muss, bevor postfix gestartet wird. Wenn "remote-fs" nicht benötigt wird, würde es nie aktiv, und daher würde "postfix" in dem Fall nie aktiviert.
Das würde jedoch IMO nicht gleich erklären, warum sich der postfix-Service später manuell starten läßt, wie es beim OP der Fall war, es sei denn, das Target "remote-fs" ist dann zu dem Zeitpunkt doch aktiv.
Naja, remote-fs.target ist aber der SuSE-Default. Da dürfte dann auf jdem System ohne NFS-Mounts der Postfix versagen. Das hätte SuSE schnell mitbekommen :) Aber ich habe auf meinem System einige NFS-Mounts....
Gruß
Daniel
Daniel Spannbauer [12.08.2015 11:36]:
Naja, remote-fs.target ist aber der SuSE-Default. Da dürfte dann auf jdem System ohne NFS-Mounts der Postfix versagen. Das hätte SuSE schnell mitbekommen :) Aber ich habe auf meinem System einige NFS-Mounts....
Ja, eben. Und wenn die zum Zeitpunkt des Postfix-Starts nicht alle zur Verfügung stehen, wird der Postfix-Start abgebrochen, weil das Target remote-fs nicht erreicht ist.
Werner
Am 11.08.2015 um 20:17 schrieb Rainer Gubanski:
Hallo Liste, hallo Herr Spannbauer,
Am 11.08.2015 um 19:45 schrieb Daniel Spannbauer:
Moin,
ich habe hier einen Rechner mit opensuse 12.3, der beim booten einfach den Postfix nicht mitstarten will. Der Rechner fährt normal hoch, ein "systemctl status postfix.service" sagt aber nur: postfix.service - Postfix Mail Transport Agent Loaded: loaded (/etc/systemd/system/postfix.service; enabled) Active: inactive (dead) CGroup: name=systemd:/system/postfix.service
journalctl -u postfix.service sagt gar nichts....
In der Ausgabe von journalctl findet sich auch nichts...
Nachstarten von postfix geht problemlos.
mir (ebenfalls systemd Neuling) würde da ein
systemctl enable postfix.service
einfallen. Ein ähnliches Problem hatte ich mit amavis. Gruß Rainer
Loaded: loaded (/etc/systemd/system/postfix.service; enabled)
Ist bereits enabled....
Gruß
Daniel
P.S.: Sorry für die PN
Am 12.08.2015 um 08:59 schrieb Daniel Spannbauer: Hallo Liste, Hallo Daniel
Am 11.08.2015 um 20:17 schrieb Rainer Gubanski:
Am 11.08.2015 um 19:45 schrieb Daniel Spannbauer:
mir (ebenfalls systemd Neuling) würde da ein systemctl enable postfix.service
einfallen. Ein ähnliches Problem hatte ich mit amavis. Gruß Rainer
Loaded: loaded (/etc/systemd/system/postfix.service; enabled)
Ist bereits enabled....
sorry, hatte ich überlesen. War aber bei meinem amavis Problem ähnlich: unter 12.3 noch enabled und beim booten aktiv, unter 13.1 nach dem Booten tot. Hab dann leider nicht weiter geprüft sondern den amavis.service gleich noch mal händisch enabled. Dann ging es.
Gruß Rainer
Daniel Spannbauer [11.08.2015 19:45]:
Moin,
ich habe hier einen Rechner mit opensuse 12.3, der beim booten einfach den Postfix nicht mitstarten will. Der Rechner fährt normal hoch, ein "systemctl status postfix.service" sagt aber nur: postfix.service - Postfix Mail Transport Agent Loaded: loaded (/etc/systemd/system/postfix.service; enabled) Active: inactive (dead) CGroup: name=systemd:/system/postfix.service
journalctl -u postfix.service sagt gar nichts....
In der Ausgabe von journalctl findet sich auch nichts...
Nachstarten von postfix geht problemlos.
# systemctl status postfix.service postfix.service - Postfix Mail Transport Agent Loaded: loaded (/etc/systemd/system/postfix.service; enabled) Active: active (running) since Tue, 2015-08-11 19:44:16 CEST; 33s ago Process: 3348 ExecStartPost=/etc/postfix/system/cond_slp register (code=exited, status=0/SUCCESS) Process: 3342 ExecStartPost=/etc/postfix/system/wait_qmgr 60 (code=exited, status=0/SUCCESS) Process: 3262 ExecStart=/usr/sbin/postfix start (code=exited, status=0/SUCCESS) Process: 3259 ExecStartPre=/etc/postfix/system/update_postmaps (code=exited, status=0/SUCCESS) Process: 3256 ExecStartPre=/etc/postfix/system/update_chroot (code=exited, status=0/SUCCESS) Process: 3250 ExecStartPre=/etc/postfix/system/config_postfix_marco (code=exited, status=0/SUCCESS) Process: 3246 ExecStartPre=/bin/echo Starting mail service (Postfix) (code=exited, status=0/SUCCESS) Main PID: 3341 (master) CGroup: name=systemd:/system/postfix.service â 3341 /usr/lib/postfix/master â 3343 pickup -l -t fifo -u â 3344 qmgr -l -t fifo -u â 3349 cleanup -z -t unix -u â 3358 trivial-rewrite -n rewrite -t unix -u â 3359 pipe -n uucp -t unix flags=Fqhu. user=uucp argv=/usr/uti/sbsmtp $nexthop $sender $recipient
Jemand ne Ahnung wie man das am besten debuggen kann? systemctl ist immernoch ziemliches Neuland....
Schau mal in der Ausgabe von dmesg nach "postfix", etwa
dmesg | grep postfix
Es kann sein, dass Postfix startet und eine Abhängigkeit noch nicht erfüllt ist. Systemd bricht dann den Start von Postfix ab. Später, wenn Du Postfix von Hand startest, ist die Abhängigkeit vermutlich erfüllt und der Start klappt.
Für die 12.1 gibt es dazu http://lists.opensuse.org/opensuse-de/2012-06/msg00268.html.
HDH, Werner
-
Daniel Spannbauer -
Dr. Jürgen Vollmer -
Ingo -
Martin Burnicki -
Rainer Gubanski -
Werner Flamme -
Yamaban