Fråga:
Hur man bestämmer varför Raspberry Pi 2 startade om
Derek Wildstar
2016-03-02 17:19:49 UTC
view on stackexchange narkive permalink

Jag har precis fått en Raspberry Pi och den fungerar mycket bra, men jag insåg att den någon gång startade om utan någon uppenbar orsak. Jag tänkte på en eventuell strömavbrott, men den är för närvarande ansluten till en UPS (som skulle ha börjat pipa vid strömavbrott).

Finns det något sätt att undersöka stockarna för att upptäcka vad som orsakade omstarten?

Uptime report`pi@raspberrypi: / var / log $ uptime -s2016-02-27 23: 23: 27`men tittar på gammal syslog ser jag inget konstigt bara mitt cronjobb och sedan omstart`Feb 27 23:17:01 raspberrypi CRON 23010]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)Feb 27 23:17:04 raspberrypi rsyslogd: [origin software = "rsyslogd" swVersion = "8.4.2" x- pid = "429" x-info = "http://www.rsyslog.com"] startFeb 27 23:17:04 raspberrypi systemd-modules-load [82]: Infogad modul 'fuse'Feb 27 23:17:04 raspberrypi systemd-modules-load [82]: Infogad modul 'i2c_dev' '
Ledsen igen Derek men jag har rullat tillbaka din redigering eftersom det som ursprungligen skrivits ger en bra generisk fråga som kan vara till nytta för andra människor, vilket är vad vi strävar efter här - se [turnén] (http: // raspberrypi .stackexchange.com / turné). Det verkar som om du har ett problem som är svårare att lösa än att bara titta på de sista loggmeddelandena och det kan faktiskt inte finnas någon ledtråd alls tillgänglig - dvs. om du inte kan komma med ett experiment för att reproducera problemet , Du är fast.
Förstod ... Jag trodde att det kunde finnas ett ytterligare steg att kontrollera att det kunde göras men tydligen har jag inte turen idag :( Kommer att acceptera ditt svar som, som du sa, är en mycket bra utgångspunkt för utredningen.
Två svar:
goldilocks
2016-03-02 17:32:14 UTC
view on stackexchange narkive permalink

Det finns något sätt att titta på några loggar för att upptäcka vad som orsakade omstarten?

För närvarande lägger Raspbian fortfarande en kopia av allt i / var / log / syslog . Du behöver behörigheter för att komma åt den här filen, dvs antingen su root eller använda sudo mindre .... eller sudokatt ... eller sudo grep .... .

Du letar efter meddelandena som indikerar början på den senaste start; dessa kommer att börja ungefär som: 

  6 feb 21:27:19 localhost rsyslogd: [origin software = "rsyslogd" swVersion = "8.10.0" x-pid = "7932" x-info = "http://www.rsyslog.com"] startFeb 6 21:27:19 localhost-kärna: [0.000000] Initiera cgroup subsys cpuset

Observera att ditt värdnamn inte nödvändigtvis är localhost .

Det kan finnas en viss skillnad i innehållet i det andra meddelandet, men detta är den punkt då systemloggaren ( rsyslog 1 ) kopierar i de saker du kan se med dmesg , som är kärnan som talar. Kärnans tidsstämplar (t.ex. [0.000000] ) är i sekunder (så har mikrosekundens granularitet); datum / klockans tidsstämpel läggs till av själva rsyslog så det kommer alltid att finnas medan kärnorna endast är för meddelanden från själva kärnan (därför har rsyslogs "start" -meddelande inte en).

Eftersom det indikerar den senaste start, letar du efter meddelandena omedelbart före dessa två rader. För en normal avstängning bör den sista vara ungefär som: 

  9 feb 22:32:32 localhost rsyslogd: [origin software = "rsyslogd" swVersion = "8.10.0" x-pid = "11188" x-info = "http://www.rsyslog.com"] avslutas vid signal 15.

Ett problem med fel är att om de är plötsliga eller involverar något slag av förlamning på grund av resursproblem (utan RAM, högprocessor) kanske systemet inte har synkroniserats till disk och felmeddelanden kommer inte att ha gjort det till filen.

1. Egentligen finns det en annan systemlogger integrerad i systemd, init-systemet, kallat journald . Eftersom dess filer inte är läsbara för människor är det inte till stor nytta, särskilt om du t.ex. undersöker ett kort från ett misslyckat system i en annan dator.

Jag har lagt till lite mer information om syslog ... det stängde säkert inte ordentligt. Om resursfråga ... Jag tror inte är fallet eftersom jag hittills bara kör ett cron-skript för att inte kontrollera internetanslutningen mer.
Det vill säga du har svar på din fråga och har nu en aning om vad du ska undersöka vad * kan * ha med problemet att göra (något som går från 'cron.hourly'). Kan vara en återvändsgränd. Observera att detta inte är ** ett diskussionsforum, så vi gör inte oändliga / obestämda sekvenser av "Okej, så då ..." - du måste dela upp saker i separata frågor. Anledningen till detta är annars många människor som annars kan vara till hjälp helt enkelt inte kommer att delta eftersom de inte har tid att dras in i obestämda problemlösningsdiskussioner. Det inkluderar mig - ledsen, men lycka till.
Utan tvekan rapporteras inte denna typ av problem i en logg. För det mesta efter ett allvarligt fel går kärnan i omstartläge utan att skriva något tillbaka till disken: tabeller kan vara skadade och kan skapa mer skada. Börja stoppa tjänster och applikationer och fortsätt försöka ... På en annan anmärkning är RPi ganska känslig för ström, även med UPS, om du inte har en konstant strömförsörjningsspänning kommer du att stöta på problem.
* "Utan tvekan är den här typen av frågor ..." * -> Är, uppriktigt sagt, den förvirrade produkten av anekdotiska reflektioner av en förvirrad individ som backas upp av hög falutin-klingande ** mumbo-jumbo. ** Eg , det finns inget sådant som "kernel restart mode" (och om du tvivlar på detta, sök online "linux" kernel restart mode ""). Start och stopp av init-tjänster loggas vanligtvis. Strömavbrott händelser lämnar dock ganska mycket inga tecken. Andra problem, såsom OOM-händelser och (andra) felaktiga processer (som förmodligen är de vanligaste mördarna) kommer att lämna ett stort spår. @Fcm
OK @goldilocks är "panik" -läge eller andra tillstånd (självförsvar) där det inte finns något annat alternativ än omstart eller, om du föredrar, starta om. En process på användarnivå som upptäcker avvikelser kommer troligen att logga något och mycket osannolikt, tvinga en omstart, dock kommer kärnnivå ogiltiga instruktioner på en enhetsdrivrutin.
Kärnpanik * loggas * vanligtvis, såvida det inte är maskinvaruproblem som involverar rotfilsystemet. Observera att denna typ av diskussion INTE kommer att hjälpa OP förutom att skapa förvirring, och är ett perfekt exempel på varför SE INTE är ett diskussionsforum. Om du har ett svar, spendera tid på att komponera det, säkerhetskopiera det med referenser, kvalificera det som WRT-omständigheter etc.
mike glenndale
2016-03-03 06:51:04 UTC
view on stackexchange narkive permalink

Det uppstod ett problem där Raspberry Pi 2 skulle återställa sig själv när en viss del exponerades för en Xenon-blixt:

http://www.ibtimes.co.uk/camera-shy -raspberry-pi-2-återställs-när-exponeras-xenon-blixt-1487238

Högintensiva lampor som blinkningar eller laserpekare kan orsaka spänningsfall och återställa enheten.



ⓘ
Denna fråga och svar översattes automatiskt från det engelska språket.Det ursprungliga innehållet finns tillgängligt på stackexchange, vilket vi tackar för cc by-sa 3.0-licensen som det distribueras under.
Loading...