ubuntuusers.de

Ich bekomme seit einiger Zeit mails im syslog unter anderem mit dieser Fehlermeldung

Allerdings handelt es sich da um ein Raspi4 , die Verzeichnisstruktur (/var/backup/ )ist allerdings fast identisch mit meinem Ubuntu 20.04.

Ich würde gerne der Sache auf den Grund gehen.

Darf ich hier dennoch Fragen stellen?

Das raspi Forum konnte mir nicht weiterhelfen.

Als System kritisch stufe ich den Fehler nicht ein, ist weshalb ich eine Neuinstallation erst mal nicht erwäge.

Die Mail:

Cron <root@raspi4> test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )

der Fehler

run-parts: /etc/cron.daily/mlocate exited with return code 1

als root ausgeführt:

root@raspi4:/var/backups# /etc/cron.daily/mlocate
root@raspi4:/var/backups# 

gehe ich richtig, daß return 1 ein Fehlercode ist?

Wenn ja, wieso kann es dann sein, daß er über ssh nicht auftritt/angezeigt wird?

edit./. Es sollte nicht syslog heißen sondern "in den sysmails"

Der Fehler kann unter Cron auftreten, aber nicht per SSH, weil die Cronumgebung einfach eine andere ist, als wenn Du Dich per SSH verbindest. Du kannst mal folgendes probieren, womit das Skript quasi unter der Cron-Umgebung ausgeführt wird:

env -i /etc/cron.daily/mlocate

Und ja, jeder Returncode ungleich 0 wird als Fehler gewertet.

EDIT: Hm, laut diesem Artikel ist das ein Problem mit dem index von locate: https://christophe.cucciardi.fr/proxmox-run-parts-etc-cron-daily-mlocate-exited-with-return-code-1/

Danach sollte folgendes helfen (also den Index von locate neu zu bauen):

rm /var/lib/mlocate/mlocate.db
updatedb

Besten Dank

env -i /etc/cron.daily/mlocate

Genau nach so was habe ich gesucht

root@raspi4:~$ env -i /etc/cron.daily/mlocate
/usr/bin/updatedb.mlocate: can not open a temporary file for `/var/lib/mlocate/mlocate.db'

jetzt kommt keine Fehlermeldung mehr

root@raspi4:/# rm /var/lib/mlocate/mlocate.db
root@raspi4:/# updatedb
root@raspi4:/# env -i /etc/cron.daily/mlocate
root@raspi4:/# 

weil die Cronumgebung einfach eine andere ist,

ist mir auch aufgefallen, ich sehe nur unter webmin den crontab, aber nicht, wenn ich als root crontab -l eingebe

kann mir jemand sagen, warum?

nächste Frage:

was bedeutet diese Meldung:

/etc/cron.daily/dpkg:
mv: der Aufruf von stat für './/dpkg.statoverride.5.gz' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
mv: der Aufruf von stat für './/dpkg.statoverride.4.gz' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
mv: der Aufruf von stat für './/dpkg.statoverride.3.gz' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
mv: der Aufruf von stat für './/dpkg.statoverride.2.gz' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
gzip: .//dpkg.statoverride.0: No such file or directory

Die Dateien sind alle ein halbes Jahr alt, und wenn ich sie verschiebe, werden sie mit gleichen Datum neu erstellt

-rw-r--r--  1 root root      388 Jul  3  2021 dpkg.statoverride.0
-rw-r--r--  1 root root      238 Jul  3  2021 dpkg.statoverride.1.gz
-rw-r--r--  1 root root      238 Jul  3  2021 dpkg.statoverride.2.gz
-rw-r--r--  1 root root      238 Jul  3  2021 dpkg.statoverride.3.gz
-rw-r--r--  1 root root      238 Jul  3  2021 dpkg.statoverride.4.gz
-rw-r--r--  1 root root       40 Jan 12 06:25 dpkg.statoverride.5.gz
-rw-r--r--  1 root root      238 Jul  3  2021 dpkg.statoverride.6.gz

weholei schrieb:

root@raspi4:~$ env -i /etc/cron.daily/mlocate
/usr/bin/updatedb.mlocate: can not open a temporary file for `/var/lib/mlocate/mlocate.db'

ist mir auch aufgefallen, ich sehe nur unter webmin den crontab, aber nicht, wenn ich als root crontab -l eingebe

kann mir jemand sagen, warum?

Das ist doch die systemweite crontab (... mit /etc/cron.daily) und keine eigene root crontab. Deshalb kannst Du die mit "root crontab -l" nicht sehen. Oder hast Du auch eine root crontab erstellt?

Danke für die schnelle Antwort

Oder hast Du auch eine root crontab erstellt?

einige backup Aufträge lasse ich als root ausführen

Das ist doch die systemweite crontab (... mit /etc/cron.daily) und keine eigene root crontab.

Danke für die Info, wieder was neues gelernt

Was mir aufgefallen ist, unter Ubuntu 20.04 ist der gleiche crontab Eintrag vorhanden ( nur mit webmin sichtbar)

Bei dem fehlerhaften pi4 ist dieser 3 x aufgeführt, offenbar der gleiche.

Da ich aber nicht weiß, wie ich diesen sichern und wiederherstellen kann, habe ich es nicht gewagt die 2 überzähligen zu löschen

kann mir da wer weiterhelfen?

./. edit

das ist mir noch aufgefallen:

root@raspi4:/var/backups# dir
insgesamt 2324
Auszug:
-rw-r--r--  1 root root       388 Jul  3  2021 dpkg.statoverride.0
-rw-r--r--  1 root root   2151661 Jan 14 09:31 dpkg.status.0
drwxr-xr-x  2 root root      4096 Dez  6 08:39 nach_apt_upgrade_6.12.2021
drwxr-xr-x  2 root root      4096 Nov 29 23:11 verschoben
drwxr-xr-x  2 root root      4096 Jan 14 09:51 verschoben_14.1.2022
drwxr-xr-x  2 root root      4096 Dez  6 08:36 vor_apt_upgrade_6.12.21
r

habe vorher alle dateien in /bar/backups/ verschoben

Hat keiner mehr einen Tip?

Schade, es hat so vielversprechend angefangen.

Dann werde ich wohl, wenn nichts mehr kommt mit try and error weitermachen müssen.

weholei schrieb:

Bei dem fehlerhaften pi4 ist dieser 3 x aufgeführt, offenbar der gleiche.

Da ich aber nicht weiß, wie ich diesen sichern und wiederherstellen kann, habe ich es nicht gewagt die 2 überzähligen zu löschen

kann mir da wer weiterhelfen?

Ich verstehe nicht was Du sagen willst. Was genau meinst Du mit "dieser 3x aufgeführt"? ... bzw. wo soll dir geholfen werden?

Danke für die Antwort

Im Webmin sehe ich 3 x den gleichen Cronjob

ich habe jetzt die Möglichkeit gefunden, diesen mit Webmin zu deaktivieren

Das ist doch die systemweite crontab (... mit /etc/cron.daily

Ich weiß nicht, wo die gestartet werden, in der crontab nicht.

weholei schrieb:

Ich weiß nicht, wo die gestartet werden, in der crontab nicht.

Wer sind, "die"?

Aber evtl. weiß ich was Du mit "die" meinst und sage dir, dass "die" von systemd-timern, gestertet werden, denn das kann man mit z. B.:

# skip in favour of systemd timer
if [ -d /run/systemd/system ]; then
    exit 0
fi

sehen.

Danke für die schnelle Antwort

Ich gehe davon aus, daß ich diese Zeichen in ein script einfügen muss, oder?

Das habe ich gemacht, kommt kein Fehler zurück

root@raspi4:~# ./test-cron.scr 
root@raspi4:~# 

Ich werde versuchen, mich verständlich auszudrücken

Wer sind, "die"?

Ich sehe mit webmin, dass 3 x der geleiche cronjob ausgeführt wird, 2, davon habe ich heute einmal deaktiviert

/etc/cron.daily/dpkg:

"dpkg" ist doch der Paket-Manager und der wird vom "System" ausgeführt, oder?

root@raspi4:/etc/cron.daily# dir
insgesamt 64

-rwxr-xr-x   1 root root  1187 Apr 19  2019 dpkg

durch welche "Aktion" erhalten diese Dateien einen neuen Zeitstempel?

durch apt update oder apt upgrade jedenfalls nicht

-rw-r--r--  1 root root       238 Jul  3  2021 dpkg.statoverride.6.gz
-rw-r--r--  1 root root   2151661 Jan 18 11:06 dpkg.status.0

Vermutlich habe ich heute vormittag mit "webmin" den cron job manuell ausgeführt, denn die eine datei hat einen neueren Zeitstempel

Ist das etwas verständlicher?

Ich vermute, daß der Fehler von einer vor einem halben Jahr voll gelaufenen Systempartition kommt.

Wie man vor dem Backup prüft, ob das Laufwerk gemountet wird, hat man mir hier im Forum gut erklärt.

weholei schrieb:

Ich gehe davon aus, daß ich diese Zeichen in ein script einfügen muss, oder?

Keinesfalls, ... denn wenn so ein Script die crontab ignorieren soll und eine _vorhandene_ timer-unit benutzt werden soll, dann sind diese Zeilen schon dort im Script an der richtigen Stelle, eingetragen.

Danke für die Antwort, auch wenn ich immer noch an dem für mich schwer verdaulichen Brocken kaue.

und eine _vorhandene_ timer-unit benutzt werden soll, dann sind diese Zeilen schon dort im Script an der richtigen Stelle, eingetragen.

ich habe mich schlau gemacht und das im Forum das gefunden:

Wiki systemd Timer Units

Timer Units werden als einfache Textdateien angelegt^[2], mit einer Syntax und einem Aufbau ähnlich INI-Dateien. Der Dateiname kann frei gewählt werden, muss aber auf .timer enden. Selbsterstellte Timer werden im Verzeichnis /etc/systemd/system abgespeichert,

Unter /etc/systemd/system sind zwar einige Dateien, aber keine, die auf .timer endet

Das ist doch die systemweite crontab (... mit /etc/cron.daily) und keine eigene root crontab. Deshalb kannst Du die mit "root crontab -l" nicht sehen.

das habe ich gelernt, aber offenbar gibt es doch ein paar Unterschiede bei anacron zwischen Ubuntu und noobs von raspi4, z.b kein /usr/sbin/anacron berim Raspi4

Deshalb reden wir aneinandder vorbei und hat man mir im Raspberry Forum eine Neuinstallation mit einem anderem OS nahegelegt.

Da werde ich wohl noch viel lesen müssen.

Die gute Nachricht ist, heute kam keine Fehlermail mehr, nachdem ich mit mit dem viel geschmähten Webmin zwei der 3 gleichen Cronjobs deaktiviert habe.

Erstmal vielen Dank

weholei schrieb:

Unter /etc/systemd/system sind zwar einige Dateien, aber keine, die auf .timer endet

Siehe die Ausgabe von:

systemctl list-timers --all

weholei schrieb:

..., aber offenbar gibt es doch ein paar Unterschiede bei anacron zwischen Ubuntu und noobs von raspi4, z.b kein /usr/sbin/anacron berim Raspi4

Naja, NOOBS sollte man ja auch nicht benutzen. Poste mal den Link aus dem PI-Forum.

Volltreffer!

Danke, langsam kommt Land in Sicht

Den Befehl werde ich mir merken, habe nur rudimentäre kenntnisse mit "init.d"

Danke, langsam kommt Land in Sicht

NEXT                         LEFT       LAST                         PASSED      UNIT                         ACTIVATES
Wed 2022-01-19 11:31:43 CET  37min left Tue 2022-01-18 21:07:50 CET  13h ago     apt-daily.timer              apt-daily.service
Wed 2022-01-19 17:36:54 CET  6h left    Tue 2022-01-18 17:36:54 CET  17h ago     systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Thu 2022-01-20 00:00:00 CET  13h left   Wed 2022-01-19 00:00:54 CET  10h ago     logrotate.timer              logrotate.service
Thu 2022-01-20 00:00:00 CET  13h left   Wed 2022-01-19 00:00:54 CET  10h ago     man-db.timer                 man-db.service
Thu 2022-01-20 06:57:29 CET  20h left   Wed 2022-01-19 06:51:54 CET  4h 2min ago apt-daily-upgrade.timer      apt-daily-upgrade.service

Ich denke, der letzte Timer hat die Fehlermail mit "dpkg" verursacht

Poste mal den Link aus dem PI-Forum.

https://forum-raspberrypi.de/forum/thread/54482-seltsame-fehlermeldung-von-cron/?pageNo=2

Wenn ich da System neu aufsetzen muss, werde ich daran denken.

Naja, NOOBS sollte man ja auch nicht benutzen

Aber wegen einer Fehlermeldung das System neu aufsetzen wenn es seit ca 2 Jahren tut was es soll.... ?

Mir geht es mehr darum, das System zu verstehen und zu lernen.

weholei schrieb:

Thu 2022-01-20 06:57:29 CET  20h left   Wed 2022-01-19 06:51:54 CET  4h 2min ago apt-daily-upgrade.timer      apt-daily-upgrade.service

Ich denke, der letzte Timer hat die Fehlermail mit "dpkg" verursacht

Den Inhalt der timer-/service-unit bzw. der Scripte kannst Du dir auch anschauen:

systemctl cat apt-daily-upgrade.timer
systemctl cat apt-daily-upgrade.service
cat /usr/lib/apt/apt.systemd.daily
cat /usr/lib/apt/apt.systemd.daily | grep -i mail

Wenn Du weißt was Du tust, kannst Du im Script, das mailen evtl. auch deaktivieren.

weholei schrieb:

Aber wegen einer Fehlermeldung das System neu aufsetzen wenn es seit ca 2 Jahren tut was es soll.... ?

Wenn das System tut was es soll, musst Du nicht neu aufsetzen. Wenn Du die Fehlermeldung nicht haben willst, dann diese deaktivieren.