Raspberry Pi crasht elke 10-20 dagen

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Thomas van den Heuvel

Thomas van den Heuvel

23/07/2018 13:43:28
Quote Anchor link
Een hele tijd geleden had ik een Raspberry Pi gekocht. In eerste instantie met een (Micro)SD maar gebruik nu een SSD. Recent ben ik hier weer meer mee gaan doen. Met veel kunst- en vliegwerk heb ik hier nu een (lokaal) webservertje op draaien (nginx/PHP/MariaDB). Ik kan hier direct vanaf werken via Samba wat het ideaal maakt als ontwikkelmachine zonder dat ik daar een volledige PC/laptop voor nodig heb. Het enige probleem wat ik heb is dat deze af en toe crasht, echt zwaar crasht. Maar na twee reboots (en MariaDB een keer in recovery mode aanzwengel) is alles weer in de lucht.

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)
PHP script in nieuw venster Selecteer het PHP script
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
 
PHP hulp

PHP hulp

19/03/2024 12:57:26
 
Jan te Pas

Jan te Pas

23/07/2018 15:32:29
Quote Anchor link
Hoi Thomas,
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
 
Bart V B

Bart V B

23/07/2018 22:20:00
Quote Anchor link
Het is voor mij ook een wilde gok, maar een RPi heeft geen koeler standaard er op zitten.
Dus het zou best eens kunnen dat het apparaat gewoon te heet word tijdens piekbelasting?
 
Thomas van den Heuvel

Thomas van den Heuvel

23/07/2018 23:41:04
Quote Anchor link
Temperatuur. Hm, volgens mij loopt dat ding vast als ik er niets mee doe, er is niet (nooit) echt sprake van piekbelasting. Ik weet niet precies wanneer deze crasht (overdag, 's-nachts), maar als dit een temperatuur issue zou zijn dan zou ik verwachten dat 'ie er met dit weer een stuk vaker uitligt :p (wat ie vooralsnog niet lijkt te doen).
 
Jan te Pas

Jan te Pas

24/07/2018 08:33:39
Quote Anchor link
Ik heb even wat gezocht. Er zijn een paar redenen die genoemd worden, overclocking, dus wellicht temperatuur. Maar ook dat de WiFi dongle soms de fout in gaat. Dit zou een powermanagement probleem in de dongle zijn, https://www.raspberrypi.org/forums/viewtopic.php?t=51543&p=397663.
 
Bart V B

Bart V B

24/07/2018 09:18:41
Quote Anchor link
@Thomas, het hoeft natuurlijk niet zo te zijn dat het temperatuur is, maar omdat je ook een symptoom erbij zet "tijdens het booten" was dat een eerste ingeving. Zo'n koelertje is nu niet echt een mega investering dus zou dat een optie kunnen zijn om temperatuur uit te sluiten.
Kijk eens hoe warm hij word:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
cpu=$(</sys/class/thermal/thermal_zone0/temp)

Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
echo "$((cpu/1000)) c"

Disclaimer, even google gedaan dus heb het niet getest. :)
 
John D

John D

24/07/2018 12:23:00
Quote Anchor link
Het is vrijwel zeker het OS op de (micro)SD dat crashed. Ik heb hier ook een jaar of twee mee geworsteld en velen beweren dat hun (micro)SD het niet doet of beter is maar het gebeurt gewoon. Probeer maar eens, maak een image backup en zet die terug zodra de crash optreedt. Werkt meteen weer goed. Incidenteel is er wel eens een SD die het wel goed doet maar ik heb een tiental weggegooid. Die dingen zijn gewoon niet geschikt om een OS te servicen op Raspberry Pi. Een puntje van aandacht is ook wel de belasting van de USB poorten maar sinds ik het OS niet meer op de (micro)SD draai is het probleem totaal verdwenen. Ik start alleen nog maar op op de (micro)SD met de /boot partitie en de rest van het OS staat op een USB stick van 32Gb die nu al zeker drie jaar ononderbroken online is op de Raspberry die voorheen om de tien dagen crashte. Ik ben nu met vakantie dus een linkje om het grootste deel van OS naar USB stick te brengen heb ik even niet bij de hand.

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
 
Thomas van den Heuvel

Thomas van den Heuvel

24/07/2018 12:44:56
Quote Anchor link
@Jan
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.
 
John D

John D

24/07/2018 13:10:48
Quote Anchor link
Om te achterhalen wat er gebeurt kan je kijken in de logfiles op /var/log en dan de files messages, syslog en dergelijke. Fouten moet je daarin terug kunnen vinden, zie:

https://www.linux.com/learn/sysadmin/viewing-linux-logs-command-line

Code (php)
PHP script in nieuw venster Selecteer het PHP script
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
 
Thomas van den Heuvel

Thomas van den Heuvel

24/07/2018 14:31:01
Quote Anchor link
Ja had ook al naar voedingshulpstukken zitten kijken (de SSD ontvangt nu voeding via de RPi), maar blijft de vraag, waarom pas na 10-20 dagen? Dat systeem staat het grootste deel van zijn tijd gewoon uit zijn neus te eten. En als ik code zit te kloppen, (inefficiënte) scriptjes aan het uitvoeren ben en updates+upgrades aan het uitvoeren ben is het nog nooit fout gegaan en dat is eigenlijk de enige extra "activiteit" die dat systeem heeft, naast alles wat ie automatisch onderwater uitspookt. Het is waarschijnlijk een voedingsissue, maar wat zorgt ervoor dat ie er pas na een tijd uitknalt? Als het echt met de voeding te maken heeft, waarom heb ik daar dan niet continu last van?
 
Yoop Overmaat

Yoop Overmaat

29/07/2018 23:53:26
Quote Anchor link
Een fsck op een gemounte schijf werkt niet, in het ergste geval beschadig je het ding.
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
 
Thomas van den Heuvel

Thomas van den Heuvel

30/07/2018 13:16:04
Quote Anchor link
Omdat er een onbekend aantal onbekende processen actief zijn op die disk (target is busy) kan ik deze niet unmounten. Het lijkt mij niet verstandig om maar processen te killen (waarvan ik niet weet wat ze doen) totdat het werkt.

Ik kwam er achter dat je ook een fsck kunt forceren tijdens boot door
Code (php)
PHP script in nieuw venster Selecteer het PHP script
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)
PHP script in nieuw venster Selecteer het PHP script
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)
PHP script in nieuw venster Selecteer het PHP script
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
 
John D

John D

31/07/2018 20:51:59
Quote Anchor link
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:
Heb het idee dat het een kernel probleem betreft vanwege de wederkerende tijdsduur wegens de ssd/ext4 opzet.
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.
Gewijzigd op 31/07/2018 20:59:58 door John D
 
Michael -

Michael -

04/08/2018 20:10:44
Quote Anchor link
Ik heb niet alles gelezen, maar is de voeding van de rpi wel goed? Als je zo'n batterij met bliksemschicht krijgt te zien (wat je gewend bent van je mobiel/tablet) heeft je rpi te weinig voeding. Gebruik dan een andere adapter of de originele.
 
Thomas van den Heuvel

Thomas van den Heuvel

01/12/2018 13:31:19
Quote Anchor link
Met een uptime van ~33 dagen kan ik met enige zekerheid stellen dat de problemen voorbij lijken. Heb ondertussen 8 crashes gehad met tussenpozen varierend van 6-27 dagen (gemiddeld om de 13 dagen).

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.
 
Aad B

Aad B

01/12/2018 16:16:52
Quote Anchor link
Mijn Raspberry draait qua voeding al jaren op een oude Samsung GSM adapter met een UTP kabel van 1 meter naar de switch. Verder geen randapparauur op USB behalve het OS op een Sandisk mini USB stick. Wel een netwerk koppeling (webdav) naar mijn 1Tb TransIP
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
 
Thomas van den Heuvel

Thomas van den Heuvel

01/12/2018 16:24:53
Quote Anchor link
Dit werd volgens mij al eerder als mogelijke oplossing aangehaald: zet boot op een MicroSD en/of de rest/alles op een USB stick. Mocht dat switch verhaal niet werken dan had ik in principe nog twee opties:
- 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 :).
 
Thomas van den Heuvel

Thomas van den Heuvel

13/12/2018 16:48:50
Quote Anchor link
Te vroeg gejuicht. Het is weer zover. Dit keer na 45 dagen. Ben wel iets verder. Iets zorgt voor een reboot, maar die was niet clean, daardoor crasht MariaDB continu na de reboot, waarna het systeem waarschijnlijk op den duur onherstelbaar van streek raakt. Vraag is dus, waar komt deze reboot vandaan? Of hoe kan ik zorgen dat deze clean is en alles eerst netjes wordt afgesloten? Iemand ook een idee waar ik zou moeten kijken? /var/log/syslog en /var/log/daemon.log lijken slechts stille getuigen.

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
 
Ben van Velzen

Ben van Velzen

13/12/2018 22:52:46
Quote Anchor link
Klinkt als een double fault: een kernel panic die een kernel panic veroorzaakt. De enige resterende optie is dan een reboot.

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.
 
Thomas van den Heuvel

Thomas van den Heuvel

14/12/2018 00:07:30
Quote Anchor link
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.

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.

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
 
Ben van Velzen

Ben van Velzen

14/12/2018 01:39:39
Quote Anchor link
Een correcte configuratie zou networking als demand moeten hebben. Werkt deze via DHCP? In dat geval, kijk even in /etc/network/interfaces. Verwijder allow-hotplug regels, zodat gewacht wordt op resultaat.

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
 



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.