Start Dämon auf Remote-Server über Jenkins SSH-Shell-Skript auf mysteriöse Weise

Ich habe einen Build-Job auf Jenkins, die mein Projekt erstellt und nachdem es fertig ist, öffnet es ein SSH-Shell-Skript auf einem Remote-Server und überträgt Dateien und dann stoppen und Startet einen Daemon.Start Dämon auf Remote-Server über Jenkins SSH-Shell-Skript auf mysteriöse Weise

Wenn ich den Daemon über die Befehlszeile auf einem RHEL-Server stoppe und starte, wird er problemlos ausgeführt. Wenn der Job in Jenkins ausgeführt wird, gibt es keine Fehler.

Der Daemon stoppt gut und es beginnt gut. Aber kurz nach dem Start stirbt der Dämon plötzlich.

sudo service daemonName stop 
# transfer files. 
sudo service daemonName start

Ich bin sicher, dass das Problem nicht

Pathing ist

Weiß jemand, was über die Art und Weise etwas Besonderes sein könnte Jenkins den SSH-Shell-Skript ausgeführt wird, dass der Daemon startet nicht vollständig abgeschlossen verursachen würde?

Quelle

2013-05-21 Eric

Haben Sie die Protokolle überprüft? Welche Fehler liest du da drin? – fedorqui

die jenkins logs? oder die Konsolenprotokolle? oder die Logs des Daemon? Die Konsolenprotokolle zeigen, dass alles erfolgreich war. Die Protokolle des Daemon zeigen keine Probleme Die jenkins log Ich Zweifel werden hilfreich sein. – Eric

Vielleicht ist der Daemon nicht ordnungsgemäß dämonisiert, haben Sie versucht, dem Shell-Skript in Jenkins ein 'sleep 10000' hinzuzufügen, um zu sehen, ob es länger läuft, wenn die aufrufende Shell nicht geschlossen ist? Haben Sie versucht, die Ausgabe von "env" in Jenkins und der Shell zu vergleichen? Wenn es sich um einen selbstgewachsenen Daemon handelt, kann dies durch Dinge wie das Gebietsschema beeinflusst werden. –

Das Problem: Wenn ein Build durch jenkins ausgeführt wird, um den Befehl der Daemon-Prozess zu starten war eindeutig erfolgreich ausgeführt wird, noch nach dem Build-Job wurde gemacht, der Daemon würde plötzlich aufhören.

Die Lösung: Ich dachte für die ganze Zeit, dass es Jennkins war, der den Dämon tötete. Also habe ich viele verschiedene Inkarnationen und Permutationen ausprobiert, um das ProcessTree-Modul zu deaktivieren, das Zombie-Kind-Prozesse durchläuft und aufräumt. Ich versuchte es zu täuschen, indem ich die Umgebungsvariable BUILD_ID zurücksetzte. Nichts hat geklappt.

Dank dieses Threads fand ich heraus, dass diese Lösung nur für untergeordnete Prozesse funktioniert, die auf der BUILD-Maschine ausgeführt werden. I.E. Nicht anwendbar auf mein Problem.

Weitere Suche führte mich hier: Run a persistent process via ssh

Die Lösung? Nohu.

So nun der Build erfolgreich startet den Daemon durch Ausführen der folgenden Schritte aus: sudo nohup Service daemonname starten

Quelle

2013-06-07 21:51:09 Eric

nohup hat mich auch gerettet ... aber seltsamerweise hat es nicht funktioniert, als ich '&' am Ende der Zeile angehängt habe. Ich musste '&' weglassen, damit der Skriptaufruf funktioniert. – noumenon

Jenkins überwacht Prozesse, die durch den Job ausgelöst werden, und tötet sie, um Zombieprozesse zu vermeiden. Siehe https://wiki.jenkins-ci.org/display/JENKINS/ProcessTreeKiller

Die Abhilfe ist die BUILD_ID Umgebungsvariable außer Kraft zu setzen:

BUILD_ID=dontKillMe

Quelle

2013-05-21 19:05:54 rcomblen

Okay, ich habe das in vielen verschiedenen Inkarnationen versucht, aber es scheint nicht zu funktionieren.Ich habe versucht, die Flagge Hinzufügen den Prozessbaum Killer auszuschalten, ich habe versucht, die Build-ID in dem ssh-Skript zu ändern, ich bin Ausführung build_ID = dontKillMe sudo-Dienst startet Servicenamen in einem „auszuführen ist Shell Skript auf Remote-Host über ssh " Mache ich etwas falsch? – Eric

ok, sieht aus wie ich falsch gelesene Frage. Der Prozess three killer läuft nur auf dem jenkins-Knoten (oder den verbundenen Slaves), aber nicht auf dem entfernten Rechner, also muss das Problem an anderer Stelle liegen. – rcomblen

Ich bin froh, dass du es getan hast, deine Antwort hat nur einen Tag lang Kopfschmerzen von mir gelöst. Danke =) –

Start Dämon auf Remote-Server über Jenkins SSH-Shell-Skript auf mysteriöse Weise

Antwort

Verwandte Themen