Skript beim Shutdown ausführen klappt nicht

Hallo Michael,

ich bräuchte ja erst mal nur jemanden, der erkennt, warum das mit dem Skript beim Shutdown nicht hinhaut :wink:

Wenn TVHeadend auf dem neu aufgesetzten Mediacenter-PC die Sender wieder nicht findet, dann brauche ich eh tatsächlich ne ganz andere Lösung als über die Fritzbox.
Derzeit hat TVHeadend aber noch kein Repo für 20.04, also kann ich es noch nicht installieren um das zu testen.

Viele Grüße
Steffen

Hallo Steffen!

gebe mal systemctl den kompletten Pfad an.

whereis systemctl

Beste Grüße

Thorsten

Hallo Thorsten,

du meinst in der ssh Zeile?
ssh -p 22 root@ -i /home//.ssh/id_rsa systemctl suspend

Da die Zeile ja auf dem entfernten Proxmox suspend auslösen soll und das auch klappt, wenn ich die Zeile im Terminal eingebe oder das Skript von Hand ausführe, glaube ich nicht dass das was ändert, probiere es aber aus.

Ich denke aber vielmehr dass das Skript einfach nicht ausgeführt wird beim Shutdown.

Viele Grüße
Steffen

Hallo Thorsten,

wie vermutet bringt das auch keine Besserung.

Bei den Tests ist mir aber noch was seltsames unter Ubuntu 20.04 aufgefallen.

Ich habe bislang etliche Skripte auf dem Desktop (Schreibtisch) liegen, die ich per Doppelklick aufrufe. Die Skripe haben zwecks besserer Lesbarkeit auch Leerzeichen im Namen.

Das klapp unter 20.04 nicht mehr. Da darf kein Leerzeichen mehr drin sein. Auch darf man das Skript nach dem Kopieren auf den Desktop nicht mehr umbenennen, dann klappt das Ausführen auch nicht mehr („Befehl nicht gefunden“).

Außerdem wird auch nicht wie noch unter 18.04 nachgefragt, ob man im Terminal ausführen, öffnen, abbrechen oder ausführen will, obwohl das für Nautilus für ausführbare Dateien so eingestellt ist und dort auch so funktioniert. Das Skript wird mit Doppelklick ohne Nachfrage ausgeführt.

Also entweder das ist noch buggy (was ich aber nicht glaube), oder „das kannste schon so machen, aber dann isses halt kacke“.

Bislang war ich trotz aller Kritik, die im Laufe der Jahre entstanden ist, immer zufrieden mit Ubuntu. Aber das nervt für einen intuitiven und flexiblen Workflow grad ziemlich, wenn man viele verschiedene Skripte auf dem Desktop liegen haben will, was ich einfach nur praktisch finde.

Viele Grüße
Steffen

Hallo,

sudo systemctl start shutdownscripte_mediacenter.service
Job for shutdownscripte_mediacenter.service failed because the control process exited with error code.
See "systemctl status shutdownscripte_mediacenter.service" and "journalctl -xe" for details.

Here we go

systemctl status shutdownscripte_mediacenter.service
    ● shutdownscripte_mediacenter.service - Start at shutdown, halt
         Loaded: loaded (/etc/systemd/system/shutdownscripte_mediacenter.service; enabled; vendor preset: enabled)
         Active: failed (Result: exit-code) since Fri 2020-04-03 09:21:05 CEST; 15s ago
        Process: 19925 ExecStart=/home/mediacenter/Skripte/Netzwerkserver-ausschalten (code=exited, status=203/EXEC)
       Main PID: 19925 (code=exited, status=203/EXEC)
    Apr 03 09:21:05 mediacenter systemd[1]: Starting Start at shutdown, halt...
    Apr 03 09:21:05 mediacenter systemd[1]: shutdownscripte_mediacenter.service: Main process exited, code=exited, status=203/EXEC
    Apr 03 09:21:05 mediacenter systemd[1]: shutdownscripte_mediacenter.service: Failed with result 'exit-code'.
    Apr 03 09:21:05 mediacenter systemd[1]: Failed to start Start at shutdown, halt.

und

    journalctl -xe
   The error number returned by this process is ERRNO.
    Apr 03 09:21:05 mediacenter systemd[1]: shutdownscripte_mediacenter.service: Main process exited, code=exited, status=203/EXEC
    Subject: Unit process exited
    Defined-By: systemd
    Support: http://www.ubuntu.com/support

    An ExecStart= process belonging to unit shutdownscripte_mediacenter.service has exited.

    The process' exit code is 'exited' and its exit status is 203.
    Apr 03 09:21:05 mediacenter systemd[1]: shutdownscripte_mediacenter.service: Failed with result 'exit-code'.
    Subject: Unit failed
    Defined-By: systemd
    Support: http://www.ubuntu.com/support

    The unit shutdownscripte_mediacenter.service has entered the 'failed' state with result 'exit-code'.
    Apr 03 09:21:05 mediacenter systemd[1]: Failed to start Start at shutdown, halt.
    Subject: A start job for unit shutdownscripte_mediacenter.service has failed
    Defined-By: systemd
    The job identifier is 4395 and the job result is failed.
    Apr 03 09:21:06 mediacenter sudo[19922]: pam_unix(sudo:session): session closed for user root
    Apr 03 09:21:47 mediacenter systemd[1193]: Started Application launched by gnome-shell.
    Subject: A start job for unit UNIT has finished successfully
    Defined-By: systemd
    Support: http://www.ubuntu.com/support

    A start job for unit UNIT has finished successfully.
    The job identifier is 845.
    Apr 03 09:21:48 mediacenter rtkit-daemon[1214]: Supervising 3 threads of 1 processes of 1 users.
    Apr 03 09:21:48 mediacenter rtkit-daemon[1214]: Supervising 3 threads of 1 processes of 1 users.
    Apr 03 09:21:48 mediacenter rtkit-daemon[1214]: Supervising 3 threads of 1 processes of 1 users.
    Apr 03 09:21:48 mediacenter rtkit-daemon[1214]: Supervising 3 threads of 1 processes of 1 users.
    Apr 03 09:21:48 mediacenter rtkit-daemon[1214]: Successfully made thread 20017 of process 19940 owned by '1000' RT at priority 10.
    Apr 03 09:21:48 mediacenter rtkit-daemon[1214]: Supervising 4 threads of 2 processes of 1 users.
    Apr 03 09:21:48 mediacenter rtkit-daemon[1214]: Supervising 4 threads of 2 processes of 1 users.
    Apr 03 09:21:48 mediacenter rtkit-daemon[1214]: Supervising 4 threads of 2 processes of 1 users.
    Apr 03 09:21:48 mediacenter rtkit-daemon[1214]: Supervising 4 threads of 2 processes of 1 users.
    Apr 03 09:21:48 mediacenter rtkit-daemon[1214]: Supervising 4 threads of 2 processes of 1 users.
    Apr 03 09:21:49 mediacenter rtkit-daemon[1214]: Supervising 4 threads of 2 processes of 1 users.
    Apr 03 09:21:49 mediacenter rtkit-daemon[1214]: Supervising 4 threads of 2 processes of 1 users.
    Apr 03 09:22:05 mediacenter wpa_supplicant[893]: wlp58s0: WPA: Group rekeying completed with 38:10:d5:03:8c:3d [GTK=CCMP]
    Apr 03 09:22:58 mediacenter systemd-resolved[817]: Server returned error NXDOMAIN, mitigating potential DNS violation DVE-2018-0001, retrying transaction with reduced feature level UDP.
    Apr 03 09:25:14 mediacenter PackageKit[3734]: daemon quit
    Apr 03 09:25:14 mediacenter systemd[1]: packagekit.service: Succeeded.
    Subject: Unit succeeded
    Support: http://www.ubuntu.com/support
    The unit packagekit.service has successfully entered the 'dead' state.

Momentan kann ich das nicht interpretieren, was schief läuft :thinking:

Viele Grüße
Steffen

Hallo Steffen,

Außerdem wird auch nicht wie noch unter 18.04 nachgefragt, ob man im
Terminal ausführen, öffnen, abbrechen oder ausführen will, obwohl das
für Nautilus für ausführbare Dateien so eingestellt ist und dort auch so
funktioniert. Das Skript wird mit Doppelklick ohne Nachfrage ausgeführt.

das Verhalten kannst du in den Einstellungen des Dateibrowsers umstellen
(was soll beim Doppelklick auf ausführbare Dateien passieren?)

Unter 18.04 war das erhalten icht so wie du es beschreibst: das hat „per
default“ alle Dateien nur „aufgemacht“ aber nicht ausgeführt.
Du denkst das sei anders gewesen, weil du wahrscheinlich nicht 18.04
installiert hast, sondern ein upgrade gemacht hast: dabei wurde di alte
Einstellung übernommen.

Also entweder das ist noch buggy (was ich aber nicht glaube), oder „das
kannste schon so machen, aber dann isses halt kacke“.

oder keines von beidem sondern dir erscheint das Verhalten älterer
ubuntuversionen im falschen Licht :slight_smile:

Bislang war ich trotz aller Kritik, die im Laufe der Jahre entstanden
ist, immer zufrieden mit Ubuntu. Aber das nervt für einen intuitiven und
flexiblen Workflow grad ziemlich, wenn man viele verschiedene Skripte
auf dem Desktop liegen haben will, was ich einfach nur praktisch finde.

manchmal liegt es gar nicht an ubuntu …

LG

Holger

Hallo Holger,

nein, denn

  1. habe ich das im Dateibrowser (Nautilus) umgestellt
  2. funktioniert es ja auch, nur eben nicht bei Skripten, die auf dem Desktop liegen, wenn diese
    a) Leerzeichen enthalten
    b) auf dem Desktop liegend nochmal umbenannt werden

Das ist unter 18.04 definitiv noch anders.

Viele Grüße
Steffen

Hallo Steffen,

vielleicht wird das „ausführbar“ Attribut beim Umbenennen gelöscht?

Gruß

Alois

Hallo,

ok, da war ein Tippfehler im Skriptnamen. ```
sudo systemctl start shutdownscripte_mediacenter.service


Viele Grüße
Steffen

Hallo Alois,

das habe ich schon geprüft. Nein. Das Atribut ist auf nach dem Umbenennen noch da, aber das Skript wird dann nicht mehr ausgeführt, sondern es kommt nur noch „Befehl nicht gefunden“.

So lange das Skript ohne Leerzeichen im Namen und ohne danach nochmal umbenannt zu werden von einem anderen Ordner einfach auf den Desktop kopiert wird, wird es ausgeführt.
Allerdings wie oben schon geschrieben ohne Nachfrage, was denn getan werden soll (im Terminal ausführen, öffnen, abbrechen oder ausführen), obwohl das für Nautilus für ausführbare Dateien so eingestellt ist.
Unter 18.04 wird auch bei Skripten auf dem Desktop nachgefragt und man kann die Skripte auf dem Desktop auch nachträglich umbenennen und die Namen dürfen Leerzeichen enthalten.
Das Verhalten für den Desktop bei 20.04 ist definitiv anders als bei 18.04 noch.

Viele Grüße
Steffen

Hallo,

also ich bin jetzt mal einen Schritt zurück und habe das Skript, das beim Shutdown ausgeführt werden soll, auf das Schreiben eines echo in einer Datei umgebaut:

#!/bin/bash
echo "Test" >> /home/mediacenter/Test.txt
exit 0

Wenn ich den PC herunterfahre, wird die Datei mit dem Inhalt erstellt. Also wird das Skript grundsätzlich beim Shutdown abgearbeitet.
Allerdings wird kein ssh-Befehl abgeabeitet, oder wahrscheinlich besser gesagt, er bleibt beim entfernten Server wirkungslos. Vermutlich ist zum Zeitpunkt, wenn das Skript ausgeführt wird, ssh oder network schon nicht mehr aktiv, so dass der ssh-Befehl ins Leere läuft.

Mehrere Stunden Suchmaschinen haben mich aber nicht weiter gebracht :frowning:

Auch bei Ubuntuusers nach wie vor keine Antwort, obwohl ähnliche systemd-Anliegen da schon diskutiert wurden.

Irgendwie muss das sicher hinzukriegen sein, dass der ssh-Befehl beim Shutdown so abgesetzt wird, dass er auch beim Server noch ankommt… aber wie :thinking:

Viele Grüße
Steffen

Hiho,

hast du mal SELinux geprüft?

sestatus

mach mal

getenforce 0

probiere erneut via systemctl auszuführen