141986
21.10.2022, aktualisiert um 08:00:28 Uhr
4252
15
0
Ubuntu: Service startet nur bei manuellem Start?
Hallo Gemeinschaft,
ich stehe gerade etwas auf dem Schlauch und wünsche mir, dass mich wer von Euch davon runter schubst.
Ich habe Zoneminder auf ner Ubuntumöhre gepackt. Läuft soweit auch.
Nun ist es so, dass ich ein NAS Share unter /mnt/sdb1 gemountet habe. Auch das klappt, hilft aber vielleicht bei der Problemlösung. (Mountet vielleicht erst NACH dem der Dienst starten möchte?)
Das Problem:
Starte ich die Möhre neu startet der Dienst nicht mit.
bringt mir nach dem Login direkt:
Starte ich den Dienst via Hand () kommt die PW Abfrage des Users und wird anschließend problemlos ausgeführt.
Nun möchte ich gerne, dass der Dienst nach reboot automatisch mit startet.
Habe es per crontab versucht (), jedoch erfolglos.
Habt Ihr einen Hinweis für mich, wo meine Denkblockade dbzgl. liegt?
Solltet Ihr weitere Infos benötigen, lasst es mich bitte wissen.
Danke, guten Start in den Freitag.
Viele Grüße
Edita:
Service liegt in:
ich stehe gerade etwas auf dem Schlauch und wünsche mir, dass mich wer von Euch davon runter schubst.
Ich habe Zoneminder auf ner Ubuntumöhre gepackt. Läuft soweit auch.
Nun ist es so, dass ich ein NAS Share unter /mnt/sdb1 gemountet habe. Auch das klappt, hilft aber vielleicht bei der Problemlösung. (Mountet vielleicht erst NACH dem der Dienst starten möchte?)
Das Problem:
Starte ich die Möhre neu startet der Dienst nicht mit.
service zoneminder statusOkt 21 05:20:22 redacted systemd[1]: Dependency failed for ZoneMinder CCTV recording and surveillance system.
Okt 21 05:20:22 redacted systemd[1]: zoneminder.service: Job zoneminder.service/start failed with result 'dependency'. Starte ich den Dienst via Hand (
service zoneminder startNun möchte ich gerne, dass der Dienst nach reboot automatisch mit startet.
Habe es per crontab versucht (
@reboot service zonerminder startHabt Ihr einen Hinweis für mich, wo meine Denkblockade dbzgl. liegt?
Solltet Ihr weitere Infos benötigen, lasst es mich bitte wissen.
Danke, guten Start in den Freitag.
Viele Grüße
Edita:
Service liegt in:
/etc/systemd/system/multi-user.target.wants/zoneminder.servicecat /etc/systemd/system/multi-user.target.wants/zoneminder.service
# ZoneMinder systemd unit file
# This file is intended to work with Debian distributions
[Unit]
Description=ZoneMinder CCTV recording and surveillance system
After=network.target mysql.service mnt-sdb1.mount var-cache-zoneminder-images.mount var-cache-zoneminder-events.mount
# Remarked out so that it will start ZM on machines that don't have mysql installed
#Requires=mysql.service
Requires=mnt-sdb1.mount var-cache-zoneminder-images.mount var-cache-zoneminder-events.mount
[Service]
#User=www-data
Type=forking
ExecStart=/usr/bin/zmpkg.pl start
ExecReload=/usr/bin/zmpkg.pl restart
ExecStop=/usr/bin/zmpkg.pl stop
PIDFile=/var/run/zm/zm.pid
Restart=on-abnormal
[Install]
WantedBy=multi-user.target
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 4351937987
Url: https://administrator.de/forum/ubuntu-service-startet-nur-bei-manuellem-start-4351937987.html
Ausgedruckt am: 18.04.2025 um 05:04 Uhr
15 Kommentare
Neuester Kommentar
Hi,
versuche doch den Start über die /etc/rc.local. Diese Datei könntest du ganz zum Schluss ausführen lassen und dann sollte es gehen. Es gibt einiges an Dokus wie du das in Ubuntu wieder aktivierst.
Gruß
versuche doch den Start über die /etc/rc.local. Diese Datei könntest du ganz zum Schluss ausführen lassen und dann sollte es gehen. Es gibt einiges an Dokus wie du das in Ubuntu wieder aktivierst.
Gruß
Moin,
hast Du schonmal
versucht?
Gruß
Looser
hast Du schonmal
sudo update-rc.d zoneminder defaultsversucht?
Gruß
Looser
Das ist doch systemd, d.h. man sollte auch mit systemd-Befehl arbeiten.
Systemd unterscheidet zwischen dem Starten und dem Aktivieren eines Dienstes.
Zum direkten Starten gibt man das ein:
Zum Aktivieren das hier:
Muss man beides als "root" machen.
Wenn die "service"-Datei verändert wurde, MUSS man systemd neu laden:
Ein Herumfummeln an rc.local ist dabei nicht nur unerwünscht, sondern kann auch zu Fehlern führen.
Die Lösung von Looser27 mit dem "update-rc.d" entspricht dem übrigens teilweise. Denn "update-rc.d" ist für SystemV-Initsktipte zuständig. Die liegen meist unter "/etc/init.d". Wenn sowohl das "initd" als auch "systemd" installiert sind, wird so etwas wie eine Brücke benutzt, d.h. die systemd-Skripte werden über den Umweg von initd gestartet (ist auf einigen Debian und RHEL so konfiguriert, damit beides noch läuft).
Generell sollte man alle systemd-Skripte nur per "systemctl" verwalten. Hier mal ein wenig Blabla dazu: https://www.digitalocean.com/community/tutorials/systemd-essentials-work ...
Systemd unterscheidet zwischen dem Starten und dem Aktivieren eines Dienstes.
Zum direkten Starten gibt man das ein:
systemctl start zoneminderZum Aktivieren das hier:
systemctl enable zoneminderMuss man beides als "root" machen.
Wenn die "service"-Datei verändert wurde, MUSS man systemd neu laden:
systemctl daemon-reloadEin Herumfummeln an rc.local ist dabei nicht nur unerwünscht, sondern kann auch zu Fehlern führen.
Die Lösung von Looser27 mit dem "update-rc.d" entspricht dem übrigens teilweise. Denn "update-rc.d" ist für SystemV-Initsktipte zuständig. Die liegen meist unter "/etc/init.d". Wenn sowohl das "initd" als auch "systemd" installiert sind, wird so etwas wie eine Brücke benutzt, d.h. die systemd-Skripte werden über den Umweg von initd gestartet (ist auf einigen Debian und RHEL so konfiguriert, damit beides noch läuft).
Generell sollte man alle systemd-Skripte nur per "systemctl" verwalten. Hier mal ein wenig Blabla dazu: https://www.digitalocean.com/community/tutorials/systemd-essentials-work ...
1
https://zoneminder.readthedocs.io/en/stable/installationguide/ubuntu.htm ...
Step 8:
Eigentlich ist in der Doku alles drin. :-p
Step 8:
systemctl enable zoneminder
systemctl start zoneminderEigentlich ist in der Doku alles drin. :-p
Wer liest denn schon Dokus? 
Hrm,
soltle eigentlich implizieren, dass ich das
durchgekaut habe, bevor ich mich hier zum Ei mache.
Mit anderen Worten:
Grüße
Edita:
Starte ich die Möhre neu startet der Dienst nicht mit.
service zoneminder status
bringt mir nach dem Login direkt:
service zoneminder status
bringt mir nach dem Login direkt:
soltle eigentlich implizieren, dass ich das
systemctl enable zoneminder
systemctl start zoneminderdurchgekaut habe, bevor ich mich hier zum Ei mache.
Mit anderen Worten:
Eigentlich ist in der Doku alles drin. :-p
bin ich so durch gegangen. Wer liest denn schon Dokus? face-wink
Nc.Grüße
Edita:
Ein Herumfummeln an rc.local ist dabei nicht nur unerwünscht, sondern kann auch zu Fehlern führen.
Können super gerne herausfinden, wieso der Dienst nicht automatisch gestartet ist via systemctl. Wäre mir sogar ganz recht.sondern kann auch zu Fehlern
Auf dem Srv läuft ein Dienst drauf.. und der startet anscheinend recht robust nach dem Neustart. Würde mich jetzt nicht ultra traurig machen, wenn wir/ich es dabei belassen.
Nur kurz zur "rc.local"-Lösung: das ist ein normales Skript, was bei den meisten neueren Linuxen erst einmal auf "deaktiviert" steht. Es wird nämlich beim Start direkt und seriell aufgerufen. Also nicht parallel. Was bedeutet, dass wenn rc.local hängt, der Rechner nicht mehr hochfährt.
Andererseite kann auch das normale Herunterfahren beeinträchtigt werden, wenn in rc.local Dinge gestartet werden, die z.B. "Kanäle" (TTY und son Zeugs) nutzen und blockieren. Dann hängt die Kiste beim Runterfahren so lange, bis der Rechner in einen Timeout läuft und die Prozesse zwangsweise abschiesst (kann 5 Minuten dauern).
Oder man vergisst das "exit 0" am Ende von rc.local, womit das System dann denkt, dass rc.local in einen Fehler gelaufen ist und nicht startet.
Oder rc.local hat nicht das "+x"-Bit gesetzt oder nach einem Systemupdate ist das Bit wieder weg oder oder oder...
Also lieber 10 Zeilen tippen, um eine eigene systemd-Servicedatei zu bauen, was ein Skript zuverlässig und in Abhängigkeiten z.B. vom Runlevel aufruft, als das unsichere rc.local. Die kurze Arbeit lohnt sich.
Andererseite kann auch das normale Herunterfahren beeinträchtigt werden, wenn in rc.local Dinge gestartet werden, die z.B. "Kanäle" (TTY und son Zeugs) nutzen und blockieren. Dann hängt die Kiste beim Runterfahren so lange, bis der Rechner in einen Timeout läuft und die Prozesse zwangsweise abschiesst (kann 5 Minuten dauern).
Oder man vergisst das "exit 0" am Ende von rc.local, womit das System dann denkt, dass rc.local in einen Fehler gelaufen ist und nicht startet.
Oder rc.local hat nicht das "+x"-Bit gesetzt oder nach einem Systemupdate ist das Bit wieder weg oder oder oder...
Also lieber 10 Zeilen tippen, um eine eigene systemd-Servicedatei zu bauen, was ein Skript zuverlässig und in Abhängigkeiten z.B. vom Runlevel aufruft, als das unsichere rc.local. Die kurze Arbeit lohnt sich.
Nur kurz
Jo, Danke.seriell aufgerufen
Vermutlich ist genau das, was bei mir fehlschlug. Ich tippe darauf, dass die Dienste (f.e.: sql, mount, ..) noch nicht verfügbar waren und somit mein gebauter Dienst nicht startet, da Er kurz nach dem vollständigen Boot per Hand problemlos startet. Trotz AfterAnders kann ich es mir jeden Falls aktuell nicht erklären. Leider gibt das Errorlog so gut wie nichts her.
exit 0
Ja gut, ist ja meistens so. Baut man es nicht fertig, funktioniert es meistens nicht so wie gewollt ;)+x
Guter Einwand, werde ich abfangen können. Danke.Also lieber 10 Zeilen tippen
Ich weiß nicht genau, ob Du meinen Thread wirklich gelesen hast...cat /etc/systemd/system/multi-user.target.wants/zoneminder.service
# ZoneMinder systemd unit file
# This file is intended to work with Debian distributions
[Unit]
Description=ZoneMinder CCTV recording and surveillance system
After=network.target mysql.service mnt-sdb1.mount var-cache-zoneminder-images.mount var-cache-zoneminder-events.mount
# Remarked out so that it will start ZM on machines that don't have mysql installed
#Requires=mysql.service
Requires=mnt-sdb1.mount var-cache-zoneminder-images.mount var-cache-zoneminder-events.mount
[Service]
#User=www-data
Type=forking
ExecStart=/usr/bin/zmpkg.pl start
ExecReload=/usr/bin/zmpkg.pl restart
ExecStop=/usr/bin/zmpkg.pl stop
PIDFile=/var/run/zm/zm.pid
Restart=on-abnormal
[Install]
WantedBy=multi-user.targetUnd genau dieser Dienst/Service (nicht, dass sich hier noch wer über die Namensgebung echauffiert) startet nicht bei Systemstart. Vielleicht siehst Du ja auf anhieb, was nicht passt.
Gruß
Guckdumalhier: https://www.digitalocean.com/community/tutorials/how-to-use-journalctl-t ...
Dort stehen Details zu "journalctl". Das ist das Programm, was u.a. die Logdateien von systemd-Prozessen ausgibt. Experimentier mal damit - eventuell siehst Du in den Logs etwas zu dem fehlgeschlagenen zoneminder-Service.
Dann würde ich das "After=" auf "network.target" reduzieren und "Requires=" entfernen.
Das Skript startet ausserdem die zmpkg.pl als "root". Soll das so sein? Meist bemüht man systemd-Skripte auch, weil es damit einfacher ist, zu startende Prozesse eben nicht als root zu starten (ist sichererererer).
Dann könntest Du noch gucken, ob die Services in After und Requires wirklich so existieren - dazu kannst Du "systemctl" aufrufen und gucken, ob das dem entspricht, was Du Dir denkst.
Dort stehen Details zu "journalctl". Das ist das Programm, was u.a. die Logdateien von systemd-Prozessen ausgibt. Experimentier mal damit - eventuell siehst Du in den Logs etwas zu dem fehlgeschlagenen zoneminder-Service.
Dann würde ich das "After=" auf "network.target" reduzieren und "Requires=" entfernen.
Das Skript startet ausserdem die zmpkg.pl als "root". Soll das so sein? Meist bemüht man systemd-Skripte auch, weil es damit einfacher ist, zu startende Prozesse eben nicht als root zu starten (ist sichererererer).
Dann könntest Du noch gucken, ob die Services in After und Requires wirklich so existieren - dazu kannst Du "systemctl" aufrufen und gucken, ob das dem entspricht, was Du Dir denkst.
Dann würde ich das "After=" auf "network.target" reduzieren und "Requires=" entfernen.
Warum?Probiere ich gerne aber mich interessiert dein gedachter Hintergrund.
Eigentlich soll der Dienst ja warten bis alles geladen ist.
Dadurch dass systemd ja parallel arbeitet, kann es dann nicht passieren, dass bspw. mount oder der sql-service später startet?
Soll das so sein
Ist bereits abgehakt in der aktuellen Konfig.After und Requires wirklich so existieren
Existieren, habe ich via Hand angelegt. Wie gesagt, starte ich den Dienst per Hand:systemctl start zoneminderstartet die Möhre ja fehlerfrei - also müssen die vorherigen Aktion durchgelaufen sein.
Gegengeprüft: starte ich ohne dass das NAS gemountet wird, kommt der Dienst gar nicht hoch.
VG + Danke für deine Hinweise.
Hmm hatte damit damals weniger Probleme.
Du hast recht, dass zumindest mount abgeschlossen sein soll. Erst recht wenn man die Bilder auslagert. Kommt immer auf das Konstrukt an.
Wenn alles nicht hilft gebe es noch den Holzhammer:
Als "Zeit" im cronjob setzen und ein Bash Script ausführen. Da könnte man entweder Abhängigkeiten vorher starten oder eben einen Delay einbauen. So dass der ZM erst nach x-Minuten gestartet wird. Auch denkbar den Dienst abzufrage und nur bei Bedarf hier nochmal zu starten.
Das Bash muss nur ausführbsein und der Pfad im Cronjob hinterlegt sein. Mit Bash Programmierung kann man noch mehr veranstalten.
Startet dann ZM erst nach 2 Minuten. Normal unnötig, wenn alle Abhängigkeiten erfüllt sind.
Wäre ggf. noch eine Alternative.
Du hast recht, dass zumindest mount abgeschlossen sein soll. Erst recht wenn man die Bilder auslagert. Kommt immer auf das Konstrukt an.
Wenn alles nicht hilft gebe es noch den Holzhammer:
@rebootAls "Zeit" im cronjob setzen und ein Bash Script ausführen. Da könnte man entweder Abhängigkeiten vorher starten oder eben einen Delay einbauen. So dass der ZM erst nach x-Minuten gestartet wird. Auch denkbar den Dienst abzufrage und nur bei Bedarf hier nochmal zu starten.
Das Bash muss nur ausführbsein und der Pfad im Cronjob hinterlegt sein. Mit Bash Programmierung kann man noch mehr veranstalten.
sleep 2mStartet dann ZM erst nach 2 Minuten. Normal unnötig, wenn alle Abhängigkeiten erfüllt sind.
Wäre ggf. noch eine Alternative.
Hmm hatte damit damals weniger Probleme.
Hatte sowas zuvor auch noch nie. Ist jetzt nicht unbedingt meine erste Linuxmöhre :DHatte ich ja auch getestet gehabt, siehe Eingangspost.
Allerdings ohne delay. Ggf. könnte das noch was richten.
Danke Euch.
Ups übersehen.
Naja es kommt relativ früh Delay oder Schleifenprüfung für 3-5 min. bis man sicher ist, das es läuft.
Räusper... Ich hatte Cent OS :-p
Naja es kommt relativ früh Delay oder Schleifenprüfung für 3-5 min. bis man sicher ist, das es läuft.
Räusper... Ich hatte Cent OS :-p
Zitat von @141986:
Probiere ich gerne aber mich interessiert dein gedachter Hintergrund.
Eigentlich soll der Dienst ja warten bis alles geladen ist.
Dadurch dass systemd ja parallel arbeitet, kann es dann nicht passieren, dass bspw. mount oder der sql-service später startet?
Dann würde ich das "After=" auf "network.target" reduzieren und "Requires=" entfernen.
Warum?Probiere ich gerne aber mich interessiert dein gedachter Hintergrund.
Eigentlich soll der Dienst ja warten bis alles geladen ist.
Dadurch dass systemd ja parallel arbeitet, kann es dann nicht passieren, dass bspw. mount oder der sql-service später startet?
Das, was ich denke ist:
Nicht etwas aufrufen, bei dem 10 Abhängigkeiten das Problem sein können, sondern die Abhängigkeiten reduzieren. Eines nach dem anderen. Sprich: wenn es manuell funktioniert, muss einer der Servides aus "After" und "Requires" das Problem sein. Welches - das bekommt man heraus, indem man die Services einzeln einträgt und nach und nach durchprobiert. Zusammen mit den Logausgaben (siehe "journalctl") kommt man der Sache vielleicht auf den Grund.
Ich bin mir sicher, dass das was völlig banales ist - so ähnlich wie "Stecker in Steckdose stecken"
