staging.inyokaproject.org

Ich habe eine Applikation dies sich ohne installieren aus einem Verzeichnis starten lässt. Diese Anwendung muss automatisch gestartet werden. Dazu habe ich im entsprechenden Anwendungsverzeichnis eine .service Datei erstellt und mittels systemctl enable {Pfad-zur-service-Datei} installiert.

Dennoch ist die Service-Datei nach einem Neustart des Systems wieder deaktiviert. Ich vermute, dass die Festplatte zu spät gemountet wird. Zurzeit habe ich

[Unit]
RequiresMountsFor=/home/user/mountpoint

hinterlegt und dennoch scheint es nicht zu funktionieren.

Kann mir hier wer weiterhelfen?

Hallo!

Beschreibe bitte mal genauer: Was für ein Programm soll gestartet werden? Wie wird das ausgeführt? (Script, Executable, Interpreter-Umgebung nötig,…) Welche Umgebungsvariablen müssen bis dato gesetzt sein? Ist der Mountpoint lokal oder im Netz? Wie sieht deine Unit komplett aus?

Das service File ist in /home/user/Daten/Tools/LanguageTool/ abgelegt und wurde mit systemctl enable /home/user/Daten/Tools/LanguageTool/langagetool.service aktiviert. Das Device is eine zweite festplatte im Syste

fstab

UUID=e2732f9a-b45b-4a8e-639e-6201ca02d0ae /               ext4    errors=remount-ro 0       1
UUID=02c511ab-c08a-4bab-740f-f19861e63747 /home           btrfs   defaults,subvol=@home 0       2
UUID=ba497122-39dd-4d50-95dc-8ce8cec9aa97 /home/user/3  ext4    defaults        0       2

languagetool.service

[Unit]
Description=Rechtschreib Prüfung - Languagetool
After=network.target

[Service]
ExecStart=/usr/bin/java -cp '/home/user/Daten/Tools/LanguageTool/languagetool-server.jar' org.languagetool.server.HTTPServer --port 8081  --allow-origin '*' --languageModel '/home/user/Daten/Tools/ngrams/'
Restart=always
Type=simple
User=user
WorkingDirectory=/home/user/Daten/Tools/LanguageTool

[Install]
WantedBy=network.target

Serengeti schrieb:

Das service File ist in /home/user/Daten/Tools/LanguageTool/ abgelegt

Da gehört es nicht hin, sondern nach /etc/systemd/system/, wenn es als Systemdienst laufen soll.

und wurde mit systemctl enable /home/user/Daten/Tools/LanguageTool/langagetool.service aktiviert.

Das solltest du rückgängig machen und die Unit ordentlich aktivieren:

systemctl disable /home/user/Daten/Tools/LanguageTool/langagetool.service
systemctl enable --now langagetool.service 

Ich habe jetzt im ordner /home/user/Daten/Tools/LanguageTool/ dieses script erstellt um es mir etwas einfacher zu machen beim einrichten und modifizieren.

1
2
3
4
5
6
7
8

#! /bin/bash
SUDO=''
if [ $(id -u) != 0 ]; then
	SUDO='sudo'
fi

$SUDO cp -v "$PWD/languagetool.service" "/etc/systemd/system/"
$SUDO systemctl enable --now languagetool.service

Nun klappt alles wie gewünscht. Schade, dass es nicht über ein gemountetes Laufwerk hinaus verknüpft geht.

Serengeti schrieb:

Ich habe jetzt im ordner /home/user/Daten/Tools/LanguageTool/ dieses script erstellt um es mir etwas einfacher zu machen beim einrichten und modifizieren.

Wenn Du Dienste öfters aktivierst und deaktivierst, dann nutzt Du wahrscheinlich nicht das richtige Werkzeug.

1 2 3 4 5 6 7 8

#! /bin/bash SUDO='' if [ $(id -u) != 0 ]; then SUDO='sudo' fi $SUDO cp -v "$PWD/languagetool.service" "/etc/systemd/system/" $SUDO systemctl enable --now languagetool.service

Nun klappt alles wie gewünscht.

Das sieht aus, als ob Du ein Skript schreibst, um es exakt ein Mal auszuführen? Das kommt mir verschwenderisch vor.

Schade, dass es nicht über ein gemountetes Laufwerk hinaus verknüpft geht.

Es geht darum, dass Systemd definierte Verzeichnisse hat, wo die Units abgelegt werden müssen. Das hat nix mit dem Mounten zu tun.

rklm schrieb:

Das sieht aus, als ob Du ein Skript schreibst, um es exakt ein Mal auszuführen? Das kommt mir verschwenderisch vor.

Wenn ich Neuerungen an einem bestimmten PC einführe, die ich behalten möchte, dann schreibe ich diese in ein Install Script. Ich installiere mein PC inkl. home-verzeichnis jedes Jahr neu.

Damit verfolge ich zwei ziele. Zum ersten ich habe ich auf diesem PC immer ein frisch aufgesetztes System ohne Altlasten. Zum Zweiten ist das Script gleichzeitig mein Nachschlagewerk für neu gelernte Sachen. Wie jetzt die Bedienung für SystemD. Unter Linux muss ich nur erstaunlich selten etwas in der Konsole auf eine weise ändern, was ich schonmal machen musste, daher lerne ich kaum etwas durch Wiederholen. Die ersten fünf Zeilen meines Bash-Scriptes sind Standard für Dinge, die ich als Root machen muss und daher auch kein Aufwand.

Serengeti schrieb:

rklm schrieb:

Das sieht aus, als ob Du ein Skript schreibst, um es exakt ein Mal auszuführen? Das kommt mir verschwenderisch vor.

Wenn ich Neuerungen an einem bestimmten PC einführe, die ich behalten möchte, dann schreibe ich diese in ein Install Script. Ich installiere mein PC inkl. home-verzeichnis jedes Jahr neu.

Damit verfolge ich zwei ziele. Zum ersten ich habe ich auf diesem PC immer ein frisch aufgesetztes System ohne Altlasten. Zum Zweiten ist das Script gleichzeitig mein Nachschlagewerk für neu gelernte Sachen. Wie jetzt die Bedienung für SystemD. Unter Linux muss ich nur erstaunlich selten etwas in der Konsole auf eine weise ändern, was ich schonmal machen musste, daher lerne ich kaum etwas durch Wiederholen.

Ah, dann macht das natürlich Sinn.

Die ersten fünf Zeilen meines Bash-Scriptes sind Standard für Dinge, die ich als Root machen muss und daher auch kein Aufwand.

Bei mir sieht das immer so aus:

1
2
3
4
5

#!/bin/sh

[ $(id -u) -eq 0 ] || exec sudo "DEBUG=$DEBUG" "$0" "$@"

[ -z "$DEBUG" ] || set -x

Damit erreiche ich zweierlei:

• Das gesamte Skript wird immer als "root" ausgeführt. Das hat den Vorteil, dass die Authentifizierung unterwegs nicht flöten gehen kann. Wenn Du sudo bei einzelnen Kommandos aufrufst, kann es halt passieren, dass Du mittendrin Dein Passwort eingeben musst, wenn es mal wieder etwas länger dauert. Andererseits hat Dein Ansatz den Vorteil, dass Root-Rechte nur da vorliegen, wo sie auch gebraucht werden.

• Wenn man die Umgebungsvariable DEBUG setzt, gibt es Debug-Ausgaben. Man kann das auch für einen Aufruf machen DEBUG=y script arg. Da ich die überall verwende, erstreckt sich das Debugging dann auch auf andere aufgerufene Skripte, falls das der Fall sein sollte.