staging.inyokaproject.org

Seit Ubuntu 9.10 ist wegen Upstart die Verwendung von rc.local deprecated, bzw. sie funktioniert gar nicht mehr.

Dies müsste in dem vorliegenden Artikel unbedingt berücksichtigt werden. Insbesondere sollten Alternativen angeboten werden, die nach wie vor funktionieren.

Leider sehe ich hier selbst nicht ganz klar. ☹

Gruß - Max-Ulrich

Max-Ulrich Farber schrieb:

Seit Ubuntu 9.10 ist wegen Upstart die Verwendung von rc.local deprecated, bzw. sie funktioniert gar nicht mehr.

Bei mir (10.04) funktioniert sie. Veränderungen habe ich nicht vorgenommen.

Grüße
Thomas

Ich nehme an, rc.local wird verwendet, wenn vorhanden bzw. nicht nur auskommentierte Zeilen drin stehen. Ähnlich wie xorg.conf.

Bei mir gibt es unter 10.04 auch keine Probleme.

Vermutlich ist das Problem, dass es wohl keinen definierten Zeitpunkt mehr gibt, zu dem rc.local beim Boot-Vorgang ausgeführt wird (??). Denn verschiedentlich wurde berichtet, dass z.B. Einträge wie

sleep 20
mount -a

mit denen früher "nachgemountet" wurde, wenn beim Abarbeiten der smb.conf das Netzwerk noch nicht stand, nun ohne Wirkung sind.

Ich habe nun etwas gegoogelt und festgestellt, dass es doch in fast allen Fällen, in denen mit rc.local neue Probleme auftraten, eine "konventionelle" Lösung ohne Upstart-Job gab. Ich komme mit dem Nebeneinander von "init"-Methode und Upstart nicht klar.

Die Frage ist wohl: Ist rc.local ein Auslaufmodell, das zwar noch läuft, aber ganz durch Upstart-Jobs ersetzt werden soll? Und läuft es jetzt umso unzuverlässiger, je mehr von init auf Upstart umgestellt wurde? Oder kann/soll es bleiben?

Gruß - Max-Ulrich

Ich bin der Sache jetzt noch etwas weiter nachgegangen.

Man findet zwar verschiedentlich die Aussage, dass rc.local "deprecated" ist, auch bei anderen Distributionen. Es wird aber in Ubuntu 10.04 ohne Änderung nach wie vor ausgeführt (deprecated heißt ja nicht außer Funktion). Wenn einige Scripts in rc.local Ärger machen, hat dies offenbar andere Ursachen. Ganz klar ist das alles aber nicht. Denn eine Ausführung, die an einen Zeitpunkt und nicht an ein Event gebunden ist, passt nicht recht zu Upstart.

Tatsache ist, dass man sich wegen der evtl. veränderten Boot-Reihenfolge nicht mehr allgemein darauf verlassen kann, dass bisher gültige Empfehlungen für Einträge in rc.local nach wie vor problemlos laufen. Man muss dies jeweils im Einzelfall prüfen.

Entgegen meiner ursprünglichen Absicht bin ich jetzt der Ansicht, man sollte den Artikel doch zumindest vorerst unverändert lassen bis alle Auswirkungen von Upstart wirklich klar sind.

Gruß - Max-Ulrich

Hallo,

Ganz klar ist das alles aber nicht. Denn eine Ausführung, die an einen Zeitpunkt und nicht an ein Event gebunden ist, passt nicht recht zu Upstart.

Upstart parallelisiert Dinge beim Systemstart, hält aber AFAIK immer noch die "Reihenfolge" ein. Heißt: rc.local zum Schluss. Warum jetzt bestimmte Sachen bei dir nicht funktionieren - keine Ahnung. Du kannst dir aber auch sonst selber einen Upstart-Job schreiben... 😉

Gruß, noisefloor

Warum jetzt bestimmte Sachen bei dir nicht funktionieren - keine Ahnung.

Ist nicht bei mir, dass es nicht funktioniert. Verschiedene Benutzer haben sich im Forum beklagt, dass der Automount von Netzwerk-Freigaben mittels fstab nicht mehr funktioniert und auch nicht durch das im Wiki beschriebene Workaround (Verzögerung durch Eintrag in rc.local) zum Tun zu bringen ist.

Ich selbst mache den Automount bei Netzwerk-Freigaben längst nicht mehr über fstab, sondern durch ein "Post-connection Script" in Wicd. Das klappt einwandfrei und braucht kein rc.local, auch keinen Upstart-Job 😉

Upstart parallelisiert Dinge beim Systemstart, hält aber AFAIK immer noch die "Reihenfolge" ein.

Ganz so einfach ist es offenbar nicht, wenn ich es richtig verstanden habe.

Gruß - Max-Ulrich

Seit Ubuntu 9.10 ist wegen Upstart die Verwendung von rc.local deprecated, bzw. sie funktioniert gar nicht mehr.

Mir ist das Problem eigentlich nicht klar, da ich zwischen Upstart und rc.local bisher keinen direkten Zusammenhang gesehen hatte. Bisher bin ich davon ausgegangen, das der Inhalt von rc.local einfach am Ende des eigentlichen Boot Prozesses dranngehängt wird. Das hatte ich bisher bei meinen Servern (8.04) dafür ausgenutzt um die Betriebsbereitschaft über den Piezo-Piepser oder Lautsprecher anzuzeigen. Mir ist aber völlig unklar, wie man sowas über Upstart realisieren könnte. Ich sehe da keine 1:1 Entsprechung.

Ich sehe nicht ganz klar. Deshalb bin ich nicht sicher, keinen Unsinn zu sagen.

Bisher bin ich davon ausgegangen, das der Inhalt von rc.local einfach am Ende des eigentlichen Boot Prozesses dranngehängt wird.

Das ist AFAIK immer noch so. Das Problem ist wohl, dass wegen der Event-bezogenen Arbeitsweise das Ende des eigentlichen Bootprozesses nicht mehr klar definiert ist. Upstart bleibt sozusagen aktiv und kann den Bootprozess jederzeit fortsetzen bzw. vervollständigen.

In http://www.galileocomputing.de/artikel/gp/artikelID-343 (leider nicht mehr aktuell) steht folgende Erklärung:

Upstart (http://upstart.ubuntu.com) ist der Name eines völlig neuartigen Konzeptes, welches eine völlige Abkehr von init darstellen soll. Die bisherigen Konzepte haben eines gemeinsam: sie sind zielorientiert. Dies bedeutet, dass vorher festgelegt wird, welche Dienste am Ende des Startvorganges laufen sollen. Die Abhängigkeiten werden vorher in einer sinnvollen Reihenfolge definiert. Upstart hingegen soll ereignisorientiert sein. Bei dieser Vorgehensweise lauern die Dienste im Hintergrund und starten erst dann, wenn alle Vorbedingungen erfüllt sind. Dies sind die so genannten Events. Beispiel: Wenn Sie einen USB-Stick an den Rechner stecken, löst dies ein Event aus, welches dazu führt, dass der USB-Stick gemountet wird.

Dieser Artikel ist etwas aktueller.

Wenn das so ist, kann ich mir vorstellen, dass etwas auch mal hinter rc.local geraten könnte, was normalerweise davor gehört.

Ich suche eben nach Erklärungen dafür, dass hier offenbar sporadisch Probleme auftreten, die nicht sicher reproduzierbar sind, mit denen man aber trotzdem rechnen muss.

Gruß - Max-Ulrich

Hi,

auf keinen Fall läuft rc.local zuverlässig immer als letzter Schritt im Bootvorgang. Ich würde eher von "Race Condition" oder schlicht Zufall sprechen. Es hängt davon ab wie schnell die Maschine insgesamt bootet.

Der Mechanismus ist, daß der ganze /etc/rc2.d/*-Kladderadatsch vom Upstart-Job /etc/init/rc-sysinit.conf aufgerufen wird. Dieser läuft los wenn folgende Bedingungen erfüllt sind

start on filesystem and net-device-up IFACE=lo

D.h. also wenn alle lokalen Dateisysteme und das Loopback-Netzwerkinterface da sind. Eine weitere Synchronisation mit dem Rest der Upstart-Jobs findet nicht statt.

Am besten schaut man es sich mit Bootchart an. Dazu sollte aber in rc.local etwas ausgeführt werden, sonst sieht man nix.

Braucht man für die Statements in rc.local weitere Voraussetzungen, sollte man eher eine Lösung wählen, wie ich sie in Trackpoint beschrieben habe. Dort war übrigens das Problem, daß /sys zwar gemountet ist (s.o.), aber die Inhalte noch nicht alle da.

@linrunner

Danke. Dann liege ich mit meinen Vermutungen doch nicht ganz daneben. Doch Du kennst Dich da offenbar besser aus als ich und siehst die Zusammenhänge klarer.

Könntest Du bitte mal den Artikel rc.local ansehen, ob man diesen jetzt mal so stehen lassen kann, oder ob man ihn im Hinblick auf Ubuntu 9.10 und 10.04 ändern muss ❓

Ausgangspunkt meiner Zweifel war der Artikel Baustelle/Samba Client cifs, den ich zur Zeit überarbeite. Dort werden für ein paar Automount-Probleme Lösungen mittels rc.local vorgeschlagen, die nach Aussagen von Benutzern nicht mehr funktionieren. Beim Überprüfen haben sie mal funktioniert und mal auch nicht. Ich sehe mich im Moment außer Stande, hier klare Aussagen zu machen oder sichere Alternativen vorzuschlagen.

Ich weiß nicht, ob man überhaupt - ganz abgesehen von rc.local - noch zu einem Automount von Netzwerk-Freigaben (Samba oder NFS) über /etc/fstab raten darf. Persönlich mache ich es schon länger nicht mehr so.

Gruß - Max-Ulrich

Ich würde an rc.local nichts ändern. Dort steht nirgends etwas davon, daß rc.local am Ende des Bootvorgangs läuft. Man könnte ellenlange Warnhinweise aufnehmen, was alles nicht geht. Aber was soll das bringen? Verwirrt nur den Leser. Es kann nur jeder selbst prüfen welche Voraussetzungen die eigenen Kommandos haben.

Das gilt insbesondere für Wiki-Artikel die etwas in die rc.local einbauen wollen. Da sollte m.E. der Verfasser prüfen, ob es in diesem Umfeld funktioniert oder eben eine andere Lösung aufnehmen.

Was die Netzwerk-Mounts betrifft: ich hab zwar keine Erfahrung damit, aber wenn, dann gehören sie in die fstab. Da gibt es einen (temporären) Dämon /sbin/mountall, aus /etc/init/mountall.conf gestartet, der sich um alles kümmern soll. Bei jedem neuen Interface wird er zudem per /etc/init/mountall-net.conf erneut angeschubst. Soweit die Theorie.

Danke für die Erklärungen.

Bei jedem neuen Interface wird er zudem per /etc/init/mountall-net.conf erneut angeschubst.

Gilt das auch, wenn das Interface - wie es jetzt Standard ist - durch den NetworkManager gestartet wird? Der NetworkManager startet ja erst beim Einloggen des Benutzers. Irgendwie funktioniert das einfach nicht richtig. Oder wenigstens nicht zuverlässig.

Gruß - Max-Ulrich

Jein. Ethernet wird vom NM vorher gestartet, WLAN wg. der Schlüssel jedoch nicht. Bei der Benutzeranmeldung läuft mountall natürlich längst nicht mehr, auch wenn beim Start eines Interfaces stets /etc/networking/if-up.d/upstart gerufen wird.

Ich würde es vielleicht mal mit einem eigenen Skript unterhalb von /etc/networking/if-up.d/ probieren, dabei wären aber das lo-Interface und bereits gemountete Shares entsprechend selbst zu filtern.