staging.inyokaproject.org

Hallo, ich versuche gerade crontabs zu verstehen und scheitere schon an der simpelsten Variante. Mit crontab -e habe ich die Tabelle zum bearbeiten geöffnet und habe dann einen simplen Befehl zum Testen eingegeben (siehe Bild). Dieser wird jedoch nicht ausgeführt. Zuerst dachte ich, dass der Speicherort in temp falsch ist, jedoch scheint dies laut stackexchange richtig zu sein um fehlerhafte crontabs zu vermeiden. Wo liegt dann mein Fehler?

Beste Grüße

Bitte keine Screenshots von Code posten.

Das kann man nicht per copy/paste in die eigenen Werkzeuge übertragen.

Markiere den Text und paste ihn mit der mittleren Maustaste ins Editfeld und markiere ihn da, dann den codeblock-Button betätigen und im Falle crontab "Code ohne Highlight" auswählen. Sieht dann etwa so aus:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

# Edit this file to introduce tasks to be run by cron.
# 
# Each task to run has to be defined through a single line
# indicating with different fields when the task will be run
# and what command to run for the task
# 
# To define the time you can provide concrete values for
# minute (m), hour (h), day of month (dom), month (mon),
# and day of week (dow) or use '*' in these fields (for 'any').# 
# Notice that tasks will be started based on the cron's system
# daemon's notion of time and timezones.
# 
# Output of the crontab jobs (including errors) is sent through
# email to the user the crontab file belongs to (unless redirected).
# 
# For example, you can run a backup of all your user accounts
# at 5 a.m every week with:
# 0 5 * * 1 tar -zcf /var/backups/home.tgz /home/
# 
# For more information see the manual pages of crontab(5) and cron(8)
# 
# m h  dom mon dow   command
#
* * * *  printf "\a"

Gib mal

1

grep -i cron /var/log/syslog

in eine Shell ein. Bei mir zeigt sich dann:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

May 22 03:06:56 tux201t crontab[16558]: (stefan) LIST (stefan)
May 22 03:08:29 tux201t crontab[16639]: (stefan) BEGIN EDIT (stefan)
May 22 03:09:36 tux201t crontab[16639]: (stefan) REPLACE (stefan)
May 22 03:09:36 tux201t crontab[16639]: (stefan) END EDIT (stefan)
May 22 03:09:48 tux201t crontab[16710]: (stefan) LIST (stefan)
May 22 03:10:01 tux201t cron[1088]: (stefan) RELOAD (crontabs/stefan)
May 22 03:10:01 tux201t CRON[16715]: (stefan) CMD (printf "\a")
May 22 03:11:01 tux201t CRON[16780]: (stefan) CMD (printf "\a")
May 22 03:12:01 tux201t CRON[16848]: (stefan) CMD (printf "\a")
May 22 03:13:01 tux201t CRON[16892]: (stefan) CMD (printf "\a")
May 22 03:14:01 tux201t CRON[16954]: (stefan) CMD (printf "\a")
May 22 03:15:01 tux201t CRON[17004]: (stefan) CMD (printf "\a")
May 22 03:16:01 tux201t CRON[17063]: (stefan) CMD (printf "\a")

Es findet also minütlich das Kommando statt - man hört nur nix.

Dann gib nur

1

printf "\a"

ein. Hörst Du was? Backslash-a steht doch für alert, und soll ein Glockensignal ausgeben?

Du könntest auch versuchen statt

1
2
3

printf "\a" 
#
aplay ~/proep.mp3

zu nutzen, freilich nach dem Du am betreffenden Ort eine geeignete Prööööp-Datei deponiert hast, die Du hörst, wenn Du auch sonst keinen Alert hörst (ich höre keinen).

user_unknown schrieb:

Gib mal

1	grep -i cron /var/log/syslog

in eine Shell ein. Bei mir zeigt sich dann:

Es findet also minütlich das Kommando statt - man hört nur nix.

Dann gib nur

1	printf "\a"

ein. Hörst Du was? Backslash-a steht doch für alert, und soll ein Glockensignal ausgeben?

Danke für deine Antwort. Die Konsole gibt bei mir folgendes aus

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

May 22 10:49:12 ws-budgie keyboard-setup.sh[374]: WARNING: Unknown X keysym "dead_belowmacron"
May 22 10:49:12 ws-budgie keyboard-setup.sh[374]: message repeated 3 times: [ WARNING: Unknown X keysym "dead_belowmacron"]
May 22 10:49:12 ws-budgie cron[903]: (CRON) INFO (pidfile fd = 3)
May 22 10:49:12 ws-budgie anacron[919]: Anacron 2.3 started on 2019-05-22
May 22 10:49:12 ws-budgie anacron[919]: Normal exit (0 jobs run)
May 22 10:49:12 ws-budgie systemd[1]: Started Trigger anacron every hour.
May 22 10:49:12 ws-budgie cron[903]: (CRON) INFO (Running @reboot jobs)
May 22 10:49:12 ws-budgie systemd[1]: Started Run anacron jobs.
May 22 10:50:01 ws-budgie CRON[2355]: (ws) CMD (printf "\a")
May 22 10:51:01 ws-budgie CRON[2512]: (ws) CMD (printf "\a")
May 22 10:52:01 ws-budgie CRON[2517]: (ws) CMD (printf "\a")
May 22 10:53:01 ws-budgie CRON[2548]: (ws) CMD (printf "\a")

Wenn ich printf "\a" ganz normal in die Konsole eingebe, bekomme ich auch ein akustisches Signal vom System. Demzufolge sollte es ja auch beim cronjob funktionieren.

Wenn ich mit aplay eine mp3 aus meinem Musikordner abspielen will, höre ich nur ein Rauschen und Knacken. Ich denke das ist erstmal eine andere Baustelle, da ja sonst die Soundausgabe problemlos funktioniert.

wollentino schrieb:

Wenn ich printf "\a" ganz normal in die Konsole eingebe, bekomme ich auch ein akustisches Signal vom System. Demzufolge sollte es ja auch beim cronjob funktionieren.

Da bin ich mir noch nicht so sicher. Das printf ist ein bashinternes Kommando, und die Bash kann prüfen, ob sie als interaktive Shell läuft und sich je nach dem anders verhalten. Ob das für printf und echo zutrifft weiß ich aber nicht.

user_unknown schrieb:

Da bin ich mir noch nicht so sicher. Das printf ist ein bashinternes Kommando, und die Bash kann prüfen, ob sie als interaktive Shell läuft und sich je nach dem anders verhalten. Ob das für printf und echo zutrifft weiß ich aber nicht.

Ganz ehrlich, für mich als 0815-Anwender ist das schon zu hoch. Ich versuche es mal laienhaft:

Wenn ich in der Terminalemulation tilix einen Befehl eingebe wird dieser doch vom Befehlszeileninterpreter (standardmäßig ist das wohl Bash?) verarbeitet.

Wie sieht das mit einem Befehl eines cronjobs aus? Wird dieser nicht auf die gleiche Weise durch einen Befehlszeileninterpreter (Bash) verarbeitet?

Ja, das ist leider eine komplexe Geschichte.

Ich zähle unter den regelmäßigen Postern hier wahrscheinlich zu den ca. 10, die sich am besten mit der Bash auskennen, allerdings bin ich kein Netzwerkadministrator und betreibe keinen Server, so dass ich in manchen Teilbereichen große Wissenslücken habe. Die kommen hier ins Spiel, da cron ein Programm ist, dass gerade auf einem Server und in Netzwerken besonders nützlich ist.

Erstmal gilt, dass die Shell, die benutzt wird, ausdrücklich gesetzt werden kann (siehe man 5 crontab).

1

SHELL=/bin/bash

Die Bash kennt 4 unterschiedliche Modi, die im Wiki behandelt werden Loginshell/Nichtloginshell und interactive/non-interactive.

Bei einem Netzwerksystem kann es sein, dass da dutzende User registriert sind und einen crontab-File am Start haben und dass der Server läuft, ohne dass ein User eingeloggt ist, ist häufig der Fall, gerade für Aufräumjobs die bevorzugt nachts laufen. Dass es da nicht dauernd piept, vor allem wenn die Leute 4 Räume oder 4000 km weiter sitzen, wäre verständlich. Ob dem aber so ist weiß ich wie gesagt nicht.

Bei einem Desktopsystem, das eigentlich nur läuft, während man davor sitzt, sind die Bedürfnisse natürlich andere.

Im Wiki habe unter cron folgende interessante Empfehlung gefunden:

1

/bin/bash --login /PFAD/ZUM/SKRIPT.sh

im Abschnitt "Häufige Fehler". Das ist wohl am leichtesten auszuprobieren, also in Deinem Fall eher:

1

/bin/bash --login -c 'printf "\a"'

Danke für deine Bemühungen die Problematik mir zu erklären.

Ich hab eben mal ausprobiert was passiert, wenn ich "SHELL=/bin/bash" in den crontab hinzufüge. Auch dann gibt es keine Soundausgabe. Das es nicht funktioniert wäre ja nicht schlimm, da es ja nur zum Testen dienen sollte. Was mir aber Kopfschmerzen bereitet ist, dass im Log jede Minute angezeigt wird, dass der Befehl (printf "\a") ausgeführt wird.

May 26 13:03:01 ws-budgie CRON[5014]: (ws) CMD (printf "\a")
May 26 13:04:01 ws-budgie CRON[5020]: (ws) CMD (printf "\a")
May 26 13:05:01 ws-budgie CRON[5026]: (ws) CMD (printf "\a")
May 26 13:06:01 ws-budgie CRON[5035]: (ws) CMD (printf "\a")
May 26 13:07:01 ws-budgie CRON[5055]: (ws) CMD (printf "\a")
May 26 13:08:01 ws-budgie CRON[5061]: (ws) CMD (printf "\a")

Wie kann ich denn bei anderen Befehlen sicher sein, dass die ausgeführt werden? Z.B. bei einem Cronjob, der jede Nacht für den Raspberrry Aktualisierungen suchen und installieren soll.

0 3 * * * sudo apt-get update -y && sudo apt-get dist-upgrade -y

Nur weil dieser Befehl dann in der log auftaucht, bedeutet es ja nicht zwangsläufig, dass der auch ausgeführt wurde.

wollentino schrieb:

Nur weil dieser Befehl dann in der log auftaucht, bedeutet es ja nicht zwangsläufig, dass der auch ausgeführt wurde.

Dann versuch mal mit z. B.:

*/2 * * * * logger "test for cronjob"
# - - - 

als letzte Zeilen in deiner crontab. Wenn es die systemweite crontab ist, musst Du auch den user oder root eintragen.

wollentino schrieb:

Z.B. bei einem Cronjob, der jede Nacht für den Raspberrry Aktualisierungen suchen und installieren soll.

0 3 * * * sudo apt-get update -y && sudo apt-get dist-upgrade -y

..., dass der auch ausgeführt wurde.

Ja, denn es könnte ja auch sein, dass zu diesem Zeitpunkt, keine Internetverbindung vorhanden war oder/und keine Namensauflösung (DNS) möglich war. Wenn man so etwas machen will, dann evtl. in einem Script, das im Vorfeld des updates/upgrades die erforderlichen Bedingungen (Internetverbindung, Namensauflösung, etc. , ...) prüft bzw. testet.

BTW: Noch besser ist es m. E. keine automatischen updates zu machen, sondern immer nur manuell bzw. interaktiv, damit man sieht was genau updatet wird.

Meine Vermutung ist, dass man dafuer einen aktiven X-Server braucht und das Terminal auch darunter laufen muss. So wie auch xset

Versuche mal die Umgebungsvariable entweder in einem Skript vorher zu exportieren:

1
2
3
4
5

#! /bin/bash

export XDG_RUNTIME_DIR="/run/user/1000"

printf "\a"

Nicht vergessen es ausführbar zu machen und dann das Skript in crontab ausführen.

Bei mir gibt es übrigens keinen Ton, wenn ich printf "\a" in der Konsole ausführe!