Jemand ein Tipp? Nerviges cron-Problem unter UnRaid

no.spam

Auf meinem UnRaid-Server habe ich leider das nervige Problem, dass ich in meinen anfängen wohl einen crontab angelegt habe, den ich jetzt nicht mehr loswerde.

Ich kann den crontab bearbeiten mit nano, das Ergebnis abspeichern - aber beim nächsten Neustart ist alles wieder beim alten. Manchmal braucht es dazu nicht mal ein Neustart (z.B. taucht das Problerm auch auf, wenn das autoupdate-plugin sich selbst updatet).

Nach dem Neustart gehe ich ins Terminal und rufe mit

Code

sudo root nano /etc/cron.d/root

den crontab auf, mache meine Änderungen (lösche die gelb markierten Zeilen raus), speichere mit Strg+O und gehe wieder raus mit Strg-X

Ich weiß nicht, ob der crontab auf dem USB-Boot-Stick liegt - jedenfalls finde ich ihn da nicht oder ich suche nicht richtig.
Wo und wie kann ich am besten nach diesem crontab suchen und natürlich vor allem, ihn endgültig bearbeiten.

Ein docker dürfte da nichts eintragen, den die docker werden jede Nacht gestoppt, ein Backup gemacht und wieder neu gestartet und trotzdem bleibt der crontab bis zum nächsten Neustart sauber...

DaVu

Versuch mal ein crontab -e mit dem User, dem der Cronjob gehört.

Dann die entsprechenden Zeilen löschen und speichern. Das sollte es eigentlich gewesen sein.

no.spam

Sieht bei mir komisch aus:

Code

root@xxxxxxx:~# cd /etc/cron.d/
root@xxxxxxxx:/etc/cron.d# ls -l
total 4
-rw------- 1 root root 823 Mar 16 08:16 root
root@xxxxxxxxxx:/etc/cron.d#

Die Datei heißt root und gehört root. Ein crontab -e in diesem Verzeichnis (bin ja als root eingelogged) lässt mich nur einen neuen crontab anlegen

Code

# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null.  We'll do this here since these jobs should run
# properly on a newly installed system.  If a script fails, run-parts will
# mail a notice to root.
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this.  If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null
0 4 * * * /usr/local/emhttp/plugins/ca.backup2/scripts/backup.php &>/dev/null 2>&1
~                                                                                                                           
~                                                                                                                           
~

Alles anzeigen

DaVu

Zitat von no.spam

(bin ja als root eingelogged)

Für was in aller Welt brauchst du denn das "sudo" im Befehl, wenn du schon als root eingeloggt bist?

Wenn du schon als root eingeloggt bist, dann wäre ein nano /etc/cron.d/root ausreichend.

Aber egal....

Ich habe gerade mal geschaut. auf meinem Unraid liegt ebenfalls in /etc/cron.d/root ein Crontab. Das hat einen anderen Inhalt als wenn ich ein crontab -l mache. Der Inhalt von crontab -l liegt in der Datei /var/spool/cron/crontabs/root und diese Datei sollte nicht bearbeitet werden.

Wenn ich dann mit einem Editor an die Datei unter /etc/cron.d ran gehe, dann bleibt das auch so. Vielleicht solltest du mal den Befehl ohne "sudo" versuchen. Denn das ist gar nicht nötig.

no.spam

Pure Verzweiflung
Nein, im Ernst - ich meine, ich hatte es früher immer ohne sudo probiert und aus purer Verzweiflung ein sudo vorne dran gestellt. In der hoffnung, dass es eben nicht nur Nullen und einsen gibt, sondern irgendwo noch 0,5...
Habe die Datei gerade nochmal ohne sudo bearbeitet, kann aber das System gerade nicht neustarten...

DaVu

Was ich noch machen würde....

Wenn nach dem nächsten reboot die Datei wieder den gleichen Inhalt hat, dann würde ich mir mal den Zeitstempel der Datei anschauen. Der zeigt, wann die Datei zuletzt "angefasst" wurde. Um ganz sicher zu sein, würde ich ggf. auch mal vorrübergehend den Docker entfernen/deaktivieren.

Das ein Docker einen Eintrag in der Host-Crontab anlegt kann nur dann passieren, wenn der Container den Ordner auch entsprechend als Volume zur Verfügung hat. Ist das der Fall? Wenn das der Fall ist, dann kommt der Eintrag vom Container beim Boot und du solltest mal schauen, wie du das änderst. Wobei grundlegend das Editieren einer Datei, welche in einen Container gemountet wird auch einen direkten Effekt haben sollte und dann auch nicht mehr automatisch vom Container geändert werden kann.

Wenn es wirklich nach einem Reboot wieder einen alten Stand hat, dann würde ich denken, dass das System (UnRaid) irgendwo eine übergeordnete Datei hat, die die Datei in /etc/cron.d überschreibt. Das wäre aber auch wirklich tricky und ist schwer vorstellbar. Ich glaube da jagen wir Geister

no.spam

Danke, schaue ich mir gerne auch noch an.

Wenn alles nichts hilft, dann gebe ich dem System was es will und lege die Pfade und die Datei zum Kopieren an.
Dann läuft der cron-Auftrag wenigstens ohne Fehlermeldungen ab, auch wenn dort dann sinnlos was hin und her kopiert wird...

Danke Dir fürs Anschauen meines Problems!

DaVu

Nenenene....so einfach kommst du mir nicht davon

Kapitulation ist nicht drin. Es muss nen Grund haben, warum das so ist und den sollten wir auch rausbekommen. Ansonsten würde ich mal eine Support-Anfrage an Unraid stellen. Die Jungs sind grundlegend sehr nett und hilfsbereit.

Das ist ja hier keine Raketenwissenschaft, was wir machen wollen. Das ist ein einfacher Cronjob, der geändert werden soll. Ich kann mir höchstens vorstellen, dass unraid noch irgendwo anders eine Konfiguration versteckt hat. Diese werden wir schon noch finden

Die Holzhammermethode wäre noch, die Datei via scp vom Server runter zu kopieren, dann die Datei zu löschen, dann rebooten. Dann sollte die Datei immer noch nicht da sein. Dann die Datei "offline" (also auf deinem Rechner) bearbeiten und dann wieder rein kopieren. Ggf. kannst du ihr auch einfach einen anderen Namen geben.

Das bekommen wir schon noch hin

no.spam

Also, alle weiteren Versuche wie von Dir vorgeschlagen haben nun die Erkenntnis gebracht, dass die Datei tatsächlich bei jedem Neustart neu geschrieben wird. Selbst als ich sie gelöscht habe, wurde sie beim Start wieder erzeugt. Und leider wieder mit den ungewünschten Einträgen.
Ich poste mal ins UnRaid-Forum - denke, da läuft grundsätzlich was schief...

DaVu

Ich bin gespannt, was bei raus kommt. Halt uns bitte auf dem Laufenden

Magst du vielleicht einen Link zur Frage teilen? Ich habe selbst einen Account. Dann kann ich dem auch so folgen.

no.spam

Habe es erst mal in die deutsche Sektion eingetragen:

Unraid-Forum

Wenn da nichts geht, poste ich nochmal im englischen Forum...

no.spam

Ist gelöst.

Mit

Code

grep -riIls "tvheadend" /boot

habe ich zwei cron-Jobs finden können, die diese Einträge verursacht haben. die Jobs gelöscht und nun ist nach dem Neustart alles so, wie es sein soll

Jemand ein Tipp? Nerviges cron-Problem unter UnRaid

Jetzt mitmachen!

Benutzer online in diesem Thema