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
Wenn nach 10 Tagen mehrere Giga(!)byte an Logdateien anfallen, liegt der Fehler eher an anderer Stelle..
Mit
1 | sudo systemctl disable rsyslog |
sollte man auf einem aktuellen Debian/Raspbian nichtsdestotrotz das Meiste ausschalten können..
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
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.
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.
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.
Frank E. schrieb: > > Browser Chromium)
1 | chromium-browser --disk-cache-size=XXX |
limitiert noch den Cache vom Browser.
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.
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)
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.
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).
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' |
Joachim B. schrieb: > ich ja, für Synergy die DEBUG Ausgaben wachsen ständig in den Himmel! Warum hast Du das Debugging denn eingeschaltet?
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 ...
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.
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.
test schrieb: > LINUX ist zum durchlaufen gedacht. Will man da ständig an-ausschalten > muss man Hand anlegen. Vollkommener Blödsinn!
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.
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.
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...
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
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.
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?
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.
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.
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.
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.
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.
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.
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
Nein, er schaltet ihm mit einer WLAN Steckdose den Strom ab.
Grmf. Antwort auf "Ah, stimmt, er legt sie ja nur schlafen."
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 :-)))
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.
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.
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
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
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
Trenn mal die Verbindung zum Touch-Sensor (ADS7846) und schau mal ob die Meldungen dann verschwinden.
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
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.
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.
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 |
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).
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!
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.