Wie debugge ich das alte initd-Skript unter systemd?

5147
Gene Vincent

Ich habe ein älteres initd-Skript, um meine Anwendung zu starten. Bei älteren SuSE-Versionen funktionierte dies einwandfrei, bei Open SuSE 12.3 schlägt dies jedoch fehl.

Das Merkwürdige ist

cd /etc/init.d ; ./script start

funktioniert gut.

/etc/init.d/script start

zeigt eine Umleitung zu systemctl an, startet jedoch nicht meine Anwendung (und auch keine Ausgabe des initd-Skripts).

Ich sehe keine Protokolleinträge, die mir zeigen, was schief geht. Der einzige Eintrag, den ich sehe, ist in / var / log / messages, dass die Anwendung gestartet wurde.

Wie debugge ich das?

5
check this out http://0pointer.de/blog/projects/systemd-for-admins-3.html Alex vor 11 Jahren 2

3 Antworten auf die Frage

2
Otheus

Einige Sachen.

  1. Führen Sie den Befehl in einer sauberen Umgebung aus: 

    env -i PATH=/usr/sbin:/sbin:/usr/bin:/bin /etc/init.d/SCRIPT start

  2. Aktivieren Sie anschließend das Shell-Debugging. Ein einfacher Weg, dies zu tun, ist mit:

    bash -x SCRIPT start

Kombinieren Sie die beiden, erhalten Sie:

 env -i PATH=/usr/sbin:/sbin:/usr/bin:/bin bash -x /etc/init.d/SCRIPT start

  1. Deaktiviert systemdden Kompatibilitätsmodus mit:

    SYSTEMCTL_SKIP_REDIRECT=true

Der Name dieser Variablen kann variieren. Dein Init-Skript enthält wahrscheinlich etwas

 . /etc/sysconfig/functions

Diese Datei prüft die obige Umgebungsvariable. (Suse ist ein bisschen anders als die auf RedHat basierenden Cousins, also YMMV).

Alle oben genannten kombinieren:

env -i PATH=/usr/sbin:/sbin:/usr/bin:/bin SYSTEMCTL_SKIP_REDIRECT=true \ bash -x /etc/init.d/SCRIPT start

Da die Ausgabe sehr umfangreich sein wird, fügen Sie Folgendes hinzu:

2>&1 | less -r +F

Das lessProgramm puffert die Ausgabe, sodass Sie die gesamte Historie zurückblättern können. Drücken Sie CTRL-Cdie Taste, um den "Follow" -Modus zu verlassen, zurück zu scrollen usw.

1
MariusMatutiae

Der Grund für das Verhalten dieses Skripts besteht darin, dass OpenSuse 12.3 das alte sysvinit durch systemd ersetzt hat, einen Systemverwaltungs-Daemn, der den gesamten Startvorgang steuert.

Das Format des Skripts, das die von systemd zu startenden Dienste beschreibt, unterscheidet sich von dem von sysvinit. Daher ist es kein Wunder, dass Ihr Skript fehlschlägt. Sobald das Skript richtig eingerichtet ist, ist die Bedienung über systemctl trivial:

sudo systemctl enable/disable your-service

Aktiviert oder deaktiviert es und normalerweise

sudo systemctl start/stop/status your-service

startet es, stoppt es, fragt seinen Status ab.

Ein typisches benutzerdefiniertes Serviceskript befindet sich im Ordner / etc / systemd / system, endet mit dem Suffix .service und hat das folgende Format:

 [Unit] Description=sdbarker.com Chiliproject Requires=mysqld.service nginx.service Wants=mysqld.service nginx.service  [Service] User=www-data WorkingDirectory=/path/to/chiliproject/install ExecStart=/usr/bin/bundle  PIDFile=/path/to/chiliproject/install/tmp/pids/server.pid  [Install] WantedBy=multi-user.target

Wie Sie sehen können, sind die meisten Einträge selbsterklärend. Ohne mehr über Ihr Skript zu wissen, kann ich Ihnen keine weitere Unterstützung anbieten. In dieser Seite finden Sie jedoch die Informationen, die Sie zum Schreiben eines geeigneten benutzerdefinierten Serviceskripts benötigen.

0
Mihai

In /etc/init.d/script befindet sich wahrscheinlich ein relativer Pfad, der außerhalb von /etc/init.d/ nicht relevant ist. Sie können den Inhalt des Skripts hier einfügen (sofern es nicht wirklich riesig ist).

Stellen Sie sicher, dass alle an Ihre Anwendung gesendeten Argumente keine relativen Pfade enthalten, da das Arbeitsverzeichnis der Anwendung das Verzeichnis ist, in dem sie gestartet wird.

Es ist kein Erholungspfad. Es hat damit zu tun, dass es ein Shell-Skript ist, das gestartet wird und eine endlose Schleife enthält. Gene Vincent vor 11 Jahren 0

Verwandte Probleme