Raspbian 11 freezed, hoe debuggen?

[smeerbartje]

Ik heb hier een rpi zero2 waarop ik Raspbian GNU/Linux 11 (bullseye) heb draaien. Vrij vanilla; het enige dat erop draait is motioneye. Nu werkt het allemaal goed, alleen na verloop van tijd freezed de pi.

• pingen --> geen response
• ssh toegang --> niks nakkes

Hoe kan ik dit nu debuggen? Welke file moet ik hebben uit /var/log en waarop moet ik letten? Ik heb inmiddels via healthchecks.io een check opgezet. De pi doet elke minuut via crontab een cURL naar healthchecks waarin hij zich dus "meldt". Ook dit proces stopt op het moment dat het misgaat.

Dit geeft me een goede indicatie van het timewindow waarop ik moet checken. Alleen... wat dan?

[Juup]

Lastig. Begin met de meest voordehand liggende problemen:
- Temperatuur te hoog
- SD kaart vol of corrupt
- Instabiele voedingsspanning

[Hero of Time]

En het meest voor de hand liggende stap voor oplossen: Hang er een scherm aan! Leuk en al dat je van afstand er niet bij kan en na een reboot probeert te achterhalen wat er mis is, maar als het zo ernstig op z'n bek gaat dat er geen logs worden weggeschreven, ga je nooit vinden wat de oorzaak is, als je er niet direct naar kijkt.

[smeerbartje]

Thanks beide; ik heb er een scherm aan gehangen. Hierop tail ik alle logs. Kijken wat er gebeurt!

[SVMartin]

Is idd de makkelijkste oplossing. Je kunt ook na een vraag de sd kaart in een laptop stoppen en de logs bekijken. Of een syslog server opzetten en de logs daar naar laten wegschrijven.

[smeerbartje]

Nou, daar ben ik weer. Zie screenshot hieronder. Vannacht was het weer zover; m'n pihole (Raspbian GNU/Linux 11 (bullseye)) liep weer eens vast. Dit was om 02.59 uur. Enkel een reboot is dan een optie om er iets van beweging in te krijgen. Echter in de logs zie ik niets vreemds. Jullie wel?

Hoe zou ik dit kunnen debuggen? Kan ik het OS op een soort van speciale debug mode zetten? Zodat er nóg meer logging uit komt?

EDIT

Na wat onderzoek blijkt dat rond exact hetzelfde moment mijn unifi netwerk van channel is gewijzigd. Zie screenshot hieronder. Dit kan bijna geen toeval zijn lijkt me. Alleen op de één of andere manier kan dus de raspberry Pi zero 2W hier nog goed tegen.

[ Voor 29% gewijzigd door smeerbartje op 20-12-2022 07:36 ]

[Tux3.14]

Grote kans dat je SD kaart defect is. Probeer is een andere.
Door de vele writes gaan SD kaartjes vrij snel defect. Eigenlijk zijn ze daar niet voor gemaakt. Hopelijk komt de volgende RPi daarom ook met een MMC/sata/nvme-slot oid.

[smeerbartje]

Tux3.14 schreef op dinsdag 20 december 2022 @ 07:35:
Grote kans dat je SD kaart defect is. Probeer is een andere.
Door de vele writes gaan SD kaartjes vrij snel defect. Eigenlijk zijn ze daar niet voor gemaakt. Hopelijk komt de volgende RPi daarom ook met een MMC/sata/nvme-slot oid.

Ja denk je dat?
Had je mijn aanvulling (edit) ook gelezen?
het lijkt mij namelijk verband te houden met het wijziging van het wifi channel.

Ik stuitte net ook hierop: https://raspberrypi.stack...changed-channel-frequency

[Ultraman]

Zit de Pi dan wel vast? Ik heb de indruk dat de Pi puur de WiFi verbinding verliest waardoor ze onbereikbaar wordt.
Als je ook een toetsenbord aan de Pi hangt kun je ontdekken of je op de Pi zelf nog kunt inloggen.

Ik heb een paar ideëen. Van het proberen van een configuratieoptie tot het gebruiken van watchdog (die je Pi ook kan rebooten bij een crash, handig bij headless gebruik).

Zou je je netwerkconfiguratiefile eens willen posten? Ontdaan van het wachtwoord

[ Voor 7% gewijzigd door Ultraman op 20-12-2022 08:02 ]

[SVMartin]

Kun je dit niet testen door handmatig de wifi naar een ander kanaal over te zetten? Zou mooi zijn met de pi verbonden aan een scherm en toetsenbord zodat je gelijk kunt kijken of hij vast loopt of de wifi verliest

[aawe mwan]

Je kan proberen of het probleem weg is als je WiFi op de Pi disablet en hem met een kabeltje aansluit.
Belangrijk: de WiFi op de Raspberry Pi niet disablen met rfkill, maar met de setting in het opstartbestand.

[smeerbartje]

[smeerbartje]

Kan iemand mij vertellen waarom een "from scratch" raspberry Pi 2 zero (met raspberry os) zoweel swap gebruikt? Mijn andere Pi doet dit namelijk niet,.

[pennywiser]

Probeer nieuwe installatie op andere SD kaart. Liefst een "Endurance" SD kaartje van Samsung of Sandisk.

[pennywiser]

smeerbartje schreef op woensdag 28 december 2022 @ 10:45:
[Afbeelding]

Hoe kan iemand swap gebruik debuggen zonder logs en kennis van welke processen er draaien?

[Ultraman]

smeerbartje schreef op woensdag 28 december 2022 @ 10:45:
[Afbeelding]

Omdat hij waarschijnlijk inactieve stukken geheugen naar het swap wegdrukt om meer RAM vrij te spelen voor nuttige zaken.
Misschien heeft hij wel iets ondernomen waarvoor even veel geheugen nodig was? Check voor updates wellicht of een indexering van de files op het filesysteem (mlocate?), of wat anders natuurlijk. En zodra dat proces klaar was is het geheugen weer vrij gegeven. Wat naar swap is gedrukt blijft daar lekker zitten tot het weer een keer opgevraagd wordt. Totdan lekker laten zitten in swap want dat geeft vrij RAM.

Waarom de een het wel doet en de ander niet kan liggen aan een aantal instellingen rondom geheugenbeheer, achtergrondprocessen, softwareversies. In hoeverre zijn ze gelijk aan elkaar is de hamvraag.

Swapgebruik an sich is niet erg, het kan zelfs een goed iets zijn want je speelt er RAM mee vrij. Waar je op wilt letten met swapgebruik is hoe frequent de swap wordt aangesproken. Als er wat inactieve pages naar swap verplaatst worden en daar vervolgens lekker blijven kamperen: prima. Wat je niet wilt zien is regelmatige heen-en-weer beweging tussen RAM en swap. Dat is thrashing en dat merk je keihard aan je performance; dan is het bakkie niet vooruit te fikken. Dan is meer RAM nodig, of je moet de belasting van het bakkie verminderen. Meestal zie je dan ook het swapgebruik flink de hoogte in gaan.
En een volle swap is natuurlijk ook problematisch, want dan is de koek op en gaan er dingen afgeschoten worden.

pennywiser schreef op woensdag 28 december 2022 @ 10:56:
[...]

Hoe kan iemand swap gebruik debuggen zonder logs en kennis van welke processen er draaien?

Precies. Is zonder functionerende kristallen bol niet te doen.

---

Dit is weliswaar een heel ander onderwerp dan waarmee je de draad begon. Misschien moeten we niet gaan uitwijden over swap en geheugengebruik? Hoe is het met je oorspronkelijke probleem?

[ Voor 24% gewijzigd door Ultraman op 28-12-2022 11:01 ]

[pennywiser]

Dat wifi probleem zou dag in dag uit achter elkaar reproduceerbaar moeten zijn na elke dhcp lease of kanaal wissel, dat resultaat zie ik hier niet terug. Na 1 zo'n voorval ben ik niet overtuigd dat dat het probleem is. Ik heb ook niet gezien welk merk SD je nu gebruikt. Ik hou het daarom op slechte SD, met bovenstaande problemen als gevolg. Ik gebruik hier al jaren Samsung Endurance en heb nooit meer gedoe met SD kaarten gehad sindsdien. Samsung heeft nu net weer een nieuwe lijn daarvan en voor de kosten hoef je het niet te laten.

[Ultraman]

Zou ook nog kunnen. Er is al een hoop geopperd.
Ik denk dat de TS eerst beter kan reageren op alle suggesties en vragen voordat we er nog meer theorieën op los laten.

[smeerbartje]

SVMartin schreef op vrijdag 11 november 2022 @ 23:17:
Is idd de makkelijkste oplossing. Je kunt ook na een vraag de sd kaart in een laptop stoppen en de logs bekijken. Of een syslog server opzetten en de logs daar naar laten wegschrijven.

Ik heb een remote syslog server ingesteld; tot op heden is de pi niet meer vastgelopen. Zodra dit gebeurt ga ik hier uiteraard als eerste naar kijken.

Ultraman schreef op dinsdag 20 december 2022 @ 08:01:
Zit de Pi dan wel vast? Ik heb de indruk dat de Pi puur de WiFi verbinding verliest waardoor ze onbereikbaar wordt.
Als je ook een toetsenbord aan de Pi hangt kun je ontdekken of je op de Pi zelf nog kunt inloggen.

Ik heb een paar ideëen. Van het proberen van een configuratieoptie tot het gebruiken van watchdog (die je Pi ook kan rebooten bij een crash, handig bij headless gebruik).

Nice! Ik kende watchdog nog niet; is nu geinstalleerd. Benieuwd naar het resultaat.

SVMartin schreef op dinsdag 20 december 2022 @ 08:33:
Kun je dit niet testen door handmatig de wifi naar een ander kanaal over te zetten? Zou mooi zijn met de pi verbonden aan een scherm en toetsenbord zodat je gelijk kunt kijken of hij vast loopt of de wifi verliest

Heb ik inderdaad geprobeerd; alleen daar ging de pi gewoon "normaal" mee overweg. M.a.w. de channel-change werd netjes gerespecteerd door de pi.

pennywiser schreef op woensdag 28 december 2022 @ 10:56:
[...]

Hoe kan iemand swap gebruik debuggen zonder logs en kennis van welke processen er draaien?

Ik snap dat dat moeilijk is; sorry . Hoe kan ik eigenlijk inzien welk proces verantwoordelijk is voor het swap gebruik?

Ultraman schreef op woensdag 28 december 2022 @ 10:57:
[...]

Waarom de een het wel doet en de ander niet kan liggen aan een aantal instellingen rondom geheugenbeheer, achtergrondprocessen, softwareversies. In hoeverre zijn ze gelijk aan elkaar is de hamvraag.

Beide pi's zijn 100% identiek. Zelfde os versie, zelfde packages, beide geprovisionned met dezelfde ansible playbook .

pennywiser schreef op woensdag 28 december 2022 @ 11:10:
Dat wifi probleem zou dag in dag uit achter elkaar reproduceerbaar moeten zijn na elke dhcp lease of kanaal wissel, dat resultaat zie ik hier niet terug. Na 1 zo'n voorval ben ik niet overtuigd dat dat het probleem is. Ik heb ook niet gezien welk merk SD je nu gebruikt. Ik hou het daarom op slechte SD, met bovenstaande problemen als gevolg. Ik gebruik hier al jaren Samsung Endurance en heb nooit meer gedoe met SD kaarten gehad sindsdien. Samsung heeft nu net weer een nieuwe lijn daarvan en voor de kosten hoef je het niet te laten.

De SD kaart is echt net nieuw. Kan me niet voorstellen dat dit de boosdoener is. Ik gebruik overigens deze SD kaartjes.