Jemand ein Tipp? Nerviges cron-Problem unter UnRaid

[unrno.spam]

Auf meinem UnRaid-Server habe ich leider das nervige Problem, dass ich in meinen Anfängen wohl einen cronjob 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

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

 

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...

 

Wenn ich die Datei "root" lösche, wird sie beim nächsten Neustart automatisch wieder angelegt. die Datei woanders hin kopieren, bearbeiten , die alte ursprüngliche löschen und die bearbeitete Datei wieder zurück kopieren hat auch nicht geholfen.

 

Wie kann ich am besten rausfinden, was die Datei beim Neustart erzeugt und wie ich das dann lösen kann?

Weiß leider nicht mehr, wo ich damals bei Installation des UNR-Servers rumgepfuscht habe und da das Problem nur bei einem Neustart auftaucht, ist es mir lange nicht aufgefallen - nun nervt es aber doch, da der cronjob so Fehler ausspuckt, die per Mail versandt werden...

[mgutt]

Mal den "offiziellen" Weg versucht mit "crontab -e"?

 

Normal nimmt man keinen Editor um die Dateien zu bearbeiten.

[unrno.spam]

Sorry für Nachfragen: im Pfad /etc/cron.d/ und muss ich dann noch irgendwie den Dateinanmen mitgeben? Denn sonst kommt im Terminal ja nur die Möglichkeit, einen neuen Crontab zu erstellen...

 

crontab -l führt zur selben Ausgabe, ebenso crontab -e -u root

 

# 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

 

Edited March 20, 2022 by unrno.spam

[Ford Prefect]

...die crontab unter /etc/ ist nicht die richtige...kann nicht die richtuge sein, da diese ja einen Neustart nicht überleben würde (unraid läuft im RAM).

Also mal auf dem Stick (/boot/config/........) schauen, wo dort das Original rumfliegt.

Ich nutze crontab nicht, aber wie hast Du das ursprünglich eingerichtet...irgendein Plugin dafür am Start?

Das Phänomen mit dem auto-update Plugin deutet darauf hin.

[unrno.spam]

Danke, aber es sieht ja so aus, als wenn die Datei beim Neustart neu geschrieben wird. Zumindest deutet Uhrzeit und Datum der Datei darauf hin.

Ich suche aber mal auf dem Stick nach der Datei...

[Ford Prefect]

33 minutes ago, unrno.spam said:

Danke, aber es sieht ja so aus, als wenn die Datei beim Neustart neu geschrieben wird.

Ja, weil sie eben zum Zeitpunkt des Neustarts vom Stick ins RAM kopiert bzw. von dort von einem plugin dorthin "generiert" wird.

Daher hat sie den Datumsstempel vom Neustart.

 

[mgutt]

Such mal so:

grep -riIls "tvheadend" /boot

 

[unrno.spam]

BINGO! Danke, mgutt - das hat zwei cron-Jobs hervorgebracht, in denen die Kopiervorgaänge angelegt sind:

 

/boot/config/plugins/dynamix/epgfinal.cron
/boot/config/plugins/dynamix/test.cron

 Werde die beiden cron-Jobs löschen und dann sollte hoffentlich Ruhe sein!