Univention Bugzilla – Bug 18000
Update von 2.2 auf 2.3 führt zu runsv - fatal error
Last modified: 2015-04-01 13:48:13 CEST
ps aux liefert folgenden Eintrag: root 2387 0.0 0.0 124 32 ? S Mar12 0:01 runsvdir -P /et c/service log: ion: fatal: unable to start ./run: file does not exist?runsv univ ention: fatal: unable to start ./run: file does not exist?runsv univention: fata l: unable to start ./run: file does not exist?runsv univention: fatal: unable to start ./run: file does not exist?runsv univention: fatal: unable to start ./run : file does not exist?runsv univention: fatal: unable to start ./run: file does not exist? Im Vergleich zu UCS 2.3 ist der Link /etc/service -> /etc/runit/univention nach einem Update von 2.2 weiterhin ein reales Verzeichnis. Workaround: Das vom Link referenzierte Verzeichnis /etc/runit/univention existiert und das Verzeichnis ist durch den Link zu ersetzen.
Ist in dem Verzeichnis /etc/runit/univention das Verzeichnis supervise vorhanden, sollte dieses vor dem Restart von univention-runit entfernt werden.
Das Problem ist auch nach einem Reboot noch vorhanden? Ich habe das in noch keiner aktualisierten UCS 2.3-Umgebung gesehen.
(In reply to comment #2) > Das Problem ist auch nach einem Reboot noch vorhanden? > > Ich habe das in noch keiner aktualisierten UCS 2.3-Umgebung gesehen. Bei Kunde 06190 ist das auch aufgetreten: Roman hatte mich auf das Problem hingewiesen, nachdem er es dort festgestellt hatte.
Ebenfalls bei einer anderen Kundenumgebung beim Update aufgetreten, siehe Ticket 2010100510002209
Ist das Problem nach dem Reboot (nach dem Update auf UCS 2.3) noch vorhanden? Welche runsv-Dienste sind auf dem System vorhanden? Wie äußert sich das Problem, ausser der Anzeige in der ps-Ausgabe?
In einer weiteren Kundenumgebung aufgetreten, Sie Ticket: 2010100610001324
(In reply to comment #6) > In einer weiteren Kundenumgebung aufgetreten, Sie Ticket: 2010100610001324 Ergänzung: Ja, (In reply to comment #5) > Ist das Problem nach dem Reboot (nach dem Update auf UCS 2.3) noch vorhanden? > > Welche runsv-Dienste sind auf dem System vorhanden? > > Wie äußert sich das Problem, ausser der Anzeige in der ps-Ausgabe? Ja, das Problem besteht auch nach dem Reboot. Als Fehler tritt, wie in der ps-Ausgabe zu sehen ist, der Versuch auch, im Verzeichnis 'univention' das run-File auszuführen. Das ganze wirkt sich ja rekursiv aus. Welche Auswirkungen das bspw. auf die anderen Services hat, sollte dann vielleicht nochmal untersucht werden.
(In reply to comment #7) > (In reply to comment #6) > > In einer weiteren Kundenumgebung aufgetreten, Sie Ticket: 2010100610001324 > > Ergänzung: Ja, (In reply to comment #5) > > Ist das Problem nach dem Reboot (nach dem Update auf UCS 2.3) noch vorhanden? > > > > Welche runsv-Dienste sind auf dem System vorhanden? > > > > Wie äußert sich das Problem, ausser der Anzeige in der ps-Ausgabe? > > Ja, das Problem besteht auch nach dem Reboot. > > Als Fehler tritt, wie in der ps-Ausgabe zu sehen ist, der Versuch auch, im > Verzeichnis 'univention' das run-File auszuführen. Das ganze wirkt sich ja > rekursiv aus. Welche Auswirkungen das bspw. auf die anderen Services hat, > sollte dann vielleicht nochmal untersucht werden. Auch nochmal getestet: Die anderen Dienste werden weiter neugestartet, wenn man sie bswp. durch kill -9 abschießt. Funktional sind also keine Einschränkungen erkennbar, unschön also vor allem die ps-Ausgabe.
An Ticket#: 2011030910000135 nach dem Update auf 2.4-1-2 aufgetreten. Workaround mv /etc/service /etc/service.BAK ln -s /etc/runit/univention /etc/service Das System konnte aufgrund dieses Verhaltens nicht erneut joinen.
*** Bug 21833 has been marked as a duplicate of this bug. ***
Vorhin aufgetreten wenn das Verzeichnis "supervise" nicht entfernt wird: Network not reachable. Nachdem das Verzeichnis entfernt wurde war nach einem Neustart der Rechner wieder pingbar und per ssh erreichbar.
ebenfalls aufgefallen an Ticket#: 2011081710001548 root 5225 0.0 0.0 124 32 ? S Aug31 0:09 runsvdir -P /etc/service log: ion: fatal: unable to start ./run: file does not exist?runsv univention: fatal: unable to start ./run: file does not exist?runsv univention: fatal: unable to start ./run: file does not exist?runsv univention: fatal: unable to start ./run: file does not exist?runsv univention: fatal: unable to start ./run: file does not exist?runsv univention: fatal: unable to start ./run: file does not exist?
Erneut aufgetreten an 2011110121002791, hier hat sich das bis in ein 2.4-3 System gezogen, ein nachträglich installierter UVMMd lies sich aufgrund dieses Problems nicht starten. Ist es evtl. möglich auf dieses Problem während eines Updates zu prüfen und das ggf. direkt zu fixen? Der Workaround hat auch in diesem Fall das Problem direkt behoben.
Wiederholt aufgetreten an Ticket: #2011091210001564 Fehlermeldung im update.log: rmdir: failed to remove `/etc/service': Directory not empty ...fail!
Quickfix: 1. mv /etc/service /etc/service.old; rm -r /etc/runit/univention/supervise; ln -s /etc/runit/univention /etc/service 2. Reboot
*** Bug 26077 has been marked as a duplicate of this bug. ***
Wie an Bug #26077 comment 8 beschrieben tritt beim Aktualisieren eines UCS-Systems auf UCS-2.3 ein Bug auf, der dazu führt, das /etc/service dann kein Symlink auf /etc/runit/univention ist. Spätestens mit UCS-3.0 führt das dann dazu, daß z.B. Samba-4 nicht gestartet wird. Ein automatisches Mergen der Verzeichnisse ist nur schwer möglich, von daher sollte in den Release-Nodes zu UCS-3.0 (bzw. auch UCS-2.x) folgendes aufgenommen werden: Wegen \ucsBug{18000} kommt es beim Update von UCS-2.2 auf UCS-2.3 zu einem Fehler, der dazu führt, daß später bei einer Aktualisierung auf UCS-3.0 verschiedene Dienste (u.a. Samba 4) nicht gestartet werden. Um diesen Fehler zu korrigieren muß sichergestellt werden, das \ucsFile{/etc/service} ein symbolischer Link auf das Verzeichnis \ucsFile{/etc/runit/univention} ist. Ist \ucsFile{/etc/service} ein Verzeichnis, so sollte dieses per \ucsCommand{mv /etc/service /etc/service.old} umbenannt werden. Anschließend kann per \ucsCommand{ln -s /etc/runit/univention /etc/service} der symbolische Link erzeugt werden. Anschließend sollte die beiden Verzeichnisse verglichen werden und ggf. fehlende Einträge nach \ucsFile{/etc/service} von Hand übernommen werden. \textbf{Beachte}: Verwechseln Sie die Pfadangabe nicht mit der Datei \ucsFile{/etc/services}!
In Kapitel 3.1 der UCS 3.0 Release Notes wurde ein entsprechender Hinweis aufgenommen.
OK: svn13349
Die deutschsprachigen 3.0-Release Notes auf dem Mirror wurden ersetzt (die englischen folgen, sobald übersetzt)