CCU-Historian auf Debian: Autostart funktioniert nicht

[Wastl]

Hallo zusammen, ich wurde erst gestern mit der Nase auf den CCU-Historian gestoßen und bin einerseits begeistert von dem tollen Tool und zugleich entrüstet, dass ich da nicht früher selbst drauf gekommen bin. Vorweg: Tolle Arbeit des/der Entwickler und auch die umfangreiche Doku ist zwar teils hakelig zu lesen, aber das haben technische Dinge nunmal so an sich.
Was ich der Doku leider nicht entnehmen konnte, aber das Internet ist ja voll davon, wie man das Programm automatisch startet und einfach head- und seamless laufen lassen kann. Und da beginnt nun mein Problem:
Starte ich den CCU-Historian "normal" durch aufruf der jar mit der config, läuft er so wie man sich das wünscht. In der Form kann ich das aber nicht dauerhaft nutzen, da es auf einem virtuellen Debian-Server (headless, Zugriff per SSH) läuft und das Programm somit beendet wird, sobald ich die Konsole wieder verwenden möchte bzw, schließe.
Den Autostart habe ich vermeintlich so eingerichtet, wie es viele hier getan haben: altbekanntes Script in /etc/init.d angelegt und per update-rc hinzugefügt. Rufe ich nun das Script auf durch "sudo /etc/init.d/ccu-historian start" um das Programm zustarten, so scheint dies zunächst zu funktionieren, so zumindest die Ausgabe auf der Konsole. Rufe ich dann die Website auf, so läuft zwar der Webserver, quittiert aber mit 404. Auch werden keine Logfiles durch CCU-Historian erstellt, was ich in der Config zur Fehlersuche aktiviert habe. Gleichzeitig lässt sich beobachten, dass der Arbeitsspeicher zusehends vollläuft ... offenbar open End, ich habe bei 20 GB abgebrochen. Auch nach setzen des "stop"-Signals wächst der Arbeitsspeicher weiter an. Erst ein Reboot (ohne Autostart) hilft da heraus.
Was kann ich tun bzw. was habe ich bereits falsch gemacht?

Rahmenbedingungen:
Aktueller Debian-Server, Zugriff nur per SSH
Aktuelles CCU-Historian
Auf dem Server läuft außerden Debmatic, Mosquitto und NodeRed. Der CCU-Historian-Webserver wurde entsprechend auf einen anderen Port konfiguriert

Vielen Dank und schöne Grüße,
Wastl

PS: Ich hab das Ganze jetzt auch nochmal auf einer frischen Debian-Installation gemacht, allerdings mit demselben Ergebnis. Einziger Unterschied ist, dass der RAM niedrig bleibt, der Webserver aber liefert ebenfalls 404

[Wastl]

OK vielleicht sagt folgende Auffälligkeit mehr aus:
wenn ich ins Installationsverzeichnis /opt/ccu-historian wechsle und ccu-historian dann von dort starte, funkioniert alles wie gewünscht.
von einem anderen Verzeichnis aus, z.b. ~/ , geht es nicht. der aufruf lautet dann:
sudo java -jar /opt/ccu-historian/ccu-historian.jar -config /opt/ccu-historian/ccu-historian.config
das Verhalten ist dann wie auch mit Autostart bzw. über das Script gestartet, also der Webserver meldet 404 zurück.

[Matthias K.]

Ich würde das über SystemD lösen, des Weiteren würde ich den CCU-Historian unter einem eigenen (nicht privilegierten) User laufen lassen.

• User ccuhistorian anlegen und dessen Homeverzeichnis auf das CCU-Historian-Verzeichnis legen (ich gehe hier davon aus dass das CCU-Historian-Verzeichnis "/opt/ccuhistorian" ist):

  Code: Alles auswählen

  useradd -d /opt/ccuhistorian -s /bin/bash ccuhistorian

• Besitzer und Gruppe des Verzeichnisses und allem darunter auf ccuhistorian ändern:

  Code: Alles auswählen

  chown -R ccuhistorian:ccuhistorian /opt/ccuhistorian

• Folgendes SystemD-Script als Datei "ccu-historian.service" in "/etc/systemd/system/" erstellen:

  Code: Alles auswählen

  [Unit]
  Description=CCU-Historian
  Requires=network.target
  After=network.target
   
  [Service]
  ExecStart=/usr/bin/java -jar ccu-historian.jar
  WorkingDirectory=/opt/ccuhistorian
  Type=simple
  User=ccuhistorian
  Group=ccuhistorian
   
  [Install]
  WantedBy=multi-user.target

• Service aktivieren und starten:

  Code: Alles auswählen

  systemctl enable ccu-historian.service
  systemctl start ccu-historian.service

Falls du nicht als root unterwegs bist musst du beim Anlegen natürlich entsprechend sudo verwenden.

Starten / Stoppen / Neustarten kannst du den CCU-Historian dann mittels der entsprechenden systemctl-Befehle, z.B. "systemctl restart ccuhistorian" oder "systemctl stop ccuhistorian".

[Mathias]

Mit SystemD ist natürlich die schönste Lösung.

Ich denke, dass das ursprüngliche Problem mit einem falschen Arbeitsverzeichnis zusammen hängt. Bevor der CCU-Historian aufgerufen wird, sollte in das Verzeichnis mit der ccu-historian.jar gewechselt werden. Dann sind auch alle Pfade zur Konfigurationsdatei, der Datenbank und den Web-Seiten korrekt.

Ansonsten müssen für folgende Konfigurationsoptionen absolute Pfade eingetragen werden: database.dir, database.backup, webServer.dir, logSystem.fileName und base.scriptDir. Beim Aufruf muss auch noch mit der Kommandozeilenoption -config ein absoluter Pfad zur ccu-historian.config angegeben werden. Also alles etwas komplizierter, aber geht auch.

[Wastl]

Danke für die Unterstützung!
Ich hatte in letzter Zeit leider nicht die Möglichkeit, mich darum zu kümmern. Inzwischen habe ich es mit eurer Hilfe aber zum Laufen gebracht. Es gab noch ein paar andere Hürden zu nehmen, letztlich aber nichts kompliziertes.
Umgesetzt habe ich es letztlich mit der sehr eleganten Methode von scorpionking via SystemD.

Ich habe CCU-Historian nun einen dedizierten Server gegeben, da es sehr komische Auswirkungen hatte, wenn ich es auf der Maschine laufen ließ, auf der Debmatic lief. Die Maschine hat sich dann, sobald CCU-Historian gestartet wurde, allen verfügbaren RAM eingeheimst, egal wieviel man ihr gegönnt hat. Auf der dedizierten Maschine werden quasi null Ressourcen belegt.
Zu beachten dabei waren 2 Kleinigkeiten:
- in der Config der CCU-Historian muss die eigene IP angegeben werden, sonst werden ausschließlich die Systemvariablen angezeigt.
- bei Ausführung mit einem eigenen User muss der Port des Webservers geändert werden, da die Ports unter 1024 nur root belegen darf.