Wie kann ich die Runlevel-Initialisierung untersuchen?

929
shredding

Ich untersuche, warum ein Dienst (solr) nach dem Booten des Servers nicht gestartet wird (in diesem Fall eine Vagrant-Box, auf der Ubuntu 12.04 ausgeführt wird).

Das Skript läuft, wenn ich /etc/init.d/solr start ausführt

Ich führe Sudo Update-rc.d Solr Defaults Aber es läuft nicht nach dem Booten und ich weiß jetzt nicht, wie ich es untersuchen soll.

Was sind meine Debug-Optionen?

Das Skript:

#! /bin/sh ### BEGIN INIT INFO # Provides: solr # Required-Start: $all # Required-Stop: $all # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: Starts solr # Description: Starts solr using start-stop-daemon ### END INIT INFO  SOLR_HOME=/vagrant/solr/jetty DAEMON=/usr/bin/java DAEMON_OPTS='-jar start.jar' NAME=Solr DESC=Solr PID_FILE=/vagrant/solr/jetty/$NAME.pid SOLR_USER=vagrant SOLR_GROUP=vagrant  test -x $DAEMON || exit 1  set -e  . /lib/lsb/init-functions  case "$1" in start) echo -n "Starting $DESC: " if start-stop-daemon -d $SOLR_HOME --start -b -m --pidfile $PID_FILE --user $SOLR_USER --group $SOLR_GROUP --chuid $SOLR_USER --startas $DAEMON -- $DAEMON_OPTS then echo "solr started" >> /var/log/messages exit 0 else echo "solr start failed" >> /var/log/messages exit 1 fi ;; stop) echo -n "Stopping $DESC: " if start-stop-daemon --stop --pidfile $PID_FILE then echo "stopped." exit 0 else echo "failed." exit 1 fi ;; restart|force-reload) $ stop sleep 0.5 $ start ;; status) status_of_proc -p $PID_FILE "$DAEMON" solr && exit 0 || exit $? ;; *) N=/etc/init.d/$NAME echo "Usage: $N " >&2 exit 1 ;; esac  exit 0

Ausgabe in / var / log / messages ist (zweimal!) solr started...

1
Eine Sache, die ich versuchen könnte, wäre das Hinzufügen eines Zeilenechos "laufender start-stop-daemon -d $ SOLR_HOME --start -b -m --pidfile $ PID_FILE --user $ SOLR_USER - group $ SOLR_GROUP --chuid $ SOLR_USER --startas $ DAEMON - $ DAEMON_OPTS ">> / var / log / messages und vergleicht es, wenn es von Hand ausgeführt wird und automatisch ausgeführt wird. davidgo vor 10 Jahren 0
Sie enden genau gleich: `laufender start-stop-daemon -d / vagrant / solr / jetty --start -b -m --pidfile /vagrant/solr/jetty/Solr.pid --user vagrant - vagrant - chuid vagrant - startas / usr / bin / java - -jar start.jar` shredding vor 10 Jahren 0
Könnte das Problem ein Unterschied in den Umgebungseinstellungen sein, auf die sich solr vielleicht stützt? Was wäre, wenn Sie eine "Echo" -Umgebungsdatei ausführen würden: /tmp/solr-env$$.dump; setze /tmp/solr-env$$.dump "im Startskript und vergleiche dann die verschiedenen Umgebungsdateien? davidgo vor 10 Jahren 0
Ich bin nicht sicher, was das macht, aber beim Start ist seine Umgebungsdatei: /tmp/solr-env3188.dump; set` und beim manuellen Start ist es die Umgebungsdatei: /tmp/solr-env3188.dump; set` shredding vor 10 Jahren 0
Der Schlüssel ist nicht der Dateiname, sondern der Inhalt. Der Befehl "set" zeigt die für die Shell verfügbaren Umgebungsvariablen an. Wenn Sie den Inhalt der Datei vergleichen, können Sie möglicherweise eine Schlüsseleinstellung herausfinden, die sich in den Umgebungen unterscheidet - und vermutlich etwas zur Kompensation ändern. Die Nummer am Ende der Datei ist nicht wichtig - es ist lediglich die Prozess-ID. Ich habe sie verwendet, damit Sie bei jeder Ausführung einen anderen Dateinamen erhalten. davidgo vor 10 Jahren 0

2 Antworten auf die Frage

0
davidgo

Es gibt einige Wege, um dieses Problem zu lösen, aber ich nehme an, dass sie alle auf dasselbe hinauslaufen.

Die Methode "Crude / Bare Metal" - Schauen Sie in / etc (idealerweise als root), und Sie finden eine Reihe von Verzeichnissen rcX.d sowie ein Verzeichnis "init.d".

Wenn Sie in ein Verzeichnis von rcX.d schauen, werden Sie feststellen, dass es voller Dateien ist, die mit /etc/init.d/filename verknüpft sind. Das "S" am Anfang der Datei bedeutet "Start". Die Nummer, die als nächstes erscheint, gibt an, dass die Bestelldateien ausgeführt werden sollen.

Wenn das Betriebssystem den Runlevel initiiert / ändert, führt es die gesamte Datei für diesen Runlevel aus, dh für Runlevel 2 wird /etc/rc2.d/S* ausgeführt. Wenn die Datei nicht mit einem Symlink versehen ist, wird sie nicht gestartet, wenn der Runlevel startet . Um den aktuellen Runlevel zu überprüfen, können Sie "Runlevel" eingeben, der den aktuell ausgeführten Runlevel zurückgibt.

Sie sind wahrscheinlich an Runlevels 2-5 interessiert - eine Liste der Runlevels finden Sie hier

Wenn Sie ein Programm zum entsprechenden Runlevel hinzufügen möchten, können Sie einfach den entsprechenden Symlink erstellen. Ich bevorzuge es jedoch, "chkconfig" zu installieren. Ich weiß nicht, ob dies eine Version des Redhat-Skripts ist (Syntax ist nicht kompatibel, aber sehr nahe) - aber mit diesem Befehl können Sie sehen und ändern, welche Programme auf Runlevels arbeiten.

chkconfig -l Zeigt alle Programme und ihre Runlevel an, und chkconfig -l progname zeigt Runlevel an, die für ein bestimmtes Programm aktiviert sind.

Um ein Programm für einen bestimmten Runlevel (oder für mehrere Runlevels) auszuführen, können Sie chkconfig progname Runlevels verwenden. Beispiel: chkconfig sshd 2345 stellt sicher, dass sshd ausgeführt wird, wenn Sie den Runlevel 2,3,4 oder 5 eingeben.

Wie beschrieben, führe ich sudo update-rc.d solr defaults aus und es wurden alle Einträge für mich erstellt. Ich überprüfe, es gibt Einträge wie `S20solr -> ../ init.d / solr` in allen Runlevel-Verzeichnissen. shredding vor 10 Jahren 0
0
mark

Das Problem ist, dass zum Zeitpunkt des Startens der init.d-Skripte /vagrant/nicht verfügbar / gemountet ist, Sie sich jedoch darauf verlassen, dass sie in Ihrem Skript vorhanden sind.

Siehe http://razius.com/articles/launching-services-after-vagrant-mount/ für einige Hinweise.

Verwandte Probleme