Forum: Mikrocontroller und Digitale Elektronik Raspberry: Jegliches Logging dauerhaft deaktivieren?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe mehrere Raspis als Info-Diplays mit Browser im 
12/7-Dauerbetrieb, d.h. sie werden abends per shutdown schlafen 
geschickt und morgens durch Strom-ab- und anschalten wieder gestartet.

Aller ca. 10...14 Tage starten die nicht mehr durch, weil die 
16GB-Karten mit Log- und Cachefiles vollgestopft sind. Ein manueller 
Eingriff per SSH und reboot helfen jeweils - was aber auf Dauer nervt.

Im Web finde ich nat. Lösungen zu dem Thema - aber wie immer bei Linux: 
200 Varianten und man kann nie sicher sein, dass es wirklich 
funktioniert.

Hat hier jemand Erfahrung damit, in welche (Config-) Datei man was 
Einfügen muss, um möglichst jegliches Logging (brauche ich nicht) zu 
unterbinden? Und vor Allem permanent - gerade das geht aus den wenigsten 
Web-Beiträgen hervor.

Beim Browser-Cashing bin ich mir nicht sicher, da es ja beim Aufruf 
immer der gleichen Seiten auch zu Geschwindigkeitsgewinn führt und - 
wenn die notwendigen Chache-Objekte einmal da sind - auch kein weiterer 
Zuwachs zu erwarten ist. Wie lange "lebt" so ein Cache-Eintrag? Kann man 
das permanent/persistent machen?

(System Raspian Stretch, Browser Chromium)

: Bearbeitet durch User
von JH (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Wenn nach 10 Tagen mehrere Giga(!)byte an Logdateien anfallen, liegt der 
Fehler eher an anderer Stelle..

von JH (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Mit
1
sudo systemctl disable rsyslog
sollte man auf einem aktuellen Debian/Raspbian nichtsdestotrotz das 
Meiste ausschalten können..

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
noch lösche ich die LOGs der schlimmsten Übeltäter per cronjob

eine pauschale Umleitung der /etc/log nach /dev/nul habe ich noch nicht 
gemacht, ich weiss auch nicht ob das hilft, wo speicher chromium 
eigentlich seine Seiten Cache?
Man kann eben nicht sicher sein wo überall "geloggt" wird.
Leider werden so die SD Karten ALLE irgendwann unnötig 
kaputtgeschrieben.
Bin schon am überlegen ob ich nicht alle nur noch vom NAS booten lasse.

JH schrieb:
> Wenn nach 10 Tagen mehrere Giga(!)byte an Logdateien anfallen, liegt der
> Fehler eher an anderer Stelle..

ja bei den vielen Programmierer die nicht weiterdenken als nötig!
Oder sie haben Sponsorverträge mit SD Kartenhersteller.

: Bearbeitet durch User
von ishmael (Gast)


Bewertung
1 lesenswert
nicht lesenswert
als erstes mal herausfinden welche logs so groß werden und warum.

logrotate ist ein erster ansatz um logging zu behalten aber die größe zu 
begrenzen - alternativ cronjob und truncate.

browser-cache mit symlink nach /dev/null umbiegen, dann kann der browser 
so viel speichern wie er will. wie lange irgendwas im cache bleibt ist 
nicht definiert, max-age liefert einen hinweis wie lange maximal bis 
eine neue version gesucht wird.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank E. schrieb:
> Ich habe mehrere Raspis als Info-Diplays mit Browser im
> 12/7-Dauerbetrieb, d.h. sie werden abends per shutdown schlafen
> geschickt und morgens durch Strom-ab- und anschalten wieder gestartet.
>
> Aller ca. 10...14 Tage starten die nicht mehr durch, weil die
> 16GB-Karten mit Log- und Cachefiles vollgestopft sind. Ein manueller
> Eingriff per SSH und reboot helfen jeweils - was aber auf Dauer nervt.

Das ist allerdings ungewöhnlich. Habe ich hier bei unseren Raspis (hier 
allerdings mit Firefox) noch nicht beobachtet.

Normalerweise werden die Log-Dateien per cron-job regelmäßig gezippt und 
die ältesten weggeworfen.

Kann es sein, dass durch den Halbtagsbetrieb diese cron-jobs gar nicht 
angestoßen werden?

> Es kann aber sein, dass
> Im Web finde ich nat. Lösungen zu dem Thema - aber wie immer bei Linux:
> 200 Varianten und man kann nie sicher sein, dass es wirklich
> funktioniert.
>
> Hat hier jemand Erfahrung damit, in welche (Config-) Datei man was
> Einfügen muss, um möglichst jegliches Logging (brauche ich nicht) zu
> unterbinden? Und vor Allem permanent - gerade das geht aus den wenigsten
> Web-Beiträgen hervor.
>
> Beim Browser-Cashing bin ich mir nicht sicher, da es ja beim Aufruf
> immer der gleichen Seiten auch zu Geschwindigkeitsgewinn führt und -
> wenn die notwendigen Chache-Objekte einmal da sind - auch kein weiterer
> Zuwachs zu erwarten ist. Wie lange "lebt" so ein Cache-Eintrag? Kann man
> das permanent/persistent machen?

Hast Du mal explizit nachgeschaut, wo sich die "dicken Brocken" 
ansammeln?

Oder gibt es Dienste, die auf massives Debug-Logging eingestellt wurden?

Die Holzhammermethode wäre, die Log-Dateien per Startup-Skript 
plattzumachen.

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
Chris D. schrieb:
> Hast Du mal explizit nachgeschaut, wo sich die "dicken Brocken"
> ansammeln?

ich ja, für Synergy die DEBUG Ausgaben wachsen ständig in den Himmel!

> Die Holzhammermethode wäre, die Log-Dateien per Startup-Skript
> plattzumachen.

und wenn es normal keinen Startup geben soll, dann greift das Script 
aber auch nicht.

von JH (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank E. schrieb:
>
> Browser Chromium)
1
chromium-browser --disk-cache-size=XXX

limitiert noch den Cache vom Browser.

von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> Holzhammermethode wäre, die Log-Dateien per Startup-Skript
>> plattzumachen.
>
> und wenn es normal keinen Startup geben soll, dann greift das Script
> aber auch nicht.

Ah, stimmt, er legt sie ja nur schlafen.

Ok, dann müsste man einen cronjob einrichten, der das stündlich 
plattmacht.

Ich schaue gerade mal nach, was unser kleiner Raspi so angesammelt hat. 
Der hat allerdings keinen Browser offen sondern steuert nur unsere 
Spritzgussmaschine.

von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
Bei den Raspis 3+ handelt es sich um ein im Grunde unverändertes Raspian 
Stretch, lediglich ergänzt um einen Eintrag zum Auto-Start des 
Chromium-Browsers im Kiosk-Mode und mit einer interenen URL (LAN) ... 
sonst nix.

Ach ja, und der Treiber für ein Waveshare-10-Zoll-Touchdisplay ist 
drauf. Video läuft über HDMI, Touch über die GPIOs. Die Raspis sind über 
WLAN mit einem Accesspoint im LAN verbunden. Die Raspis haben keinen 
Zugang zum Internet (per DHCP wird falsche Gateway-IP 0.0.0.0 
ausgeliefert)

von Gerd E. (robberknight)


Bewertung
0 lesenswert
nicht lesenswert
Frank E. schrieb:
> Ich habe mehrere Raspis als Info-Diplays mit Browser im
> 12/7-Dauerbetrieb, d.h. sie werden abends per shutdown schlafen
> geschickt und morgens durch Strom-ab- und anschalten wieder gestartet.

Dann solltest Du alle Dateisysteme nur als read-only mounten und die 
Logs nur im RAM speichern.

Das mit den logs kann z.B. der busybox-syslogd und logread von Haus aus. 
Das kann man recht einfach z.B. bei Raspbian einbinden. Wenn der 
zugewiesene RAM-Block voll ist, werden die ältesten Logeinträge 
verworfen.

> Aller ca. 10...14 Tage starten die nicht mehr durch, weil die
> 16GB-Karten mit Log- und Cachefiles vollgestopft sind.

Das ist noch harmlos. Lustig wird es wenn es Dateisystemfehler oder gar 
Hardwarefehler auf der SD-Karte gibt, weil während dem Löschvorgang des 
Flash der Strom ausgegangen ist.

von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
Wie mir ein Mitarbeiter gerade mitteilt, handelt es sich wohl 
hauptsächlich um das "kernel log", was so viel Zeugs wegschreibt.

Beschädigungen des Dateisystems haben wir bisher nicht. Die Raspis 
werden per SSH "shutdown now" schlafen geschickt. Ein PHP-Script pingt 
dann so lange, bis Ruhe ist, wartet zusätzlich 10s und schaltet dann den 
Strom ab (WLAN-Steckdose).

von Himbeere (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Was sagt denn
1
find /var /home /etc /usr /lib /tmp -mmin -600 -type f -printf '%CY-%Cm-%Cd_%CH:%CM:%CS %9s %p\n'

von Brummbär (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> ich ja, für Synergy die DEBUG Ausgaben wachsen ständig in den Himmel!

Warum hast Du das Debugging denn eingeschaltet?

von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
Himbeere schrieb:
> Was sagt denn find /var /home /etc /usr /lib /tmp -mmin -600 -type
> f -printf '%CY-%Cm-%Cd_%CH:%CM:%CS %9s %p\n'

schreibst du bitte auch dazu, was das genau bewirken soll? Es wird etwas 
im tmp-Verzeichnis gesucht und die Ausgabe formatiert ... mit Return am 
Ende ...

von Harry L. (mysth)


Bewertung
2 lesenswert
nicht lesenswert
Wenn die SD nach so kurzer Zeit überläuft, ist die Konfiguration bereits 
kaputt.

Ich hab hier RPis, die auf einer 4GB-Karte Uptimes von >6mon. haben, und 
da passiert rein gar nix.
Der Speicherbedarf der Logs wird durch logrotate gedeckelt. 
(Standard-Einstellung)

Statt an den Symptomen herum zu doktern würde ich erstmal die Ursache 
dafür lokalisieren.

von test (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Harry L. schrieb:
> Ich hab hier RPis, die auf einer 4GB-Karte Uptimes von >6mon. haben, und
> da passiert rein gar nix.
> Der Speicherbedarf der Logs wird durch logrotate gedeckelt.
> (Standard-Einstellung)

Der läuft dann ja auch durch ;-)

LINUX ist zum durchlaufen gedacht. Will man da ständig an-ausschalten 
muss man Hand anlegen.

Also crontab anschauen und dann wichtige Dinge beim Systemstart extra 
ausführen lassen.

von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
test schrieb:

> LINUX ist zum durchlaufen gedacht. Will man da ständig an-ausschalten
> muss man Hand anlegen.

Vollkommener Blödsinn!

von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
Harry L. schrieb:

> Statt an den Symptomen herum zu doktern würde ich erstmal die Ursache
> dafür lokalisieren.

Hast du vlt. auch einen Tip, was die Ursache sein könnte? Wie ich oben 
schrieb, ist es ein Standard-Raspian mit Chromium, eingesperrt im LAN.

von Cyblord -. (cyblord)


Bewertung
0 lesenswert
nicht lesenswert
Joachim B. schrieb:
> noch lösche ich die LOGs der schlimmsten Übeltäter per cronjob

Aber nicht vergessen über die Löschvorgänge ein Log anzulegen. Nur zur 
Sicherheit.

von Jan L. (ranzcopter)


Bewertung
0 lesenswert
nicht lesenswert
Frank E. schrieb:
> Harry L. schrieb:
>
>> Statt an den Symptomen herum zu doktern würde ich erstmal die Ursache
>> dafür lokalisieren.
>
> Hast du vlt. auch einen Tip, was die Ursache sein könnte? Wie ich oben
> schrieb, ist es ein Standard-Raspian mit Chromium, eingesperrt im LAN.

> Wie mir ein Mitarbeiter gerade mitteilt, handelt es sich wohl
> hauptsächlich um das "kernel log", was so viel Zeugs wegschreibt.

=> "kernel log" Auszug posten, dann liesse sich sicher erkennen, was 
"Zeugs" bedeuten könnte...

von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Frank E. schrieb:
> Wie mir ein Mitarbeiter gerade mitteilt, handelt es sich wohl
> hauptsächlich um das "kernel log", was so viel Zeugs wegschreibt.

Da wäre es doch von Interesse, sich den Inhalt dieser Datei einmal 
genauer anzusehen, oder? ;-)

Irgendwoher müssen die ganzen Meldungen dort ja kommen.

Also her damit - aber bitte nicht die gesamte Datei, sondern relevante 
Meldungen (=die, die offenbar permanent geschrieben werden) :-)

Edit: Jan war schneller

: Bearbeitet durch Moderator
von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
Frank E. schrieb:
> Harry L. schrieb:
>
>> Statt an den Symptomen herum zu doktern würde ich erstmal die Ursache
>> dafür lokalisieren.
>
> Hast du vlt. auch einen Tip, was die Ursache sein könnte? Wie ich oben
> schrieb, ist es ein Standard-Raspian mit Chromium, eingesperrt im LAN.

Nein, nicht aus der Ferne.
Schau dir an, wer die Masse an Einträgen produziert.(Logs untersuchen!)

Ich könnte mir vorstellen, daß deine vermurkste DHCP-Konfiguration 
(Gateway: 0.0.0.0) zu einigem Gemecker führt.

Sicherheit bietet das sowieso nicht.
Dafür nutzt man einen Firewall.
Das kann ein weiterer RPI sein oder ufw als lokaler Firewall auf jedem 
einzelnen RPi.

von Cyblord -. (cyblord)


Bewertung
4 lesenswert
nicht lesenswert
Chris D. schrieb:
> Da wäre es doch von Interesse, sich den Inhalt dieser Datei einmal
> genauer anzusehen, oder? ;-)

Was kommt als nächstes? Lesen von Fehlermeldungen?

von Chris D. (myfairtux) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Cyblord -. schrieb:
> Chris D. schrieb:
>> Da wäre es doch von Interesse, sich den Inhalt dieser Datei einmal
>> genauer anzusehen, oder? ;-)
>
> Was kommt als nächstes? Lesen von Fehlermeldungen?

Ganz genau.

von Bauform B. (bauformb)


Bewertung
1 lesenswert
nicht lesenswert
test schrieb:
> LINUX ist zum durchlaufen gedacht. Will man da ständig an-ausschalten
> muss man Hand anlegen.

Indem man das Paket anacron installiert, und gut ist.

Oder man legt einen Link von /var/log auf /tmp an. Dann hat man tagsüber 
immer noch die aktuellen Logfiles und beim nächsten Einschalten sind sie 
einfach weg.

von Joachim B. (jar)


Bewertung
-2 lesenswert
nicht lesenswert
Brummbär schrieb:
> Joachim B. schrieb:
>> ich ja, für Synergy die DEBUG Ausgaben wachsen ständig in den Himmel!
>
> Warum hast Du das Debugging denn eingeschaltet?

wer sagt immer es gibt keine dummen Fragen?
wie kommst du auf das schmale Brett?
warum schreibst du sowas?

ICH habe nichts eingeschaltet, es "nur" installiert.

von Marten Morten (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Harry L. schrieb:
> Ich könnte mir vorstellen, daß deine vermurkste DHCP-Konfiguration
> (Gateway: 0.0.0.0) zu einigem Gemecker führt.

Ja, dann lieber gar keine Gateway-Info per DHCP ausliefern oder es mit 
einer Adresse wie 127.0.0.1 zu versuchen.

Wenn es insgesamt nur zwei, drei Hosts sind, könnte man sogar drüber 
nachdenken DHCP komplett abzuschalten und alle Hosts statisch von Hand 
zu konfigurieren.

> Sicherheit bietet das sowieso nicht.
> Dafür nutzt man einen Firewall.
> Das kann ein weiterer RPI sein oder ufw als lokaler Firewall auf jedem
> einzelnen RPi.

Kabel des AP zum Internet ausstecken wäre die einfachste Variante. Ich 
verstehe nicht, warum der AP überhaupt Intenet-Verbindung hat, wenn das 
Netz keine Verbindung haben soll.

von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
Marten Morten schrieb:
> Ja, dann lieber gar keine Gateway-Info per DHCP ausliefern oder es mit
> einer Adresse wie 127.0.0.1 zu versuchen.
>
> Wenn es insgesamt nur zwei, drei Hosts sind, könnte man sogar drüber
> nachdenken DHCP komplett abzuschalten und alle Hosts statisch von Hand
> zu konfigurieren.

....wenn man keine Ahnung hat, versucht man es mit dem Holzhammer.

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe eine Raspberry Pi mit Raspbian seit fast einem Jahr 
ununterbrochen am Laufen. Abweichend von der Standardkonfiguration habe 
ch:

- Die GUI deaktiviert
- Einen Apache Server mit PHP installiert, der fast völlig ungenutzt 
herum idelt.
- Einen Cron-Job (Shell Script) installiert, der jede Minute die 
Erreichbarkeit einiger Webserver prüft und die Ergebnisse loggt.
- In /etc/fstab die Option noatime hinzugefügt.

Die Schreibzugriffe auf die SD Karten halten sich in sehr moderaten 
Grenzen. Sie funktioniert noch einwandfrei. Ich habe nichts unternommen, 
um das Logging zu reduzieren.

Auch um die Swap Partition habe ich mich nicht gekümmert, nachdem ich 
bemerkt habe, dass sie ohnehin nicht genutzt wird.

von Axel L. (axel_5)


Bewertung
0 lesenswert
nicht lesenswert
ishmael schrieb:
> als erstes mal herausfinden welche logs so groß werden und warum.
>
> logrotate ist ein erster ansatz um logging zu behalten aber die größe zu
> begrenzen - alternativ cronjob und truncate.
>
> browser-cache mit symlink nach /dev/null umbiegen, dann kann der browser
> so viel speichern wie er will. wie lange irgendwas im cache bleibt ist
> nicht definiert, max-age liefert einen hinweis wie lange maximal bis
> eine neue version gesucht wird.

Das bringt nicht viel. Der Browser Cache speichert die Seiteninhalte, 
die Chronik wird im Profil abgelegt. Bei jedem Seitenaufruf wird daher 
aufs Profil zugegriffen und die Seitenadresse (und anderes, Cookies und 
so) für die Chronik abgelegt.

Gruß
Axel

von Lutz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Nein, er schaltet ihm mit einer WLAN Steckdose den Strom ab.

von Lutz (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Grmf. Antwort auf "Ah, stimmt, er legt sie ja nur schlafen."

von adi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Frank E. schrieb:
> Aller ca. 10...14 Tage starten die nicht mehr durch, weil die
> 16GB-Karten mit Log- und Cachefiles vollgestopft sind. Ein manueller
> Eingriff per SSH und reboot helfen jeweils - was aber auf Dauer nervt.

Hallo Frank,

wie du merkst, löst deine verschwommene Problembeschreibung "16GB-Karten 
mit Log- und Cachefiles vollgestopft" kreatives Rätselraten aus. Wie 
wärs eigentlich, wenn du dir ein bisschen Mühe gibts und konkrett 
schreibst, welche Logs bzw. Cachefiles es genau sind und wie groß, am 
besten eine Ausgabe mit "ls -lh", sonst gehts so wie bisher weiter :-)))

von Marten Morten (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Harry L. schrieb:
> Marten Morten schrieb:
>> Ja, dann lieber gar keine Gateway-Info per DHCP ausliefern oder es mit
>> einer Adresse wie 127.0.0.1 zu versuchen.
>>
>> Wenn es insgesamt nur zwei, drei Hosts sind, könnte man sogar drüber
>> nachdenken DHCP komplett abzuschalten und alle Hosts statisch von Hand
>> zu konfigurieren.
>
> ....wenn man keine Ahnung hat, versucht man es mit dem Holzhammer.

Wenn man schon Netze die halbe Kontinente überspannen geplant hat, dann 
lacht man über ein paar Hosts und hat kein Problem mit dem 
Holzhämmerchen sanft anzuklopfen. Wenn man natürlich CCNA-Dogmatiker 
ist, dann geht dabei die Welt unter.

von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
Ich besorge so ein File, wird etwas dauern ... vlt. auch bis morgen ...

Beitrag #5728602 wurde von einem Moderator gelöscht.
Beitrag #5728664 wurde von einem Moderator gelöscht.
von bernd (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Moin!

Wie wäre es mit einem simplen "sudo du -h /var/log/*".
Da sieht man auf den ersten Blick wer der Übeltäter ist.

Ahoi

von Joachim B. (jar)


Bewertung
0 lesenswert
nicht lesenswert
bernd schrieb:
> sudo du -h /var/log/*

eher mit sudo du -h -b /var/log/*

Größe ist auch wichtig und Datum wäre nett, finde ich aber nicht

292292  /var/log/lastlog

schon wieder ganz schön fett für den PI

von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
Das hier taucht quasi sekündlich im Kernellog auf. Wie oben beschrieben, 
es ist ein Standard-Raspian mit 'nem Browser im Kiosk-Mode und den 
Touch-Treibern und WLAN-Connection zum Webserver (Synology) im LAN ...
1
Feb  9 12:14:47 gemmen_1 kernel: [   18.506992] ------------[ cut here ]------------
2
Feb  9 12:14:47 gemmen_1 kernel: [   18.507027] WARNING: CPU: 2 PID: 480 at kernel/irq/manage.c:527 __enable_irq+0x54/0x80
3
Feb  9 12:14:47 gemmen_1 kernel: [   18.507032] Unbalanced enable for IRQ 40
4
Feb  9 12:14:47 gemmen_1 kernel: [   18.507036] Modules linked in: fuse rfcomm cmac bnep hci_uart btbcm bluetooth evdev joydev panel_raspberrypi_touchscreen ads7846 hwmon brcmfmac vc4 brcmutil drm_kms_helper cfg80211 drm snd_soc_core rfkill snd_compress snd_pcm_dmaengine syscopyarea sysfillrect sysimgblt fb_sys_fops snd_bcm2835 i2c_gpio i2c_algo_bit snd_pcm snd_timer snd i2c_bcm2835 spi_bcm2835 bcm2835_gpiomem fixed uio_pdrv_genirq uio i2c_dev ip_tables x_tables ipv6
5
Feb  9 12:14:47 gemmen_1 kernel: [   18.507205] CPU: 2 PID: 480 Comm: Xorg Tainted: G        W       4.9.80-v7+ #1098
6
Feb  9 12:14:47 gemmen_1 kernel: [   18.507210] Hardware name: BCM2835
7
Feb  9 12:14:47 gemmen_1 kernel: [   18.507236] [<8010fa48>] (unwind_backtrace) from [<8010c058>] (show_stack+0x20/0x24)
8
Feb  9 12:14:47 gemmen_1 kernel: [   18.507254] [<8010c058>] (show_stack) from [<80457a04>] (dump_stack+0xd4/0x118)
9
Feb  9 12:14:47 gemmen_1 kernel: [   18.507273] [<80457a04>] (dump_stack) from [<8011d31c>] (__warn+0xf8/0x110)
10
Feb  9 12:14:47 gemmen_1 kernel: [   18.507286] [<8011d31c>] (__warn) from [<8011d37c>] (warn_slowpath_fmt+0x48/0x50)
11
Feb  9 12:14:47 gemmen_1 kernel: [   18.507300] [<8011d37c>] (warn_slowpath_fmt) from [<80175da8>] (__enable_irq+0x54/0x80)
12
Feb  9 12:14:47 gemmen_1 kernel: [   18.507315] [<80175da8>] (__enable_irq) from [<80175e18>] (enable_irq+0x44/0x7c)
13
Feb  9 12:14:47 gemmen_1 kernel: [   18.507393] [<80175e18>] (enable_irq) from [<7f3e0c40>] (vc4_irq_postinstall+0x24/0x40 [vc4])
14
Feb  9 12:14:47 gemmen_1 kernel: [   18.507509] [<7f3e0c40>] (vc4_irq_postinstall [vc4]) from [<7f3e38f0>] (vc4_v3d_runtime_resume+0x58/0x60 [vc4])
15
Feb  9 12:14:47 gemmen_1 kernel: [   18.507580] [<7f3e38f0>] (vc4_v3d_runtime_resume [vc4]) from [<8050391c>] (pm_generic_runtime_resume+0x3c/0x48)
16
Feb  9 12:14:47 gemmen_1 kernel: [   18.507598] [<8050391c>] (pm_generic_runtime_resume) from [<80507724>] (__genpd_runtime_resume+0x3c/0x9c)
17
Feb  9 12:14:47 gemmen_1 kernel: [   18.507612] [<80507724>] (__genpd_runtime_resume) from [<805091f4>] (genpd_runtime_resume+0xd8/0x1a4)
18
Feb  9 12:14:47 gemmen_1 kernel: [   18.507625] [<805091f4>] (genpd_runtime_resume) from [<80504eb4>] (__rpm_callback+0x48/0x98)
19
Feb  9 12:14:47 gemmen_1 kernel: [   18.507638] [<80504eb4>] (__rpm_callback) from [<80504f34>] (rpm_callback+0x30/0x90)
20
Feb  9 12:14:47 gemmen_1 kernel: [   18.507649] [<80504f34>] (rpm_callback) from [<80506320>] (rpm_resume+0x4bc/0x704)
21
Feb  9 12:14:47 gemmen_1 kernel: [   18.507661] [<80506320>] (rpm_resume) from [<805065d8>] (__pm_runtime_resume+0x70/0x9c)
22
Feb  9 12:14:47 gemmen_1 kernel: [   18.507723] [<805065d8>] (__pm_runtime_resume) from [<7f3dd78c>] (vc4_submit_cl_ioctl+0x160/0x954 [vc4])
23
Feb  9 12:14:47 gemmen_1 kernel: [   18.508056] [<7f3dd78c>] (vc4_submit_cl_ioctl [vc4]) from [<7f1a3c60>] (drm_ioctl+0x20c/0x428 [drm])
24
Feb  9 12:14:47 gemmen_1 kernel: [   18.508352] [<7f1a3c60>] (drm_ioctl [drm]) from [<80283f68>] (do_vfs_ioctl+0xac/0x820)
25
Feb  9 12:14:47 gemmen_1 kernel: [   18.508383] [<80283f68>] (do_vfs_ioctl) from [<80284720>] (SyS_ioctl+0x44/0x6c)
26
Feb  9 12:14:47 gemmen_1 kernel: [   18.508402] [<80284720>] (SyS_ioctl) from [<801080c0>] (ret_fast_syscall+0x0/0x1c)
27
Feb  9 12:14:47 gemmen_1 kernel: [   18.508413] ---[ end trace 5e7ed280a81af776 ]---

: Bearbeitet durch User
von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
Trenn mal die Verbindung zum Touch-Sensor (ADS7846) und schau mal ob die 
Meldungen dann verschwinden.

von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
Harry L. schrieb:
> Trenn mal die Verbindung zum Touch-Sensor (ADS7846) und schau mal
> ob die
> Meldungen dann verschwinden.

Das geht schlecht bzw. nur an einem extra Versuchsaufbau. Die Raspis 
stecken mit ihren GPIOs hinten auf 10"-Touchscreens von Waveshare ...

Aber selbst wenn das die Lösung wäre - ich brauche ja den Touchscreen.

Wenn ich jetzt mal ganz pragmatisch denke, ist es mir eigentlich auch 
völlig egal, was da geloggt wird, denn der Raspi tut ansonsten, was er 
soll.

Ich suche schlicht und einfach ein Kommando, was sämtliches Logging 
dauerhaft abschaltet damit meine SD-Karte nicht vollgemüllt wird und 
Ruhe ist.

Ist denn

"systemctl disable syslog"

persistent und konsequent genug, oder muss ich das (und Weiteres) in 
irgendeine Datei eintragen? Wenn ja, in welche? Danke.

: Bearbeitet durch User
von Harry L. (mysth)


Bewertung
3 lesenswert
nicht lesenswert
Frank E. schrieb:
> Wenn ich jetzt mal ganz pragmatisch denke, ist es mir eigentlich auch
> völlig egal, was da geloggt wird, denn der Raspi tut ansonsten, was er
> soll.
>
> Ich suche schlicht und einfach ein Kommando, was sämtliches Logging
> dauerhaft abschaltet damit meine SD-Karte nicht vollgemüllt wird und
> Ruhe ist.

Das ist mit Abstand die schlechteste aller Vorgehensweisen.
Finde raus, woher und warum die Meldungen kommen und stell die Ursache 
ab!

Alles Andere ist völliger Murks.

von Das ist doch alles total irre (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Die Frage, ob es ausreicht, kann dir niemand beantworten.

Die interne Komplexität ist komplett aus dem Ruder gelaufen. Linux 
Administration ist inzwischen ein Vollzeitjob für 5 Spezialisten. Einer 
alleine kann gar nicht mehr das ganze System überblicken.

Entweder du arbeitest die in die Sache so weit ein, dass du die 
sekündlichen Meldungen abschalten kannst, oder du probierst halt solange 
irgendwelche Tipps aus, bis einer dabei ist, der funktioniert. 
Anschliessend beten, dass es nach Updates, Vollmond oder Stromausfall 
immer noch funktioniert.

von Frank E. (Firma: Q3) (qualidat)


Bewertung
-1 lesenswert
nicht lesenswert
Habe unter:

https://raspberrypi.stackexchange.com/questions/62533/how-can-i-reduce-the-writing-to-log-files

diesen Tip gefunden und ausprobiert. Die Logfiles wachsen tatsächlich 
nicht mehr an und das System bootet auch noch ...
1
If you are not interested in the logs you can switch a lot off using a log configuration setting.
2
3
Edit the file /etc/rsyslog.conf and just after the section starting
4
5
###############
6
#### RULES ####
7
###############
8
9
add the following line.
10
11
*.*     ~
12
13
If you want to be more fine-grained you will need to read the file comments.
14
15
Do not forget to restart rsyslog daemon:
16
17
sudo service rsyslog restart

von S. R. (svenska)


Bewertung
4 lesenswert
nicht lesenswert
Frank E. schrieb:
> Das hier taucht quasi sekündlich im Kernellog auf.

Dann sollte es deine Priorität sein, das eigentliche Problem zu beheben 
und nicht die Hilferufe zum Schweigen zu bringen.

Kurze Google-Suche findet
https://bugs.launchpad.net/raspbian/+bug/1756553

Ein Kernel-Update oder Abschalten von OpenGL sollte die Meldungen also 
verschwinden lassen. Außerdem reduzieren sich dann Stromverbrauch und 
Wärmeentwicklung des Systems (weil die CPU dann auch mal zum Schlafen 
kommt).

von Harry L. (mysth)


Bewertung
0 lesenswert
nicht lesenswert
S. R. schrieb:
> Dann sollte es deine Priorität sein, das eigentliche Problem zu beheben
> und nicht die Hilferufe zum Schweigen zu bringen.

Thumbs Up!
perfekt auf den Punkt gebracht!

von Mario M. (thelonging)


Bewertung
0 lesenswert
nicht lesenswert

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.