Vorher muss aber unbedingt auf /dev/root freier Speicherplatz freigeschaufelt werden. Das hat erstmal oberste Priorität und natürlich ggf. die Ursache, warum die Logs überlaufen.
Normalerweise ist auch beim RaspiBlitz logrotate aktiv, wo Logs nach Fristen oder Größenbeschränkungen automatisch (zeitgesteuert aufgerufen) gekürzt und komprimiert werden.
Wie das genau mit Binär-Logs vom Systemd abläuft, entzieht sich im Moment meiner Kenntnis. Das ist mir nicht mehr so ganz präsent im Kopf. (Man wird nicht jünger und die Themen immer zahlreicher…)
Läuft alles wieder…zumindest was ich beurteilen kann. 
/dev/root ist bei ca. 17G. Muss ich im Auge behalten.
Danke euch allen ganz herzlich!
1 „Gefällt mir“
Mit den Befehlen wurde die Log-Dateien nur einmalig eingedampft, um es dauerhaft zu machen ist noch etwas arbeit notwendig. Kannst wie folgt vorgehen:
sudo nano /etc/systemd/journald.conf
An das Ende der Datei dann folgende Zeile anhängen
MaxRetentionSec=10day
mit
strg+o speichern
strg+x beenden
um es zu aktivieren ein herzhaftes
sudo systemctl restart systemd-journald
1 „Gefällt mir“
Vielen Dank! 
Hey Leute,
Meine Logs laufen weiterhin voll. 
interessanterweise sind mein syslog und daemon.log = 0. Dafür habe ich dies schönen syslog.1 und daemon.log.1 in riesiger Grösse, genauso wie messages.1 auth.log
habe nun mal die syslog.1 angeschaut und da siehts schon nicht so toll aus:
Gibts da Abhilfe?
Danke euch und happy Weekend allerseits.
F
So wie es aussieht, steht der Log-Mode(bitcoind) auf DEBUG. Gibt es im Raspiblitz Einstellung um das abzustellen, kenne mich mit Raspiblitz nicht aus?
Wenn du die Einstellung deaktiviert hast, kannst du nochmal
sudo journalctl --vacuum-size=1G
ausführen.
Danke fürs Antworten.
Ich habe auch keine Ahnung. 
Bin da schon über Limit. Die —vacuum funktion macht auch keine Verbesserung mehr. Komisch, dass das nicht mehr geht. Zeigt jeweils an, dass 0B freed. 
Auch die Limitierung auf 10d (MaxRetentionSec=10day) hat nicht gewirkt, da immer noch Daten von Mitte März geloggt sind.
Bin gerade erwas ratlos.
Vielleicht mal vorübergehend den LNDg ruhigstellen bzw. temporär deaktivieren. lnd und bitcoind Unit stoppen (mit sudo systemctl stop Servicename; für einen Überblick über alle laufenden Systemd-Services kannst du auch einfach mal systemctl ohne weitere Parameter aufrufen).
Ich meine damit erstmal nach Möglichkeit alles Geschwätzige zur Ruhe bringen, nicht die Node herunterfahren oder neustarten. Du willst erstmal Schnauze! in den digitalen Maschinenraum rufen und etablieren. Dann mal die die Logdateien säubern und ausmisten. Ist ja nicht normal, wenn die innerhalb von zwei Wochen ca. zweistellig GiB vollschreiben. Für die Bereinigung von Logdateien ist doch meistens logrotate zuständig, dessen Konfiguration man in /etc/logrotate.conf und /etc/logrotate.d/ findet.
Nach dem Säubern dann vielleicht doch nochmal die Retention-Zeit auf weniger Tage reduzieren.
Anschließend sollte ein sauberer Reboot alles wieder hochfahren, vorher natürlich mal checken, daß man die Hütte ordentlich gefegt hat. Wenn du Zweifel hast, was weg kann oder nicht, lieber nachfragen.
Backup wäre auch nicht verkehrt, je nachdem wieviel Kapital du in Lightning-Kanälen gebunden hast. Da muss man ggf. vorsichtig vorgehen.
Wieviele Lightning-Channel hast du offen?
Wie hast du LNDg konfiguriert?
Welche Services/Optionen sind auf deinem RaspiBlitz aktiviert?
Ich bin mit systemd und journalctl noch nicht per Du. Da müssten dir andere weiterhelfen.
Du musst erst einmal das übermäßige Protokollieren in den Griff bekommen, dass wird deine sd-Karte nicht lange mitmachen.
Wie gesagt, kenne mich mit dem Raspiblitz nicht aus. Was verbirgt sich den hinter diesen Einträgen https://github.com/rootzoll/raspiblitz/blob/v1.8/pictures/system.png , kann man damit das Protokollieren reduzieren oder abschalten?
Die laufenden Protokolleinträge kannst du mit
sudo journalctl -f
verfolgen, kannst du nicht mitlesen, wird definitiv zu viel protokolliert.
Hi Cricktor,
Danke für deine Hilfe. Zu deinen Fragen am Schluss:
Anzahl Channels: 24 und 1 ist pending zum öffnen
LNDg habe ich gem. Anleitung auf Github installiert und konfiguriert gem. Bild:
Services: LNDg, und folgende:
Logrotate.conf sieht so aus:
und das sind meine *.service:
avahi-daemon.service, background.scan.service, background.service, binfmt-support.service, bitcoind.service, blitzapi.service, bootstrap.service, console-setup.service, cron.service, dbus.service, dhcpcd.service, dphys-swapfile.service, electrs.service, fail2ban.service, fake-hwclock.service, getty@tty1.service, glamor-test.service, gldriver-test.service, session-2867.scope, session-4.scope, avahi-daemon.service, background.scan.service, background.service, background.service,
binfmt-support.service, bitcoind.service, blitzapi.service, bootstrap.service, console-setup.service cron.service dbus.service dhcpcd.service dphys-swapfile.service electrs.service fail2ban.service fake-hwclock.service getty@tty1.service glamor-test.service gldriver-test.service htlc-stream-lndg.service ifupdown-pre.service keyboard-setup.service kmod-static-nodes.service lightdm.service lnbits.service lnd.service mariadb.service mempool.service ModemManager.service networking.service nginx.service polkit.service postgresql.service postgresql@13-main.service raspi-config.service rc-local.service redis-server.service rng-tools-debian.service rpi-eeprom-update.service rsyslog.service
RTL.service ssh.service systemd-fsck-root.service systemd-fsck@dev-disk-by\x2dpartuuid-9230a3fe\x2d01.service systemd-fsck@dev-disk-by\x2duuid-53c072a6\x2dc349\x2d41d3\x2d9ca4\x2d581b2acafaa3.service systemd-journal-flush.service systemd-journald.service systemd-logind.service systemd-modules-load.service systemd-random-seed.service
welchen davon soll ich anhalten? den nginx.server ist ja für LNDg relevant. Kann es daran liegen?
OMG auf was habe ich mich da nur eingelassen.
Hey fedaykin,
Danke dir. Ja, das denke ich auch. Weiss einfach nicht wie.
Das debugging über das Raspiblitz Menü macht folgendes:
abschalten kann damit aus meiner Sicht nichts. Allerdings heisst das nichts (aus meiner Sicht :))
LG
F
Stopp mal den Electrum Rust Server und schaue anschließend mit
sudo journalctl -f
ob sich die Protokollierung beruhigt.
Du kannst auch nochmals in das aktuelle Log schauen, Dort wirst du Einträge mit
[nnnnn] DEBUG: ......
finden. Die Nummer in den eckigen Klammern ist die ProcessID, über diese ID kannst du mit
ps ProcessID
die Anwendung herausfinden, die den Log-Eintrag verursacht. Muss aber ein neuer Log-Eintrag sein, weil sich die ProcessID nach einem Neustart ändert.
Viel Glück
Okay, versuche ich direkt mal. Wie kann ich den dann wieder starten danach (gleicher befehl einfach mit start statt stop?)?
Genau
sudo systemclt stop/start electrs.service
Electrs gestoppt. Hat nichts an der DEBUG Log geändert. Kommen nach wie vor ständig rein.
Stoppe mal
mempool.service
1 „Gefällt mir“
Aber ja, Mempool.service lasse ich mal gestoppt, denn was da mit DEBUG logged ist ja der Wahnsinn. Aber warum? Keinen Plan!
Kenne mempool.service nicht, du musst es aber über die Einstellungen deaktivieren, da nach einem Neustart der mempool.serivce wieder gestartet wird.