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 -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org