shutdown: / run / initctl: Keine solche Datei oder Verzeichnis

10617
henje

Ich habe meinen Server auf Debian Wheezy aktualisiert und damit herumgespielt. Nach einer Weile wollte ich neu starten und bin auf den Fehler gestoßen

shutdown: /run/initctl: No such file or directory

Ich habe im Web gesucht und herausgefunden, dass initctl vom Emporkömmling kommt. Obwohl es nicht entsprechend der Eignung installiert ist und der serviceBefehl von sysvinit immer noch funktioniert. Ich freue mich über jede Hilfe.

4
Für mich funktioniert `reboot -f`, aber es ist keine wirkliche Lösung für die Situation. henje vor 9 Jahren 3
Danke für das `reboot -f`. Guter Tipp. Nach weiterem googeln soll ein harter Neustart das Problem beheben, hat es aber nicht. Ich habe auch `mkfifo / run / initctl` ausgeführt, wodurch der _No-Fehler dieser Datei oder des Verzeichnisses_ angehalten wird, das System aber immer noch nicht heruntergefahren wird. Ich bekomme jetzt `init: timeout öffnend / schreibe Steuerkanal / run / initctl`. Ich habe das soeben erstellte `/ run / initctl` mit dem auf meinem Arbeits-RPi verglichen, und sie sehen identisch aus:` prw ------- 1 root root 0 Jan 1 1970 / run / initctl`. Greenonline vor 9 Jahren 0
Ich fühle mich wie wir in der gleichen Situation sind, ich habe auch alles ausprobiert und immer noch kein Glück: D henje vor 9 Jahren 0
Ich weiß nicht, was Ihr Problem ist, aber meiner scheint darauf zurückzuführen zu sein, dass mein Server virtualisiert ist und kein verwalteter Server. henje vor 9 Jahren 0
Ich habe das Problem behoben. Meine ist auch eine virtuelle Maschine, die [qemu] (http://wiki.qemu.org/Main_Page) verwendet. Greenonline vor 9 Jahren 0

2 Antworten auf die Frage

4
JdeBP

Ich habe im Web gesucht und herausgefunden, dass initctl vom Emporkömmling kommt.

Diesen Fehler erhalten Sie bei der Recherche durch die Suchmaschine und nicht auf der manuellen Seite.

Der Name ist eigentlich /run/initctl. Upstart hat eine /sbin/initctl. Die zwei sind völlig verschiedene Dinge. Ersteres ist ein FIFO, der verwendet wird, um Steuerbefehle an Prozess Nr. 1 zu senden. Letzteres ist eine Programmdatei.

Ursprünglich würde (Linux-Klon von) System V initim Prozess Nr. 1 beim Booten einen FIFO-Namen erstellen /dev/initctl. Programme, die beispielsweise telinitdurch Öffnen dieses FIFOs und Schreiben von Nachrichten, die der Prozess Nr. 1 lesen würde, ausgeführt werden, werden ausgeführt.

Systeme wie Upstart, Joachim Nilsson finitund systemd stellen Kompatibilitäts-Shims bereit, die ein FIFO erstellen /dev/initctl, auf Nachrichten warten und die Befehle von System V-Konzepten in die Äquivalente finit / Upstart / systemd übersetzen. Werkzeuge, die davon ausgehen, dass das System V- initProgramm ausgeführt wird, können diesen FIFO jedoch weiterhin öffnen und Befehle schreiben. (Nicht alle Init-Systeme stellen solche Shims zur Verfügung. Wenn Sie die Debian System V- initLeute fragen, werden sie Ihnen sagen, dass dies eine schlecht dokumentierte interne API ist, die besagt, dass Programme, die nicht Teil des System V-Pakets sind, nicht wirklich sein sollten in erster Linie verwenden.)

Dann, vor ein paar Jahren, die Debian System V initentschieden Menschen, dass der FIFO von bewegen würde /dev/initctlzu /run/initctl. So änderten sie ihre initdort zu schaffen, und änderte alle Werkzeuge, die mit ihren kommen init- wie shutdown, halt, telinitund so weiter - es danach zu suchen.

Sie erzählten jedoch nur den Entwicklern eines der anderen Systeme. Wenn also keine System V- initSysteme das System verwalten, bieten sie meistens noch ihre Kompatibilitäts-Shim-FIFOs an /dev/initctl. Wenn Sie ein System V- initTool mit einem solchen Nicht-System V- initSystem mischen, versucht das Tool, den FIFO an seinem neuen Speicherort zu öffnen, während das System es an dem alten Speicherort bereitstellt.

Die Problemumgehung sollte jetzt offensichtlich sein: Ein schneller symbolischer Link macht den Trick. 

ln -s / dev / initctl / run / initctl
Und es dauert bis zum nächsten Neustart (wenn vermutlich einer das System in einer besseren Konfiguration neu gestartet hat, die init-Systeme nicht vermischt, und versucht, den FIFO selbst zu erstellen). Roger Leigh, einer der Betreuer des Debian System V- initPakets, hat dies 2012 hervorgehoben.

Beachten Sie, dass die Verwendung der System V- initTools nicht unbedingt erforderlich ist . Das Fehlen eines kompatiblen Shim-FIFOs auf vielen Init-Systemen ist keine große Sache. systemd, Upstart, nosh und andere Systeme alle neigen dazu, bieten ihre eigenen Versionen von Tools wie halt, reboot, telinitund so weiter, sowieso . Diese Tools sprechen die nativen Protokolle ihrer jeweiligen Systeme und verwenden den initctlFIFO überhaupt nicht. Die Shims von systemd sprechen die relevanten D-Bus-Protokolle an, um # 1 direkt zu verarbeiten. Die Shims von Upstart generieren direkt die relevanten Upstart-Ereignisse. Die Shims von nosh senden die relevanten Signale direkt an die Verarbeitung von # 1.

All das Fummeln in der anderen Antwort und den Kommentaren läuft auf zwei Punkte hinaus:

  • Wenn Sie mit einem /bin/bashProzess Nr. 1 anstelle eines tatsächlichen Init-Systems booten, wird es natürlichinitctl nirgendwo ein FIFO geben. Wie bereits erwähnt, ist es das init-System, das es erstellt. Von neuem. Bei jedem Bootstrap.
  • Und es ist das Init-System, das darauf reagiert. Durch das manuelle Erstellen des FIFOs wird der Server, der am Leseende des FIFO auf Nachrichtenmkfifo wartet, nicht auf magische Weise erstellt . Deshalb funktionieren die nachfolgenden Versuche der Hilfsprogramme, Nachrichten über den FIFO zu senden, nicht.

Wie Sie es geschafft haben, Debian 7 in einen Zustand zu bringen, in dem es die System V- initTools verwendet, aber zu diesem Zeitpunkt ein anderes init-System ausführt, ist ein anderer Fischkessel. Es ist durchaus möglich, dies zu tun, vor allem, wenn man sich gerade mit dem Wechseln von Init-Systemen befindet. Für Debian 7 war das wirklich nicht alles geregelt, und es gibt einige merkwürdige Zustände, in die ein System geraten kann. Es ist nicht alles glatt und auch in Debian 8 fertig. Zum Glück war das nicht deine Frage. ☺

Lesen Sie weiter

1
Greenonline

Ich hatte genau das gleiche Problem mit einem Raspbian-Wheezy, das ich mit einem RPi-Emulator auf Qemu laufe . Ich habe das Problem offenbar für mein spezielles Setup gelöst. Ob es bei Ihnen funktioniert, ist eine andere Sache. Ich hoffe, dass es geht. Ich werde ehrlich sein und sagen, dass ich nicht sicher bin, was das Problem war oder wie es behoben wurde, aber ich habe alles dokumentiert, was ich getan habe und keine Schritte verpasst.

Präambel

Ich hatte einen emulierten Raspberry Pi mit Qemu eingerichtet und dabei diese beiden Anleitungen verwendet 1 :

  1. Installieren von QEMU unter OS X und dann;
  2. QEMU - Raspberry Pi einfach simulieren (Linux oder Windows!)

Die Probleme erfahren

Beim ersten Booten qemumit dem Befehl (beachten Sie die Verwendung von init=/bin/bash)

qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw init=/bin/bash" -hda 2013-09-25-wheezy-raspbian.img

Sobald das System hochgefahren war, stellte ich wie das OP fest, dass der haltBefehl nicht ausgeführt werden konnte, und gab stattdessen den Fehler aus:

init: /run/initctl: No such file or directory

Ich lief dann (mit freundlicher Genehmigung von: Ich habe ein Fehler-Flag "init: / dev / initctl: keine solche Datei" erhalten )

mkfifo /run/initctl

Das hat den No such file or directoryFehler gestoppt, aber das System immer noch nicht heruntergefahren, stattdessen den Fehler ausgegeben

 init: timeout opening/writing control channel /run/initctl.

Ich verglich das /run/initctlsoeben erstellte, mit dem auf meinem Arbeits-RPi verwendeten, ls -l /run/initctlund sie sahen identisch aus:

prw------- 1 root root 0 Jan 1 1970 /run/initctl

Mögliche Lösung

Ich habe mit den Schritten des Guides trotzdem weiter gemacht, nachdem a reboot -f. Jetzt ist der nächste Schritt, wo der Fix aufgetreten ist, glaube ich. Ich begann das qemu RPi mit einem „normalen“ boot, das Weglassen desinit=/bin/bash

qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2013-09-25-wheezy-raspbian.img

Wheezy fuhr in die raspi-config. Ich habe lediglich das Kennwort und den Hostnamen des Pi-Benutzers geändert und das System neu gestartet. Ich habe dann das Qemu RPi erneut mit gestartet

qemu-system-arm -kernel kernel-qemu -cpu arm1176 -m 256 -M versatilepb -no-reboot -serial stdio -append "root=/dev/sda2 panic=1 rootfstype=ext4 rw" -hda 2013-09-25-wheezy-raspbian.img

Es wurde in den tty Login-Bildschirm gebootet. Ich habe mich angemeldet, bin gelaufen startx. Nach dem XStart bin ich gerannt sudo shutdown -h now. Es wurde heruntergefahren und wie erwartet ohne init:Fehler angehalten .

Fazit

Das Booten des (virtuellen) Geräts ohne das init=/bin/bashschien das Problem zu beheben. Ob dies das Äquivalent eines harten Stiefels war, der das Problem 2 beheben sollte, oder ob es eine Kombination aus dem mkfifound dem war reboot, bin ich nicht sicher. Nicht meine beste Antwort, die ich kenne, aber hoffentlich wird es helfen.

1 Es gibt viel zu viele Informationen, um im Falle eines Link-Todes zusammenzufassen. Das Setup ist jedoch für die Ausgabe des OP weitgehend irrelevant.

2 Entsprechend kann nicht neu gestartet debian und systemd-sysv, sysvinit: Probleme beim Neustart zwischen systemd-sysv und sysvinit Schalt

Verwandte Probleme