Raspberry Pi crasht elke 10-20 dagen
Voor iemand die niet echt in de linux systeembeheer of -architectuur wereld zit is dit voor mij een redelijk complex probleem, ik kan simpelweg niet overzien wat er allemaal gebeurt. Ook wordt het analyseren van het daadwerkelijk probleem hierdoor bemoeilijkt. Wat ik wel kan doen is beschrijven wat er gebeurt.
Hardware
Raspberry Pi 3 Model B (revisie a02082)
Official Raspberry Pi 3 Power Supply
Randapparatuur (gekoppeld aan de RPi)
USB 3.0 - 22 pins SATA aansluiting voor 2.5" harde schijven
(met hieraan) Kingston SUV400S37 120G
USB toetsenbord
USB muis (wordt niet gebruikt, ik boot in shell, niet in de GUI)
monitor (staat meestal uit)
Software
Raspbian versie 9 (stretch), handmatige update van jessie (don't ask lol, ik had beter gewoon een nieuwe image kunnen installeren)
Symptomen
Na verloop van tijd loopt het systeem vast, deze is niet langer extern toegankelijk, de webserver reageert ook niet meer. Als ik achter de RPi zit dan worden vele varianten van de volgende melding uitgespuugd:
Code (php)
1
EXT4-fs error (device sda2): ext4_find_entry:1436: inode #131094: comm nmbd: reading directory lblock 0
Commando's worden ook niet meer herkend. Het enige wat ik op dat moment kan doen is de voeding eruit trekken en rebooten. De eerstvolgende reboot faalt ook altijd (een component tijdens het opstarten rapporteert [FAILURE]), ik heb getracht een manier te vinden om te achterhalen wat dit onderdeel is, maar de machine reboot meteen (misschien een boot_delay inbouwen?). Ook het raadplegen van boot- en systeemlogs na de tweede reboot bevat geen informatie (meer?) over de vorige niet-succesvolle boot.
Analyse
Ik heb echt veel gezocht op het internet, maar heb de oplossing nog niet gevonden. Er worden ook legio potentiële oorzaken aangedragen, met allerlei complexe linuxcommando's c.q. toverformules of configuratieregels die je ergens in de krochten van het systeem moet aanpassen... Een greep van oorzaken:
- voedingsprobleem (tijdens piekbelasting)
ik doe geen aannames over wat het is, want dat weet ik simpelweg niet, maar deze lijkt mij onwaarschijnlijk omdat er geen sprake is van piekbelasting, en hij knalt er altijd redelijk consequent uit na 10-20 dagen (tenzij er een loodzware cron is die tweewekelijks draait?)
- slijtage SSD
deze lijkt mij ook onwaarschijnlijk, de SSD is/was nieuw, en de rest van de tijd is er geen enkel probleem
- complexe technische oorzaak?
had ergens gelezen dat er iets was met niet om kunnen gaan met IPv6 adressen, of een of andere bug in de aansturing van IPv4, maar ik kan hier echt geen waardeoordeel over geven, ik heb geloof ik wel draadloos netwerk uitgeschakeld op mijn RPi omdat ik deze toch niet gebruik
Suggesties?
Misschien is de huidige opzet (SSD met SATA koppelstuk) niet echt ideaal en moet ik denken over een SSD met externe voeding? Of wellicht de "officiële" standaard adapter van de RPi vervangen, omdat daar ook nog wel wat berichtgeving over is dat deze redelijk bagger is? Wel zijn er een hoop webtutorials (waarvan de kwaliteit nogal eens verschilt ;)) die zo een SSD aan hun RPi fietsen ogenschijnlijk zonder enig probleem.
Ook kan ik niet goed controleren of er iets met de SSD mis is (ik kan fsck namelijk niet uitvoeren op een gemounte (systeem)schijf?).
Ik heb wel een beetje het idee dat ik bij alles wat ik probeer een beetje buitenspel wordt gezet :p. Als iemand enig idee heeft of iets soortgelijks heeft meegemaakt, I'm all ears :).
On a sidenote: als ik het apparaat reboot (sudo reboot), start deze nooit opnieuw op als ik dit commando remote aanroep (via SSH), en... soms (?!) als ik dat rechtstreeks vanaf de prompt doe. Dit kan ik ook niet helemaal plaatsen. Misschien heeft dit er iets mee te maken, misschien helemaal niets. Ik heb begrepen dat de RPi geen power saving heeft, deze is altijd op 100% vermogen actief maar wellicht is dat ondertussen veranderd?
Gewijzigd op 23/07/2018 13:52:15 door Thomas van den Heuvel
Mijn advies is om dit bericht/vraag bij Tweakers te plaatsen. Daar zitten echte DIE HARDS. Ik overweeg hetzelfde te gaan doen. En heb aldaar veel gelezen en gezien. Succes.
Gewijzigd op 23/07/2018 15:34:57 door Jan te Pas
Dus het zou best eens kunnen dat het apparaat gewoon te heet word tijdens piekbelasting?
Kijk eens hoe warm hij word:
Code (php)
1
cpu=$(</sys/class/thermal/thermal_zone0/temp)
Code (php)
1
echo "$((cpu/1000)) c"
Disclaimer, even google gedaan dus heb het niet getest. :)
Ik draai Debian linux op de Pi en ook de migratie van Jessie naar Stretch was simpel. Wat jij zegt: "Met veel kunst- en vliegwerk heb ik hier nu een (lokaal) webservertje...." is wel pech, het is namelijk heel simpel op Linux. Misschien met wat hulp kom je sneller tot een goed resultaat.
Ik heb ook een OrangePi van Ali en die presteert beter dan Raspberry en die draait wel probleemloos met een MicroSD. Op deze OrangePi draaien drie websites onder Apache en Domotics voor de Home Domotica. De Raspberry is mijn ontwikkel machientje en tevens toegang tot het netwerk van buiten, hier draai ik OpenVPN op met eigen certificaten.
Gewijzigd op 24/07/2018 12:30:11 door John D
Overclocking is niet van toepassing. Zoals eerder aangegeven heb ik mijn draadloze netwerk uitgeschakeld. Weet niet of ik dan in de problemen raak met power saving settings, maar lijkt mij onwaarschijnlijk. Verder is dat een topic uit 2012, dus dat doet mij ook afvragen of de informatie nog relevant is / van toepassing is op mijn situatie.
@Bart
55 c, dus toasty warm? Lijkt mij binnen de grenzen voor normale operatie.
@JohnD
Juist vanwege die stabiliteitsverhalen was ik overgestapt op een SSD :), ik gebruik dus in het geheel geen (micro)SD meer. Hiervoor moest je een of andere "one time programmable memory" bit omgooien zodat je van USB kan booten. Het is allemaal ook vrij simpel, maar ik weet graag van de hoed én de rand :).
Bedankt voor de reacties tot nu toe.
https://www.linux.com/learn/sysadmin/viewing-linux-logs-command-line
Code (php)
1
EXT4-fs error (device sda2): ext4_find_entry:1436: inode #131094: comm nmbd: reading directory lblock 0
Dit geeft toch aan dat je filesysteem vernaggeld is. Hebben de Sd's een eigen voeding (adapter) of voedt je ze uit de USB van de Raspberry? Als dit laatste het geval is dan is dat je probleem. De Pi is niet in staat om USB's hubs gevoed of niet lekker aan te sturen zo heb ik ervaren. Misschien de SSD's eruit en een USB stick van 64 of 128 Gb direct in de Raspberry zonder Hubje ofzo.
Gewijzigd op 24/07/2018 13:23:54 door John D
Je zult de schijf eerst moeten unmounten met een: umount /dev/sda2, hierna kun je de fsck commando reeks er op loslaten & daarna het schijf weer mounten met een mount /dev/sda2
Heb het idee dat het een kernel probleem betreft vanwege de wederkerende tijdsduur wegens de ssd/ext4 opzet.
Aangezien ik geen idee heb hoe groot of de ruimte op de ssd is kan het wel eens zijn dat de errorlogs volgelopen zijn onder; /var/log/hdd.log, /var/log/nginx/error.log of /var/log/nginx/access.log.
Het effect hier van uit zich in fouten die niet in de logs terug te vinden zijn wegens buffer vol.
P.s, een ssd is ook niet zaligmakend qua techniek, na een 1000x /r/w/x gaat de kwaliteit snel achteruit.
Gewijzigd op 29/07/2018 23:55:26 door Yoop Overmaat
Ik kwam er achter dat je ook een fsck kunt forceren tijdens boot door
Code (php)
1
fsck.mode=force
toe te voegen aan /boot/cmdline.txt en ervoor te zorgen dat deze elke boot (of liever gezegd, elke mount?) wordt uitgevoerd m.b.v. het commando:
Code (php)
1
# tune2fs -c 1 /dev/sda2
Vervolgens was het zoeken naar enige logging van fsck, die ik uiteindelijk vond onder /var/log/syslog. Hierin staat dat /dev/sda2 clean is...
Vooralsnog is het dus voor mij nog steeds een raadsel waarom de RPi er op een gegeven moment uitknalt.
Saillant detail: als ik wil rebooten (sudo reboot) dan reboot 'ie niet altijd, soms moet ik 'em dan hard resetten (voedingskabel ontkoppelen en opnieuw koppelen).
EDIT: het gebruik van:
Code (php)
1
sudo touch /forcefsck
wordt blijkbaar afgeraden, en lijkt ook maar één boot te werken (dit bestand wordt verwijderd?)
Gewijzigd op 30/07/2018 13:36:47 door Thomas van den Heuvel
Thomas van den Heuvel op 30/07/2018 13:16:04:
Omdat er een onbekend aantal onbekende processen actief zijn op die disk (target is busy) kan ik deze niet unmounten.
Omdat je van deze ssd je boot disk gemaakt hebt kan je sowieso niet unmounten tenzij je single user mode start op de console. Er worden dan geen andere processen gestart. Dan nog betwijfel ik of je fsck zinvol kan uitvoeren.
Toevoeging op 31/07/2018 20:58:03:
Yoop Overmaat op 29/07/2018 23:53:26:
Hetzelfde probleem heb ik ook ervaren met gewone sdhc cards, gewoon de kaart na 10-30 dagen vernaggeld. Rijp voor de vuilnisbak zelfs. Ik heb nu een iets andere configuratie dan Thomas. /boot staat nog op een shdc en de rest van het Linux systeem staat op een USB van 64Gb en sindsdien draait het probleemloos.Heb het idee dat het een kernel probleem betreft vanwege de wederkerende tijdsduur wegens de ssd/ext4 opzet.
Gewijzigd op 31/07/2018 20:59:58 door John D
Ondertussen heb ik mij ook redelijk suf gezocht naar mogelijke oorzaken, het meeste stond o.a. in deze thread:
- logs die vollopen met vervolgens gebrek aan diskruimte
- geheugen dat volloopt
- crontabs die te zwaar zouden zijn, blijkbaar is de crontab van PHP die sessies opschoont berucht
- brakke adapter
- brakke SSD kabel
- teveel apparaten die stroom trekken / voedingsprobleem
Dit alles bood echter geen soelaas.
Had de adapter vervangen (door precies dezelfde variant), geen verandering.
Had de SSD kabel vervangen (2x), geen verandering.
Had het toetsenbord en muis losgegooid (zodat er enkel een SSD aanhing), geen verandering.
Had de PHP sessie opschoon cron uitgeschakeld, geen verandering.
Heb het geheugengebruik gemonitord, deze liep weliswaar langzaam vol, maar dat schijnt normaal te zijn in UNIX/Linux omdat alles gecached wordt. Als je vervolgens dit geheugen niet vrij kunt geven dan is dit een indicatie dat er een geheugenlek is terwijl deze toch als theoretisch "vrij" wordt bestempeld terwijl deze toch "geclaimd" is, en dus ook niet bruikbaar is. Ook dit bleek niet het euvel te zijn (which reminds me, ik moet de cron voor het loggen van geheugengebruik nog even uitzetten haha).
De problemen hielden op toen ik een kortere netwerkkabel aan de RPi hing.
Voorheen hing er een UTP-kabel van een meter of 10 aan de RPi die rechtstreeks naar mijn modem ging. Bij wijze van laatste experiment had ik een kleine switch gekocht die ik tussen de modem en de RPi heb gezet, vanuit de switch loopt er een kabeltje van een meter naar de RPi. En sindsdien zijn alle problemen (vooralsnog, knock on wood :)) weg.
Dit zal dus wellicht toch in de voedingshoek liggen, en helemaal zeker ben ik nog steeds niet dat dit dan de oplossing is (en oorzaak was), maar voorlopig lijkt het er dus op dat dit op een of andere manier op den duur roet in het eten gooit.
In het begin heb ik dezelfde storing gehad, vele malen de SHDC opnieuw een image opgezet. Dagelijks Image backuppen. Veel Ellende. Conclusie hier en daar gevonden was: SHDC is niet geschikt voor de enorme hoeveelheid schrijfacties die Linux doet (w.o. de memory cache/swap, MySQL en apache). Na veel zoeken een leuke ombouwpagina gevonden: het hele OS naar een USB MiniStick 64Gb overgebracht en de SHDC wordt nu alleen nog maar gebruikt voor het booten (/boot). De Raspberry draait al een jaar of vier foutloos. Drie dev websites, Domotics, AIS server (niet meer actief) Python internet Radio voor in mijn hobbykamer, OpenVPN server voor mijn laptop onderweg, kortom alles probleemloos. Ondertussen ook nog even gemigreerd (upgrade) van Jessie naar Stretch.
Dat alles sinds de Raspberry de SHDC alleen nog maar gebruikt voor /boot
Het vollopen met en van logfiles kan je voorkomen met LogRotate. Dagelijks een nieuw logfile en de oude gezipped (GZ) bewaard met een nummer 1-5 of voor belangrijke 1-30 dagen. Instelbaar per log. Geen omkijken naar :)
Gewijzigd op 01/12/2018 16:25:12 door Aad B
- probeer het inderdaad met een USB-stick
- complete herinstallatie van OS (stretch) want op dit moment gebruik ik een upgrade van jesse, dus mogelijk ging daar nog wat mis
Maar nu werkt het dus zoals ik wil (met SSD). Mocht dit zootje weer op zijn bek gaan dan ga ik een van de twee bovenstaande oplossingen overwegen, want dan ben ik het ondertussen toch wel een beetje beu :).
Na de reboot wordt de klok ook altijd teruggezet, na de reboot die leidde tot de crash was dit 22 minuten. Kan dit nog dingen extra verstoren?
Gewijzigd op 13/12/2018 16:49:12 door Thomas van den Heuvel
Je kunt filesystem checks op een aantal manieren forceren:
1. In het tekstbestand waar de kernel commandline in staat (cmdline.txt) kun je "fsck.mode=force" opnemen
2. Via tune2fs kun je filesystem checks tijdens iedere mount forceren (tune2fs -c /dev/jerootpartitie). Dit werkt voor alle ext gebaseerde bestandssystemen.
Bij een kernel panic ga je zien dat je database zijn laatste transacties niet heeft. Ook zie je hier dat het journal niet als correct wordt beschouwd, waardoor deze hard onderuit gaat. Het is mogelijk dat dit wordt veroorzaakt door het tijdverschil. Je kunt hiervoor de ntp service installeren, zodat de tijd altijd wordt bijgewerkt vanaf een bekende bron. Eventueel zou je ook alleen ntpdate kunnen installeren en in /etc/rc.local iets kunnen opnemen als ntpdate nl.pool.ntp.org.
Mbt tot de crashes zelf: het kan zinvol zijn om naar de io scheduler te kijken. Standaard staat deze globaal op noop op raspberry pi (wederom via cmdline.txt), maar dit is toegespitst op het gebruik van SD kaarten.
Je kunt dit on boot veranderen door in /etc/rc.local iets op te nemen als "echo cfq > /sys/block/jeschijf/queue/scheduler". Let wel: het ligt er maar net aan wat voor kernel versie je hebt wat beschikbaar is. Je kan dit snel zien door cat /sys/block/jeschijf/queue/scheduler te doen. Vaak zul je iets zien als cfq [noop] deadline. In dat geval zijn je overige keuzes cfq en deadline, en is noop momenteel geselecteerd.
Ben van Velzen op 13/12/2018 22:52:46:
Je kunt filesystem checks op een aantal manieren forceren:
1. In het tekstbestand waar de kernel commandline in staat (cmdline.txt) kun je "fsck.mode=force" opnemen
2. Via tune2fs kun je filesystem checks tijdens iedere mount forceren (tune2fs -c /dev/jerootpartitie). Dit werkt voor alle ext gebaseerde bestandssystemen.
1. In het tekstbestand waar de kernel commandline in staat (cmdline.txt) kun je "fsck.mode=force" opnemen
2. Via tune2fs kun je filesystem checks tijdens iedere mount forceren (tune2fs -c /dev/jerootpartitie). Dit werkt voor alle ext gebaseerde bestandssystemen.
Dit doe ik volgens mij al, zie een aantal reacties van mij geleden. Na een crash (moet dan voeding eraf gooien en weer aansluiten) boot 'ie dan twee keer. De eerste keer constateert ie dan dat er iets mis was, maar wat precies gaat te snel en log wordt na 2e boot ook overschreven geloof ik. Na de tweede boot moet ik MariaDB nog handmatig herstarten in safe mode zodat dingen gerepareerd worden en daarna kan ik deze weer gewoon opstarten.
Ben van Velzen op 13/12/2018 22:52:46:
Bij een kernel panic ga je zien dat je database zijn laatste transacties niet heeft. Ook zie je hier dat het journal niet als correct wordt beschouwd, waardoor deze hard onderuit gaat. Het is mogelijk dat dit wordt veroorzaakt door het tijdverschil. Je kunt hiervoor de ntp service installeren, zodat de tijd altijd wordt bijgewerkt vanaf een bekende bron. Eventueel zou je ook alleen ntpdate kunnen installeren en in /etc/rc.local iets kunnen opnemen als ntpdate nl.pool.ntp.org.
Hier zal ik mij verder in moeten verdiepen want ik ben verder een complete linux/unix naab.
Ben van Velzen op 13/12/2018 22:52:46:
Mbt tot de crashes zelf: het kan zinvol zijn om naar de io scheduler te kijken. Standaard staat deze globaal op noop op raspberry pi (wederom via cmdline.txt), maar dit is toegespitst op het gebruik van SD kaarten.
Je kunt dit on boot veranderen door in /etc/rc.local iets op te nemen als "echo cfq > /sys/block/jeschijf/queue/scheduler". Let wel: het ligt er maar net aan wat voor kernel versie je hebt wat beschikbaar is. Je kan dit snel zien door cat /sys/block/jeschijf/queue/scheduler te doen. Vaak zul je iets zien als cfq [noop] deadline. In dat geval zijn je overige keuzes cfq en deadline, en is noop momenteel geselecteerd.
Je kunt dit on boot veranderen door in /etc/rc.local iets op te nemen als "echo cfq > /sys/block/jeschijf/queue/scheduler". Let wel: het ligt er maar net aan wat voor kernel versie je hebt wat beschikbaar is. Je kan dit snel zien door cat /sys/block/jeschijf/queue/scheduler te doen. Vaak zul je iets zien als cfq [noop] deadline. In dat geval zijn je overige keuzes cfq en deadline, en is noop momenteel geselecteerd.
Deze luidt momenteel noop [deadline] cfq.
Het betreft een SSD. Zou noop dan niet beter zijn?
Thx voor de suggesties :>.
EDIT: er begint mij iets te dagen. Wat als MySQL (na een boot) op komt voor/tijdens raadplegen van de tijdserver? Want ik heb wel wat ntp errors waarbij het binden aan een IPv6 adres niet lukt o.i.d..
Overigens is ntp geinstalleerd, maar ntpdate niet. Maar blijkbaar heeft het installeren van ntpdate geen zin als ntp al aanwezig is?
Gewijzigd op 14/12/2018 00:25:22 door Thomas van den Heuvel
noop werkt beter op een raspberry pi dan deadline, al was het alleen al omdat de snelheid van SD en USB niet optimaal zijn voor deadline. Deadline probeert namelijk zoveel mogelijk requests met zo hoog mogelijke snelheid te pushen. Dit kan instabiliteit tot gevolg hebben, zeker als je teveel vraagt van de io lijnen. Immers, de voeding kan maar zoveel leveren. Voor een HDD zou cfq mogelijk nog beter zijn, omdat deze wat meer gespreid werkt (maar wel wat meer dirty cache gebruikt). Dirty cache is echter geen probleem, bij een clean shutdown wordt dit toch wel geschreven, en een unclean shutdown draait gewoon de laatste wijzigingen terug. Wijzigingen zijn immers atomic.
Je zou voor het overige nog kunnen kijken naar ramdisks voor zaken die niet vereist zijn om te bewaren. Maar dat is een topic op zichzelf.
EDIT: boot logs zouden niet moeten overschrijven, standaard syslog uiteraard wel. Kijk ook even of je geen bestanden hebt als /var/log/syslog.1 etc.
EDIT 2: allow-hotplug mag sowieso wel weg, dit heeft alleen effect op USB kaarten die later geplaatst worden dan on boot. In het geval van een raspberry pi zou dit alleen tot gezeur leiden, omdat alle requests dan asynchroon lopen. Netwerk op een raspberry pi is wel USB, maar hoe dan ook ingeplugd on boot, zelfs al zou het een dongle zijn. Ik kan me in ieder geval niet voorstellen dat een eventuele dongle wordt verwijderd tijdens boot.
Allow-hotplug zorgt alleen dat alle kaarten asynchroon geinitialiseerd worden (inclusief DHCP). Op een server leidt dit tot gezeur als je afhankelijk bent van networking tijdens boot.
Gewijzigd op 14/12/2018 01:51:36 door Ben van Velzen