☰

Versuch, Tomcat 8 mit Gitlab-Runner neu zu starten, PID-Datei erstellt, Protokoll leer, Server nicht gestartet

tag-icon • tag-icon tomcat gitlab continuous-integration
Versuch, Tomcat 8 mit Gitlab-Runner neu zu starten, PID-Datei erstellt, Protokoll leer, Server nicht gestartet

Ich versuche, meinen Tomcat 8-Server nach der Bereitstellung neu zu starten.

Aufstellen:

gitlab-runner läuft mit seinem eigenen Benutzer (genannt gitlab-runner)

Tomcat verwendet einen eigenen Benutzer namens Tomcat

  1. sudoers hat einen Eintrag, sodass gitlab-runner ein Skript ausführen kann: gitlab-runner ALL=(tomcat) NOPASSWD: /home/tomcat/deploy.sh

  2. Das Bereitstellungsskript kopiert einfach eine Datei in das Webapps-Verzeichnis, fährt TomAct herunter und startet es neu:

cd /home/tomcat/bin sh catalina.sh stop -force ... sh catalina.sh start

Wenn ich das Skript manuell als Gitlab-Runner-Benutzer ausführe, funktioniert alles einwandfrei:

  1. sudo -u tomcat /home/tomcat/deploy.sh

Wenn der Job jedoch vom gitlab-ci-multi-runner gestartet wird (mit einem Push in das Gitlab-Repository), geschieht Folgendes. Der gitlab-runner schreibt grundsätzlich ein script.sh, das dann denselben Befehl wie oben ausführt.

  1. Normalerweise sehe ich beim Starten von Tomcat die folgende Ausgabe: Zum Herunterfahren:

Using CATALINA_BASE: /home/tomcat/ Using CATALINA_HOME: /home/tomcat/ Using CATALINA_TMPDIR: /home/tomcat/temp Using JRE_HOME: /usr Using CLASSPATH: /home/tomcat/bin/bootstrap.jar:/home/tomcat/bin/tomcat-juli.jar Using CATALINA_PID: /home/tomcat/bin/catalina.pid

Für den Start: Using CATALINA_BASE: /home/tomcat/ Using CATALINA_HOME: /home/tomcat/ Using CATALINA_TMPDIR: /home/tomcat/temp Using JRE_HOME: /usr Using CLASSPATH: /home/tomcat/bin/bootstrap.jar:/home/tomcat/bin/tomcat-juli.jar Using CATALINA_PID: /home/tomcat/bin/catalina.pid Existing PID file found during start. Removing/clearing stale PID file. Tomcat started.

Wenn ich es mit dem Gitlab-Runner starte, gibt es keine Ausgabe zum Herunterfahren, sondern der Server fährt herunter. Das funktioniert tatsächlich.

Nur für den Start Tomcat started..

  1. Es wird eine PID-Datei mit einer darin enthaltenen PID erstellt, aber der Prozess existiert nicht.

  2. Es werden Protokolldateien erstellt, sie sind jedoch leer.

Wenn ich den Server im Debugmodus starte, sh catalina.sh jpda startenthält die Datei log/catalina.out nur eine Zeile:tomcat Listening for transport dt_socket at address: 8080

Ich dachte, die Umgebung sei anders, also habe ich mit dem envcmd nachgeprüft. Alles ist gleich, außer wenn TERM=unknownes vom Gitlab-Runner gestartet wird.

Haben Sie Hinweise, was im Hintergrund passieren könnte, oder nur Dinge, die ich testen könnte?

gitlab-runner ist Open Source und das Skript, das das Build-Skript startet, ist dieses:https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/executors/shell/executor_shell.go#L36

Antwort1

Ich habe endlich eine Lösung gefunden, die funktioniert.

Für das Problem, dass die Umgebungsvariablen nicht angezeigt werden, verweise ich auf Folgendes:https://bz.apache.org/bugzilla/show_bug.cgi?id=37848 Der Gitlab-Runner hat kein TTY, daher wird keine Ausgabe angezeigt.

Die Ursache für den fehlerhaften Start ist folgende: Im Quellcode des Gitlab-Runners findet man Folgendes:https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/blob/master/executors/shell/executor_shell.go#L84

Sobald der Gitlab-Runner fertig ist, beendet er grundsätzlich alle verbleibenden Prozesse. Das bedeutet, dass der Server in meinem Fall tatsächlich eine kurze Zeit lang lief, bevor der Prozess beendet wurde. Deshalb habe ich leere Protokolldateien erhalten.

Ich habe das Problem gelöst, indem ich einfach ein Init-Skript zum Starten und Herunterfahren von Tomcat geschrieben habe. Der Tomcat hat jetzt seinen eigenen Benutzer (und seine eigene Gruppe). Jetzt wird der Tomcat-Prozessbaum von /sbin/init initiiert. Jetzt ist sich gitlab-runner dieses Prozesses nicht mehr bewusst oder kann ihn nicht beenden. In beiden Fällen läuft der Tomcat weiter, nachdem der Runner gestoppt wurde.

Antwort2

Es reicht aus, Ihren Prozess einfach abzulehnen, zum Beispiel Tomcat (schreiben Sie dies in Ihr .gitlab-ci.yml):

deploy_to_tomcat:
  stage: deploy
  script:
    - sudo /opt/apache-tomcat-7.0.77-dbservice/bin/startup.sh &
    - disown

verwandte Informationen