Cronjobs laufen nicht

Quote from konradmd

~/Desktop/hdmi_on.sh

Du mußt schon den vollen Pfad schreiben; die Tilde wird nur in einer interaktiven Shell aufgelöst.
Und natürlich muß cron auch rechtlich auf die Datei zugreifen dürfen (wenn Du Dein home mit 700 hast, hat er keine Chance) .

Und dann kommt es bei einem Cronjob auch darauf an, was die Inhalte von hdmi_on.sh und hdmi_off.sh sind.

Quote from konradmd

Aber wenn keine 700 - welche Rechte muss ich dann setzen?

Vergiss das mit den 700er Rechten besser wieder! Das stimmt nämlich so nicht.

Interessanter wäre der Inhalt eines der Skripte und ob das ein OS mit Desktop ist und wenn ja, dann Wayland oder X11.

1. cron ist user bezogen, also muss auch der user, der das tun darf auch als cron das script ausführen

2. Die Umgebungsvariablen die du brauchst und die ggf com Login gesetzt werden müssen beim cron (noch) nicht vorhanden sein.

3. Cron kann u.U. eine andere shell verwenden als du mit deinem script. abhilfe schafft da der "#!/path/shell" Eintrag als 1.Zeile.

4. Da cron OHNE Control-Terminal arbeitet, mußt du ihm mitteilen welches HDMI-Terminal er abschalten soll.

Das sind die üblichen Fehler, die man beim Scripten so begeht. Man vergisst, das Linux vom Unix abstammt und Unix immer schon dafür ausgelegt war mehr als ein Terminal zu bedienen. Auch das uralte X11-Protokoll teilte die Darstellung und die Daten bzw den Transfer der Daten und Objekte.

Ich tippe ja eher auf die fehlende Angabe das Anzeigegeräts im Skript oder Cronjob, aber egal!

Quote from konradmd

Was könnte da grundsätzlich falsch sein?

Du hast die crontab nicht mit "crontab -e" für den angemeldeten User erstellt und vorher auch nicht "man crontab", "man 5 crontab", "man cron", durchgelesen.

Für den user root (sudo) brauchst Du keinen cronjob, da "root" kein Grafiksystem normalerweise besitzt und das Ein-/Ausschalten des Bildschirmes nur Fehler in die Logfiles eintragen würde. Wenn allerdings "sudo cron -e" im Terminal des Users (ich?) eingegeben wird, wird auch ein cronjob für den user root generiert.

Dass Dein Shellscript im Terminal des angemeldeten Users funktioniert ist auf das Environement (Umgebungsvariablen) zurückzuführen. Ein cronjob hat auch in der default Grundeinstellung ein sehr eingeschränktes Environement.

Servus !

Man könnte natürlich auch einfach die Fehlermeldung in eine Datei im Heimverzeichnis des Users schreiben lassen

0 17 * * * /home/<username>/Desktop/hdmi_on.sh > /home/<username>/cronausgabe.txt 2>&1

(Die zwei <username> müssen natürlich angepasst werden.) und sich dann cronausgabe.txt ansehen.

Die Eingabezeile in der Crontab muss auch mit einem "newline" abgeschlossen werden. Das wird insbesondere auch dann sichtbar, wenn man in die Folgezeile eine # an erste Stelle setzt.

0 17 * * * /home/<username>/Desktop/hdmi_on.sh
#

Servus !

Ich halte es für keine gute Idee das Script unter /home/<username>/Desktop/hdmi_on.sh abzulegen.
Der eigentliche Ort dafür wäre /usr/local/bin/.

Und Du kannst unter /etc/cron.d/ deine eigenen Cronjobs anlegen:
Z.B.: /etc/cron.d/motion_rm
Inhalt:
0 5 * * * root if [ -x /usr/local/bin/MOTION_RM ] ; then /usr/local/bin/MOTION_RM ESP-CAM_05 ; fi

Ist ein Beispiel von mir und funktionierte auf Anhieb. (Löscht Bilder von Überwachungskameras)

MfG

Jürgen

Edit: Du könntest uns mal hdmi_on.sh zeigen. Dann könnten wir uns mal dein Script etwas genauer ansehen.

Quote from Jürgen Böhm

Edit: Du könntest uns mal hdmi_on.sh zeigen.

Ohne das Skript zu kennen, bleibt leider alles Spekulatius, weil wir nicht mal wissen, womit HDMI an oder abgeschaltet wird und somit auch nicht wissen, welche Umgebungsvariablen fehlen könnten.

Spontan fallen mir fünf Möglichkeiten ein, um die HDMI-Ports zu schalten und zwar vcgencmd display, wlr-randr, xrandr, wlopm und xset und dafür sind verschiedene env. zuständig.

Und mir fällt nur /etc/crontab ein, mit dem systemweit cron gestartet wird.

Also mit der (POSIX compatiblen) "sh", verlinkt auf "dash" und der Grundeinstellung von PATH=

Servus !

Quote from RTFM

Und mir fällt nur /etc/crontab ein, mit dem systemweit cron gestartet wird.

Das meinst du nicht wirklich ernst.

User-Crons sind seit Anbeginn der Cron-Zeit unter Unis ganz normal. Die /etc/crontab ist etwas, was sich Leute ausgedacht heb, die immer als 'root' unterwegs waren und ohne User-Auswahl in der Datei rumpfuschen wollten.

(Die systemd-Timer-Variante ist nicht besser als die /etc/crontab, da man als pobliger User, auch unter einem System Account, keine regelmäßigen Jobs einstellen kann, ohne dass man die passenden Rechte für systemd hat- Außerdem startet 'crontab -e $USERID' nach dem speichern der Konofiguration auch gleich den cron-deamon durch, so dass man das nicht vergisst.)

Immer wieder die selbe alte Leier.

BTW: Schon mal was von Systemd User Units gehört?

Quote from Rasp-Berlin

Die /etc/crontab ist etwas, was sich Leute ausgedacht heb, die immer als 'root' unterwegs waren und ohne User-Auswahl in der Datei rumpfuschen wollten.

Nein, das stimmt nicht. Wer immer als root unterwegs ist, kann z. B. eine root-crontab benutzen. BTW: Es gibt auch Unis, die _keine_ systemweite /etc/crontab kennen/haben.

EDIT:

Quote from Rasp-Berlin

..., da man als pobliger User, auch unter einem System Account, keine regelmäßigen Jobs einstellen kann, ohne dass man die passenden Rechte für systemd hat- ...

BTW: Siehe z. B. die Optionen für systemctl:

Quote

--user
Kommuniziert mit dem Diensteverwalter des aufrufenden Benutzers statt mit dem Diensteverwalter des Systems. (Talk to the service manager of the calling user, rather than the service manager of the system.)

vs.

Quote

--system
Kommuniziert mit dem Diensteverwalter des Systems. Dies ist die implizite Vorgabe. (Talk to the service manager of the system. This is the implied default.)

Quelle: manpage für systemctl

Vielen Dank für die Rückmeldung!

Die Umleitungen in die txt-Dateien brauchts ja nun nicht mehr und kannst Du entweder ganz weglassen oder in > /dev/null 2>&1 abändern.

Wenn das Thema dann für Dich erledigt ist, dann markiere es bitte noch (oben unter Thema bearbeiten) als solches.

//Edit

wlopm --on \*, bzw. wlopm --off \* wäre statt wlr-randr besser geeignet, denn das hat gewisse Nebeneffekte.

Ok, war nur ein Hinweis.