Ich bräuchte dann auch mal Hilfe: Heute Morgen konnte ich kaum noch auf fhem bzw. den Rpi zugreifen. Was heißt kaum ? Putty und WinSCP nicht möglich. fhem im Browser ansprechbar, aber keine Bilder, sondern nur Textzeilen werden angezeigt, so wie man das schon mal bei schlechten Serververbindungen gesehen hat. Mein fhem-Infodisplay lief noch perfekt, weil es ja seine Seite auf dem Client aufbaut. Ins Auge fiel mir eine Statuszeit von 2:22 eines devices. Soweit die Symptome und meine Einschätzung: System zu 99,9% ausgelastet.
Was tun ? Restart. Also ein shutdown fhem und dann Stecker ziehen. Es passiert......nichts. Dieses 2. Problem hatte ich nun auch schon öfter. Deshalb bin ich auch vor ein paar Monaten von SD auf USB-Stick umgestiegen. Zig mal in den verschiedensten Konstellationen ohne Peripherie rebootet......nix. Die grüne LED zeigt nicht ein einziges mal Ihr Licht :( SD-Karte rein und plötzlich, oh Wunder, er bootet und blinkt mich freundlich an. Wieder runter gefahren USB-Stick dran und siehe da, bootet auch wieder ?!?!? Da bin ich mit meinem Latein am Ende. Was verhindert denn bei den anderen Versuchen den reboot meines RPi3 mit aktuellem Jessie ?
Zurück zum 1. Problem. In fhem erkenne ich nach dem reboot, dass die letzten Datenlogs um 2:22 erstellt wurden. Ahh deckt sich mit dem timestamp, den ich im Infodisplay sah. Stromausfall ? No, die Fritte ist heute Nacht nicht neu gestartet. Also mal ein Blick ins Systemlog. Hier nur ein kurzer Auszug:
Nov 21 20:17:01 raspberrypi CRON[25644]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Nov 21 21:17:01 raspberrypi CRON[25771]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Nov 21 22:17:01 raspberrypi CRON[25904]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Nov 21 23:17:01 raspberrypi CRON[26035]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Nov 22 00:17:01 raspberrypi CRON[26163]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Nov 22 01:17:01 raspberrypi CRON[26291]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Nov 22 02:17:01 raspberrypi CRON[26418]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Nov 22 02:17:05 raspberrypi rsyslogd: [origin software="rsyslogd" swVersion="8.4.2" x-pid="469" x-info="http://www.rsyslog.com"] start
Nov 22 02:17:05 raspberrypi kernel: [ 0.000000] Booting Linux on physical CPU 0x0
Nov 22 02:17:05 raspberrypi kernel: [ 0.000000] Initializing cgroup subsys cpuset
Nov 22 02:17:05 raspberrypi kernel: [ 0.000000] Initializing cgroup subsys cpu
Nov 22 02:17:05 raspberrypi kernel: [ 0.000000] Initializing cgroup subsys cpuacct
Nov 22 02:17:05 raspberrypi kernel: [ 0.000000] Linux version 4.4.17-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #902 SMP Mon Aug 15 12:21:29 BST 2016
Nov 22 02:17:05 raspberrypi kernel: [ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
Nov 22 02:17:14 raspberrypi systemd[1]: Starting Update UTMP about System Runlevel Changes...
Nov 22 02:17:14 raspberrypi systemd[1]: Started Update UTMP about System Runlevel Changes.
Nov 22 02:17:14 raspberrypi systemd[1]: Startup finished in 9.986s (kernel) + 14.606s (userspace) = 24.592s.
Nov 22 02:17:19 raspberrypi dhcpcd[707]: eth0: no IPv6 Routers available
Nov 22 07:09:59 raspberrypi systemd[1]: Time has been changed
2:17 letztmalig den cron-job ausgeführt. Danach kommt als erster Eintrag, etwas verwirrend, mit 2:17 die Meldungen über "einen" Reboot. Tatsächlich ist das aber der reboot von heute Morgen, aber erst später wird die Systemzeit auf aktuellen Stand gebracht.
Da sich also keinerlei Informationen über den Grund der Überlastung des Rpi und damit (Teil-)Ausfall von fhem finden lassen, was könnte man ins systemlog oder sonst wohin schreiben lassen, um der Ursache näher zu kommen ? Ich dachte an sowas wie die ersten 2 Zeilen von top in ein log zu schreiben.
Als letzte Info noch zu meinem System: War tagelang gelaufen. Außer fhem läuft nichts an Anwendung auf der Kiste. Lt. top in der Regel deutlich unter 10% CPU. Lediglich ein paar kworker/u8:2, kworker/u8:3 kworker/u8:0 treiben Ihr "Unwesen" mit um die 10% Last. Im Inet hab ich nix gefunden, um rauszufinden, was da den Kernel zu den Prozessen veranlasst. Komischerweise wechselt die PID auch noch ?! Wären wir also bei Problemchen Nr. 3. Ich würd ja mal ohne fhem-start booten und gucken wollen, ob die kworker mit fhem im Zusammenhang stehen, aber dann hab ich ja wieder Problem Nr. 2 :'(
Jemand Ideen zu meinen 3 Problemen ?
Grüße Markus
Zitatfhem im Browser ansprechbar, aber keine Bilder, sondern nur Textzeilen werden angezeigt, so wie man das schon mal bei schlechten Serververbindungen gesehen hat.
das hatte ich neulich auch, als ich nach ein paar tagen wieder nach hause kam. logs endeten alle während meiner abwesenheit.
fhem shutdown (restart automatisch über systemd) über eingabezeile hat keine besserung gebracht. im gegenteil, nun war fhem gar nicht mehr erreichbar, als hätte nur shutdown funktioniert. nach einem reboot des pi (stecker ziehen) war wieder alles ok.
ich vermute bei mir ein problem mit der wlan verbindung, eventuell im zusammenspiel mit der fritzbox als wlan router. habe ich aber nicht näher untersucht. allerdings frage ich mich gerade nach dem zusammenhang von wlan mit den logs, die auf dem pi angelegt werden.
Zitatbei mir ein problem mit der wlan verbindung
Könnte eine Möglichkeit sein. Ich hab zwar eine LAN-Verbindung, aber das WLAN ist aktiv und in der Fritte angemeldet. Wer weiß, ich schalte einfach mal explizit das WLAN ab und beobachte weiter.
Danke für die Hilfe. Zu den beiden anderen Problemen jemand noch ne Idee ?
Grüße Markus
Hi,
meine RasPi3-Experimente haben zwei Probleme/Schwachstellen hervorgebracht:
1. Das WLan ist nicht wirklich sehr stabil. Man scheint das Ding dann und wann mal durchstarten zu müssen.
2. Das Teil entwickelt mehr Hitze als bisherige RasPis.
Der zweite Punkt könnte diverse Folgeprobleme hervorrufen, daher poste ich das hier. Hast Du mal nachgeschaut bzw. aufgezeichnet, wie warm das Teil wird?
Gruß,
Thorsten
Danke für die Rückmeldung.
ZitatDer zweite Punkt könnte diverse Folgeprobleme hervorrufen, daher poste ich das hier. Hast Du mal nachgeschaut bzw. aufgezeichnet, wie warm das Teil wird?
leider nicht. Steht aber im Keller bei derzeit um die 16° und nicht in ein Gehäuse "gezwängt". Sollte doch hoffentlich keine Probleme verursachen.
Bin aber schon Schritte weiter.
Der reboot-Verhinderer(Problem 2) ist identifiziert. Es liegt irgendwie an den angeschlossenen USBs. Entweder macht ein passiver Hub Probleme oder eine Kabelverbindung ist irgendwie nicht in Ordnung.
Problem 1 ist erneut aufgetaucht, nachdem ich versuchte den WLAN-Adapter zu deaktivieren über "sudo ifwlan0 down", mit iwconfig zum überprüfen und dann dachte ich, stell ich es über raspi-config zur Bootzeit ab. Aber da gibt es gar keine Möglichkeit. Und dann war das Problem plötzlich wieder da. Leider kriege ich es aber nicht nachgestellt >:( Möglicherweise ist aber auch ein Zusammenhang mit dem USB(Problem 2) ?
Nachdem ich jetzt so langsam wieder aufatme: Habt Ihr auch diese kworker-Prozesse(Problemchen 3) und wisst vielleicht, was die treiben ?
Bis zu euren Antworten kümmere ich mich um den WLAN-Adapter....
Markus
ich kenne die Probleme auch.
Bei mir war der Raspi3 dann aber auch nicht mehr über SSH ansprechbar. Am Anfang trat es oft auf, wenn ich große Logfiles über den Browser geöffnet oder schnell die Seiten gewechselt habe.
Da half nur Stecker ziehen. Der Pi ist in einem Gehäuse und um die 50°C warm. Versuchsweise habe ich es offen gelassen (40°C), aber es hat keinen Unterschied gemacht.
Ich habe dann ein apt-get update gemacht + fhem update und jetzt auch mal alte Logfiles in den Ordnern gelöscht. Seitdem scheint es zu gehen. Es gibt wohl auch einen Powersave Modus beim WLAN des RPi3, den man deaktivieren sollte.
Gruß, Florian
gerade ist es mal wieder passiert. Diesmal aber etwas andere Symptome: 74h uptime, ssh u. sftp problemlos. fhem: nicht mehr erreichbar. fhem stop funktioniert nicht. Erst mit kill -9 und nachfolgendem fhem start ist wieder alles ok. Logs wurden nicht mehr fortgeschrieben, auch nicht fhem.log >:( vorgenommene Änderungen: neues device für SYSMON, Modulupdates.
Jemand ne Idee, warum fhem den Zugriff verweigern könnte bzw. was ich machen kann, um der Ursache auf die Schliche zu kommen ?
Grüße Markus
bei mir ist es gerade erstmalig passiert, während ich auf den pi über putty/ssh zugegriff hatte und ein perl modul installieren wollte. die putty ausgabe hängt, es geht nicht weiter:
root@raspberrypi:/home/pi# apt-get install libcrypt-rijndael-perl
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
libcrypt-rijndael-perl
0 upgraded, 1 newly installed, 0 to remove and 45 not upgraded.
Need to get 21.1 kB of archives.
After this operation, 34.8 kB of additional disk space will be used.
Get:1 http://mirrordirector.raspbian.org/raspbian/ jessie/main libcrypt-rijndael -perl armhf 1.12-1+b1 [21.1 kB]
Fetched 21.1 kB in 0s (41.4 kB/s)
Selecting previously unselected package libcrypt-rijndael-perl.
(Reading database ... 34729 files and directories currently installed.)
Preparing to unpack .../libcrypt-rijndael-perl_1.12-1+b1_armhf.deb ...
Unpacking libcrypt-rijndael-perl (1.12-1+b1) ...
Processing triggers for man-db (2.7.0.2-5) ...
um zu sehen, ob der pi noch läuft, habe ich im browser nach fhem geschaut. 2 bereits geöffnete tabs zeigen keinen verbindungsabbruch und longpoll funktioniert weiterhin. ein weiterer neuer fhem tab wird dann aber nur im "text-design" dargestellt. dort, wo plots sein sollten, wird eine fehlermeldung gezeigt:
Cannot read ./www/gplot/SVG_FileLog_sysmon_1.gplot
edit:
irgendwie scheint zumindestens fhem keinen zugriff mehr auf das dateisystem zu haben. die fhem eingabezeile im "text-design" funktioniert jedenfalls, sodass ich befehle ausführen kann. firebug zeigt probleme mit sämtlichen dateien (screenshot), wie png, js, css, ... dazu passt ja auch, dass die log-files nicht geschrieben werden.
interessant ist vielleicht auch, dass die fhem zeit jetzt exakt 1 stunde zurück ist. auch localtime über fhem zeigt es.
über putty/ssh komme ich weiterhin nicht auf den pi, aber ich komme über putty/telnet auf den fhem-telnet zugang über port 7072.
fhem funktioniert bei mir weiterhin extrem gut, dass heisst, es können keine freezes etc auftauchen, denn meine heizungsventile werden von fhem bedient und die benötigen ein äusserst exaktes timing. auch empfängt ein usb-cul433 am pi eine intertechno fernbedienung, womit dann in fhem ein homematic aktor geschaltet wird. völlig problemlos und verzögerungsfrei.
hat vielleicht jemand eine idee, was ich jetzt gerade versuchen könnte, um weitere hinweise zu bekommen?
gruss frank
mein pi3 ist nun schon ein paar stunden im jetzt-bin-ich-mal-weg-modus. fhem läuft immer noch bestens, bis auf die nicht funktionierenden datei zugriffe.
sysmon zeigt ein paar besonderheiten, gegenüber sonst:
- es gibt jede menge timestamps von heute 10:49, wahrscheinlich der crashzeitpunkt. eventuell wird hier auch auf dateien zugegriffen, was nun nicht mehr möglich ist.
- die temperaturen liegen jetzt bei ca null grad, sonst um 44 mit ein paar spitzen von max 48 und die zeiten sind aktuell. kann dies das problem sein? gibt es eventuell mechanismen, die durch fehlerhafte temperaturwerte bestimmte teile des pi fälschlicherweise lahmlegen?
- die ersten beiden wlan readings haben sonst etwas angezeigt. jetzt sind sie nicht möglich, aber die timestamps sind aktuell.
vielleicht fällt jemandem noch etwas entscheidendes auf, daher anbei die screenshots.
seeeehr ähnlich.
Zitateventuell wird hier auch auf dateien zugegriffen, was nun nicht mehr möglich ist.
das ist auch meine Ansicht. Alles läuft gemütlich vor sich hin und bekommt gar nicht mit, dass es ein Problem gibt. Nur auf allertiefster Systemebene klemmt was. Nur was und wo, dass fhem scheinbar glaubt das Logging liefe 1a ?
Mir kommt immer mal wieder der Gedanke, es könne mit der nicht vorhandenen rtc zusammenhängen. Kannst Du externe Server, insbesondere die ntp-server anpingen ?
jetzt habe ich schon den stecker vom pi gezogen und alles ist wieder normal.
ich hatte irgendwie keine möglichkeit über fhem auf systemebene zuzugreifen. alle mir bekannten möglichkeiten verliefen im sande. nächstes mal vielleicht. :)
verstehe ich. ;D kein Logging ist Käse. Ich fand Dich schon extrem geduldig. Wenn ich es wieder hab, probier ich es auch mal mit telnet bevor ich ungeduldig reboote ;D
Das hört sich danach an, das der Pi nicht mehr auf seine "speichermöglichkeiten" zugreifen konnte. Alle bis dahin laufenden prozesse laufen noch. Logging ist natürlich nicht möglich.
Wenn ich recht habe, ist aber auch ein login nicht möglich, da meistens nicht im Speicher vorhandene Daten auf dem externen Medium (z.B: SDCarte) zugegriffen werden muss, was ... s.o.
Trotzdem:
Vor einem reboot sollte man immer prüfen:
- ist der Rechner noch erreichbar (z.B: ping)
- ist der Rechner noch per ssh erreichbar
- ist ein einloggen möglich
- weitere Fehlersuche ...
- Wenn kein ssh, was laufen an sonstigen Netzwerkdiensten (z.B: per nmap prüfen)
- .....
- Wenn nicht pingbar, ssh etc. was sagt denn eine Bildschirmausgabe (Bildschirm/Tastatur anschließen
Zitat von: Wernieman am 29 November 2016, 09:47:26
Das hört sich danach an, das der Pi nicht mehr auf seine "speichermöglichkeiten" zugreifen konnte. Alle bis dahin laufenden prozesse laufen noch. Logging ist natürlich nicht möglich.
Wenn ich recht habe, ist aber auch ein login nicht möglich, da meistens nicht im Speicher vorhandene Daten auf dem externen Medium (z.B: SDCarte) zugegriffen werden muss, was ... s.o.
so stell ich mir das auch vor. hast du denn eine idee, was diesen zustand auslösen könnte?
Zitat- Wenn nicht pingbar, ssh etc. was sagt denn eine Bildschirmausgabe (Bildschirm/Tastatur anschließen
habe leider keine passende hardware zur hand.
Beim Pi: Meistens Probleme mit der SDCarte (Karte, Kontackte etc.)
Bei anderen Systemen: HDD kaputt, wenn über USB gebootet, USB-Probleme
Zitatso stell ich mir das auch vor.
ich mir auch. Ich könnte jetzt mutmaßen, dass es bei mir seit der Umstellung auf USB-Boot ist. Aber der Auslöser muss ja was anderes sein :o
Zitathabe leider keine passende hardware zur hand.
dito :-[
@Werniemann: auf Deine Antwort hab ich schon lange gewartet :-* Kannst Du was zu den kworker-Prozessen(siehe Ausgangspost) sagen ?
"kworker-Prozessen(siehe Ausgangspost)" ??
Finde in dem Thread nichts dazu .. was meinst Du??
ZitatAls letzte Info noch zu meinem System: War tagelang gelaufen. Außer fhem läuft nichts an Anwendung auf der Kiste. Lt. top in der Regel deutlich unter 10% CPU. Lediglich ein paar kworker/u8:2, kworker/u8:3 kworker/u8:0 treiben Ihr "Unwesen" mit um die 10% Last. Im Inet hab ich nix gefunden, um rauszufinden, was da den Kernel zu den Prozessen veranlasst. Komischerweise wechselt die PID auch noch ?! Wären wir also bei Problemchen Nr. 3. Ich würd ja mal ohne fhem-start booten und gucken wollen, ob die kworker mit fhem im Zusammenhang stehen, aber dann hab ich ja wieder Problem Nr. 2 :'(
Ich darf mal aus einer kurzen Google-Suche Zitieren:
http://askubuntu.com/questions/33640/kworker-what-is-it-and-why-is-it-hogging-so-much-cpu
"kworker" is a placeholder process for kernel worker threads, which perform most of the actual processing for the kernel, especially in cases where there are interrupts, timers, I/O, etc. These typically correspond to the vast majority of any allocated "system" time to running processes. It is not something that can be safely removed from the system in any way, and is completely unrelated to nepomuk or KDE (except in that these programs may make system calls, which may require the kernel to do something).
There were some reports of excessive kworker activity for relatively idle systems starting during 2.6.36 development (example discussion), and wide reports of confusion and problems with 2.6.38 (although many of these reports include the word "Natty", so I presume these people not to have used any kernel between 2.6.35 (distributed in Ubuntu 10.10) and 2.6.38 (distributed in Ubuntu 11.04).
I've found many reports of something that "fixed" this for one or another user. Most "fixes" seem to be related to updates of the kernel of various sorts. Where the update can be tracked to a specific issue, it seems to often be some driver or kernel service that has been patched to not misbehave: I have the impression that there are a very large number of things in the kernel that can cause a behaviour which is observed as excessive kworker usage.
If you find the system unusable due to excessive kworker activity, I would recommend trying to do fewer things. If you think you're not doing anything, try shutting down long-running services or timers (RSS readers, mail readers, file indexers, activity trackers, etc.). If this doesn't work, try restarting. If your system allows you to enable or disable hardware in a pre-boot environment, try turning off hardware you aren't using. If it happens on every restart before you do anything, you could try uninstalling things, but at this point you'll want to be running syscall profiling tools to track down specific applications that seem to be causing this overload.
It is to be hoped that your specific system will stop expressing this behaviour with a future kernel upgrade (and many of the most common causes of this have been solved).
Es sind also Kernel-Prozesse
Edit:
https://berens.net/2014/10/ubuntu-14-04-hohe-cpu-last-durch-kworker/ (https://berens.net/2014/10/ubuntu-14-04-hohe-cpu-last-durch-kworker/)
Würde aber vorher mal probieren, ob Dein Kernel auch aktuell ist!
Danke für die Hilfe.
das
ZitatWürde aber vorher mal probieren, ob Dein Kernel auch aktuell ist!
war, glaub ich, aber keine gute Idee :'(
Fröhlich ein apt-get update mit nachfolgendem apt-get upgrade, dann den
Zitathttps://berens.net/2014/10/ubuntu-14-04-hohe-cpu-last-durch-kworker/
gelesen und hoffnungsfroh, denn unter dem Link ist tatsächlich erstmalig davon die Rede, wie man den kworkern auf die Schliche kommt, ans Werk gegangen. Leider wurde ich schnell in meiner Euphorie gedämpft, denn den dort beschriebenen Pfad kennt der Rpi gar nicht :( Egal, ein Versuch war es wert, da bisher alle anderen Fundstellen, nur sehr unkonkret das Thema angingen/beschreiben
ZitatI've found many reports of something that "fixed" this for one or another user. Most "fixes" seem to be related to updates of the kernel of various sorts.
Nächste Hoffnung: Nach einem reboot sind die kArbeiter verschwunden. Waren sie, denn der reboot funktionierte nicht mehr :'(
Ohne jetzt in die Details zu gehen: Erst mal mein SD-Reservesystem mit den Logs des USB-Sticks auf aktuellen Stand gebracht und das lauffähige System gebootet. Dann in Ruhe dem Boot-Fehler des Sticks nachgegangen. Aha, die Boot-Partition ist auch aktualisiert worden :'( Mir kommt die Anleitung zum Aufsetzen des USB-Boot-Modes in den Sinn. Was hatte ich da eigentlich ohne Sinn und Verstand getan ? BRANCH=next rpi-update :o Also lud ich mir den next-Branch runter, files auf die Boot-Partition kopiert und siehe da es bootet, Log-Files wieder von SD auf USB kopiert und.... fhem läuft nicht richtig, keine USBs :-\ Das war dann aber schnell erkannt ;) ein sudo BRANCH=next rpi-update und voila nach guten 3 Stunden ist mein System wieder da ;D Für....leider nichts(außer Erfahrung). Einzige Erkenntnis:
das SD-System hat die kworker nicht, während sie auf dem USB-System nicht verschwunden sind >:(
Es bleibt also die Frage: wie kommt man den Jungs auf die Schliche ?
Und neue Frage: Ich dachte rpi-update und update/upgrade wären unterschiedliche Dinge, die sich nicht in die Quere kommen, also das eine auf den Kernel beschränkt und das andere auf "Anwendungskomponenten". Scheinbar ist dem ja nicht so, was dann wohl bedeutet: kein update/upgrade ohne nachfolgendes BRANCH=next rpi-update !
Kenne ich nicht genau mit RasPi aus, aber mit Linux ... deshalb kann ich Dir bezüglich update/upgrade eines RasPis nicht helfen
das SD-System hat die kworker nicht, während sie auf dem USB-System nicht verschwunden sind
Frage:
Gleiche Kernelversion? Stichwort: "uname -a"
Gleiches System?
Wenn ja .. könnte es der USB-Zugriff sein. Dieser bedeutet schließlich auch Systemlast ...
ZitatGleiche Kernelversion? Stichwort: "uname -a"
Gleiches System?
Dürfte gleich sein. Mag jetzt nicht mit der SD neu testen, aber die Verzeichnisse im Github deuten für beides auf 4.4.35. Mit System meinst Du jetzt Jessie oder Wheezy oder die Hardware ? Hardware ist die selbe, mal mit SD als "normales" System, mal mit USB-als-Bootdevice gestartet. So wie ich das Ganze verstehe, ist, neben anderen Dingen, die MSD-Bootmöglichkeit bzw. eben der next-Branch eine Entwickler-/Beta-Version, die dann zukünftig in eine neue Version einfließt.
ZitatWenn ja .. könnte es der USB-Zugriff sein. Dieser bedeutet schließlich auch Systemlast ...
Was die Last anbelangt, glaub ich nicht daran. Auch die SD müsste ja dann eine sichtbare Last erzeugen. Aber natürlich kann es was mit USB zu tun haben. Ist halt schade, dass man im Nebel herumstochern muss. Dabei sind diese kworker-Prozesse ja eigentlich nur irgendwelche Prozesse, die vom Kernel ausgelöst/abgespalten werden. Und dass es da keine einfache Möglichkeit gibt herauszufinden, was die tun.... :'(
@Frank: hast Du eigentlich den next-Branch drauf und auch die kworker-Prozesse ?
Grüße Markus
Du kannst per "Kernel-Debugging" bzw. perf-monitoring dieses verfolgen. ABER .. dieses ist schon für Vortgeschrittene und ich weiß nicht, wie weit Dein Wissen ist ....
(Nicht falsch verstehen)
Zitat@Frank: hast Du eigentlich den next-Branch drauf und auch die kworker-Prozesse ?
nach dem installieren des normalen jessie lite auf sd, ungefähr im august, sind mir diese prozesse auch aufgefallen.
da es meine erste bekanntschaft mit dem pi war, habe ich mich zwar auch gewundert, aber nach unbefriedigender recherche habe ich sie erstmal als "normal" bewertet.
zur zeit habe ich ein riesen desaster, da ich gar keinen zugriff mehr bekomme und fhem läuft scheinbar auch nicht mehr. :)
1. Pi Pingbar?
2. Was sagt ssh?
hallo,
ich habe hier mal mitgelesen und bei mir geschaut.
Auch bei mir ist der kworker Process sehr hoch gewesen bis 45% und teilweise mehr.
habe mich die Tage immer gewundert warum Fhem zwischendurch hängt.
Habe natürlich gegoogelt aber nicht wirklich etwas über "kworker/u8:" gefunden
Dann kam mir vorhin der Gedanke, auch ich habe meinen Raspi3 von SD-Karte auf USB-Stick umgestellt und SD-Karte entfernt. Läuft
Ich bin der Meinung das es seit diesem Zeitpunkt probleme gibt.
Evtl. Lösung
Ich habe gerade eine SD-Karte in Windows neu formatiert auf fat32.
Dann habe ich den Raspi3 runtergefahren, die leere SD-Karte eingesetzt.
Raspi gestartet
Top aufgerufen
und siehe da, jetzt ist Ruhe. Kein kworker Process der ständig läuft.
kworker kommt ab und zu mal mit 0,3 % aber auch gleich wieder weg und nicht wie vorher ständig in der ersten Leiste mit 15-45 %
Also scheint es so, wenn keine SD-Karte eingesetzt wird sucht der Kernel ständig und mit viel Power der CPU nach der SD-Karte. Schlimmer als der Hund nach dem Herrchen
Gruß Werner
Frage ist ... wie sieht die fstab aus?
ZitatEvtl. Lösung
Lösung nicht, denn es bleibt ja die Frage, was dann die Zugriffe auf die SD sollen :o Aber es ist ein Workaround. Mit leerer SD habe ich zwar noch kworker-Prozesse(klar !), aber keinen mehr der Performance frisst ;D Jetzt sehe ich nur noch mein fhem und 1w ganz open in top. So soll es sein.
ZitatFrage ist ... wie sieht die fstab aus?
proc /proc proc defaults 0 0
/dev/sda1 /boot vfat defaults 0 2
/dev/sda2 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
Zitatzur zeit habe ich ein riesen desaster, da ich gar keinen zugriff mehr bekomme und fhem läuft scheinbar auch nicht mehr. :)
Käse, melde Dich, wenn man helfen, also etwas nachstellen kann/soll.
Edit:
Zitat(Nicht falsch verstehen)
Nee, nee passt schon. Und Kernel selber kompilieren ist mir zu heftig für das dann doch eher kleine Problem. Aber so ein verbose 5 oder stacktrace hätt ich mir irgendwie erhofft ;D
Also eigentlich sollte ein "perf-test" ohne selbstkompilieren fukntionieren. Ich habe hier den Verdacht, das der RasPi-Kernel irgendwie ... "optimiert" wurde, was bei einem booten über USB sich dann eben so negativ auswirkt ...
Nur ohne Testsystem kann ich es aktuell nicht überprüfen
ZitatAlso eigentlich sollte ein "perf-test" ohne selbstkompilieren fukntionieren.
Joo, wenn es perf-test in der raspbian distribution gäbe :( Hatte vorher mit "perf-test rpi" gegoogelt. Mit "perf-test linux" sieht das Ergebnis natürlich deutlich anders aus. Schade, dass Du keinen rpi hast :'(
Spendierst Du mir einen? 8)
Irgendwann werde ich mir einen zulegen .. nur momentan brauche ich genug Hirnschmals für "neuen Job"
Moin,
@Wernieman
ich habe hier noch ein Raspi 3 als Testgerät rumliegen.
soll ich etwas testen.
Sag mir was ich machen kann/soll
Gruß Werner
Ups .. werner hilft werner ;o)
Nee ... ich sollte testen. Mangels RasPi kann ich nicht .. und ich glaube, Kernel-perf-monitoring dürfte auch nicht Deine Spezialität sein ;o)
Müsste mich selber auch "wieder" einlesen ..
ich habe jetzt ein altes tv-gerät an den videoausgang (3.5mm klinkenstecker) gehängt, um meldungen auf der konsole sehen zu können, falls das problem mit dem dateizugriff erneut auftritt. ich würde hier gerne das syslog und/oder kern.log in "echtzeit" verfolgen können. aber wie stelle ich das am besten an?
im augenblick nutze ich tail zur anzeige, haben aber die vermutung, dass hiermit ebenfalls keine anzeige zu bekommen sein wird, wenn das system keine dateizugriffe mehr erlaubt. irgendwie müsste man die signale abfangen und umleiten, bevor sie in die logs kommen. hat hierzu jemand eine idee?
gruss frank
Stichwort: syslog
Kann Dir da keine Patentlösung anbieten. Aber den Syslog kannst Du vieles "Beibringen". Siehe dessen Konfiguration.
Btw:
Du müstest aber imm er noch einen unabhängigen Speicherplatz für die Logs haben. Es bringt nichts, sie "nur" abzugreifen ...
Zitat von: Wernieman am 05 Dezember 2016, 08:04:35
Stichwort: syslog
Kann Dir da keine Patentlösung anbieten. Aber den Syslog kannst Du vieles "Beibringen". Siehe dessen Konfiguration.
Btw:
Du müstest aber imm er noch einen unabhängigen Speicherplatz für die Logs haben. Es bringt nichts, sie "nur" abzugreifen ...
merci.
allerdings ist es beim pi3/jessie_lite rsyslog.
*.* /dev/consolemit dieser neuen zeile am anfang der rules section in /etc/rsyslog.config bekomme ich jetzt zumindestens automatisch alle meldungen zusätzlich auf den angeschlossenen tv. wahrscheinlich kann man sogar über das netzwerk versenden, mal schauen.
ich hoffe nun, dass beim auftreten des fehlers nicht zu viele meldungen kommen, sodass die ersten meldungen noch sichtbar sind, wenn ich den fehler bemerke, falls überhaupt etwas kommt. ;)
nachtrag zu meinem "desaster":
nach meinem letzten reboot (stecker ziehen) wegen dem dateizugriffsproblem habe ich tagelang keinen zugriff mehr auf den pi bekommen. fhem wurde nicht gestartet und ssh war nicht möglich, obwohl sich der pi immer an der fritzbox angemeldet. auch mit einem neuen, aktuellen image auf anderer sd, war nichts möglich. ich habe alles erdenkliche in unterschiedlichsten konstellationen versucht: gehäuse entfernt, unterschiedliche umgebungstemperaturen, sd kontakte gereinigt und mehr kontaktdruck erzeugt, ethernet und/oder wlan, hmuart adapter platine vom gpio entfernt, ....
zum glück habe ich dann die möglichkeit zum anschluss eines tv bemerkt. denn exakt seit dem ersten einstecken des tv mit anschliesendem einstecken des netzteils funktioniert wieder alles normal, sogar mit beiden sd karten. so, als hätte es nie ein problem gegeben. das kann doch kein zufall sein, oder? kann ein nicht angeschlossener monitor theoretisch probleme verursachen?
oder kennt jemand einen pi-virus?
@KölnSolar
hast du deinen pi3 auch von elv?
elv keinesfalls. Ich meine von pollin.
Schon komisch manchmal diese Probleme. Bei mir lag es(Problem 2) ja irgendwie an einem USB-Hub und dessen Kabel. Irgendwie deshalb, weil der Pi3 jetzt wieder problemlos bootet, ohne dass etwas verändert ist.
Seit 5 Tagen läuft er nun und Problem 1("einfrieren") ist auch nicht wieder aufgetreten. Allerdings hab ich fhem ein paar mal rebootet wg. Neuentwicklungen.
Zitatkann ein nicht angeschlossener monitor theoretisch probleme verursachen?
Kann ich mir nicht vorstellen.
Grüße Markus
für den fall der fälle habe ich mir jetzt mal eine ramdisk eingerichtet und lasse den rsyslogd hier ebenfalls alle systemmeldungen speichern.
Zitatramdisk eingerichtet
Was bekanntlich nach einem reboot "weg" ist ... Du brächtest noch eine zusätzliche Sicherung
Zitat von: Wernieman am 07 Dezember 2016, 14:42:53
Was bekanntlich nach einem reboot "weg" ist ... Du brächtest noch eine zusätzliche Sicherung
schon klar.
da bisher "nur" der zugriff auf physikalische medien (sd-card oder usb-stick) unmöglich zu sein scheint, sonst aber alles etrem gut weiter läuft (einmal mindestens 10 tage bei mir), habe ich die hoffnung über eine direkt angeschlossene console am rpi, im fehlerfall zugriff auf die syslog datei in der ramdisk zu erlangen.
die letzte möglichkeit, die mir zur zeit einfällt, wäre, die systemmeldungen mit rsyslogd über tcp an einen anderen server zu senden, die dort dann von dessen rsyslogd eingesammelt und gespeichert werden. dazu fehlt mir derzeit das equipment.
Es gibt auch noch nfs etc. ... also mehrere Möglichkeiten. Da muß nicht gleich rsyslog ran ...
bei mir ist es gerade wieder passiert. auf der console kommen nun im 3s takt folgende syslog-meldungen vom kernel
mmc0: card never left busy state
mmc0: error -110 whilst initialising SD card
und ab und zu etwa folgendes
ext4-fs warning .... comm perl: error -5 reading directory block
leider sind das nur die auswirkungen und nicht der beginn des problems.
befehle über tastatus werden leider nicht angenommen:command not found.
da muss ich doch noch mal nfs probieren.
oh, shit :'(
ich hab seit Wochen Ruhe(nicht unken ;))
unser Profi Werniemann hatte ja direkt die SD im Verdacht. Mir scheint, dass es nicht an der Hardware(Karte,Leser), sondern an der Software, also jessie, liegt. Warum sonst hab ich das Problem nicht mehr, obwohl ich als einzige Änderung nur ne leere SD eingeschoben habe ? Oder das Problem nach einem Reboot nicht mehr existent ist.
Wäre interessant, wenn Du auf USB umstellst und ne leere SD einlegst, ob Du dann auch problemfrei bleibst.
Viel Erfolg, Markus
Ich würde es nicht an jessie, sondern dem "RasPi-Kernel" die Schuld geben. Mir ist unter jessie so etwas nicht bekannt ...
ich hatte ja auch 3 wochen ruhe. ;)
über google habe ich bisher noch nichts wirklich brauchbares gefunden. im wesentlichen auch spekulationen über den kernel und aussagen darüber, dass es nicht an der karte liegen kann, da diese auf anderen betriebssystemen anscheinend fehlerfrei funktioniert. ich habe eine sandisk ultra sdhc 32gb. mit welcher karte ist es bei dir aufgetreten, markus?
bei mir ist es jetzt 4x aufgetreten. 2x in abwesenheit und 2x während ich über ssh eingelogt war und mit apt-get gearbeitet habe. dieses mal bei apt-get update/upgrade mit folgenden bildschirmmeldungen:
root@raspberrypi:/home/pi# apt-get update
Get:1 http://mirrordirector.raspbian.org jessie InRelease [14.9 kB]
Get:2 http://mirrordirector.raspbian.org jessie/main armhf Packages [8,981 kB]
Ign http://archive.raspberrypi.org jessie InRelease
Ign http://archive.raspberrypi.org jessie Release.gpg
Ign http://archive.raspberrypi.org jessie Release
Get:3 http://mirrordirector.raspbian.org jessie/contrib armhf Packages [37.5 kB]
Get:4 http://mirrordirector.raspbian.org jessie/non-free armhf Packages [70.3 kB]
Get:5 http://mirrordirector.raspbian.org jessie/rpi armhf Packages [1,356 B]
Ign http://mirrordirector.raspbian.org jessie/contrib Translation-en_GB
Ign http://mirrordirector.raspbian.org jessie/contrib Translation-en
Ign http://mirrordirector.raspbian.org jessie/main Translation-en_GB
Ign http://mirrordirector.raspbian.org jessie/main Translation-en
Ign http://mirrordirector.raspbian.org jessie/non-free Translation-en_GB
Ign http://mirrordirector.raspbian.org jessie/non-free Translation-en
Ign http://mirrordirector.raspbian.org jessie/rpi Translation-en_GB
Ign http://mirrordirector.raspbian.org jessie/rpi Translation-en
Err http://archive.raspberrypi.org jessie/main armhf Packages
503 Service Unavailable [IP: 93.93.130.214 80]
Err http://archive.raspberrypi.org jessie/ui armhf Packages
503 Service Unavailable [IP: 93.93.130.214 80]
Ign http://archive.raspberrypi.org jessie/main Translation-en_GB
Ign http://archive.raspberrypi.org jessie/main Translation-en
Ign http://archive.raspberrypi.org jessie/ui Translation-en_GB
Ign http://archive.raspberrypi.org jessie/ui Translation-en
Fetched 9,105 kB in 33s (271 kB/s)
W: Failed to fetch http://archive.raspberrypi.org/debian/dists/jessie/main/binary-armhf/Packages 503 Service Unavailable [IP: 93.93.130.214 80]
W: Failed to fetch http://archive.raspberrypi.org/debian/dists/jessie/ui/binary-armhf/Packages 503 Service Unavailable [IP: 93.93.130.214 80]
E: Some index files failed to download. They have been ignored, or old ones used instead.
E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.
root@raspberrypi:/home/pi# dpkg --configure -a
Setting up man-db (2.7.0.2-5) ...
Updating database of manual pages ...
root@raspberrypi:/home/pi# apt-get update
Hit http://mirrordirector.raspbian.org jessie InRelease
Hit http://mirrordirector.raspbian.org jessie/main armhf Packages
Hit http://mirrordirector.raspbian.org jessie/contrib armhf Packages
Hit http://mirrordirector.raspbian.org jessie/non-free armhf Packages
Hit http://mirrordirector.raspbian.org jessie/rpi armhf Packages
Ign http://mirrordirector.raspbian.org jessie/contrib Translation-en_GB
Ign http://mirrordirector.raspbian.org jessie/contrib Translation-en
Ign http://mirrordirector.raspbian.org jessie/main Translation-en_GB
Ign http://mirrordirector.raspbian.org jessie/main Translation-en
Ign http://mirrordirector.raspbian.org jessie/non-free Translation-en_GB
Ign http://mirrordirector.raspbian.org jessie/non-free Translation-en
Ign http://mirrordirector.raspbian.org jessie/rpi Translation-en_GB
Ign http://mirrordirector.raspbian.org jessie/rpi Translation-en
Get:1 http://archive.raspberrypi.org jessie InRelease [22.9 kB]
Get:2 http://archive.raspberrypi.org jessie/main armhf Packages [130 kB]
Get:3 http://archive.raspberrypi.org jessie/ui armhf Packages [53.6 kB]
Ign http://archive.raspberrypi.org jessie/main Translation-en_GB
Ign http://archive.raspberrypi.org jessie/main Translation-en
Ign http://archive.raspberrypi.org jessie/ui Translation-en_GB
Ign http://archive.raspberrypi.org jessie/ui Translation-en
Fetched 207 kB in 28s (7,172 B/s)
Reading package lists... Done
root@raspberrypi:/home/pi# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
plymouth raspberrypi-sys-mods
The following packages will be upgraded:
apt apt-utils bind9-host curl dmsetup dpkg dpkg-dev e2fslibs e2fsprogs file firmware-atheros firmware-brcm80211 firmware-libertas firmware-ralink
firmware-realtek fontconfig fontconfig-config gdb gdbserver gnupg gpgv initramfs-tools libapt-inst1.5 libapt-pkg4.12 libbind9-90 libc-bin libc-dev-bin
libc6 libc6-dbg libc6-dev libcairo2 libcomerr2 libcurl3 libcurl3-gnutls libdevmapper1.02.1 libdns-export100 libdns100 libdpkg-perl libdrm2 libexpat1
libfontconfig1 libgcrypt20 libgd3 libicu52 libidn11 libirs-export91 libisc-export95 libisc95 libisccc90 libisccfg-export90 libisccfg90 liblwres90
libmagic1 libmodule-build-perl libnet-ssleay-perl libpython2.7 libpython2.7-minimal libpython2.7-stdlib libraspberrypi-bin libraspberrypi-dev
libraspberrypi-doc libraspberrypi0 libsqlite3-0 libss2 libssl1.0.0 libsystemd0 libudev1 libwbclient0 libxapian22 libxml2 locales multiarch-support ntp
openssh-client openssh-server openssh-sftp-server openssl perl perl-base perl-modules python-rpi.gpio python2.7 python2.7-minimal raspberrypi-bootloader
raspberrypi-kernel raspi-config samba-common sqlite3 ssh systemd systemd-sysv tzdata udev vim-common vim-tiny wget wpasupplicant
97 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Need to get 131 MB of archives.
After this operation, 2,800 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://mirrordirector.raspbian.org/raspbian/ jessie/main dpkg armhf 1.17.27 [2,930 kB]
Get:2 http://mirrordirector.raspbian.org/raspbian/ jessie/main libc6-dev armhf 2.19-18+deb8u6 [1,724 kB]
Get:3 http://mirrordirector.raspbian.org/raspbian/ jessie/main libc-dev-bin armhf 2.19-18+deb8u6 [231 kB]
Get:4 http://mirrordirector.raspbian.org/raspbian/ jessie/main libc-bin armhf 2.19-18+deb8u6 [1,205 kB]
Get:5 http://mirrordirector.raspbian.org/raspbian/ jessie/main libc6-dbg armhf 2.19-18+deb8u6 [3,180 kB]
Get:6 http://mirrordirector.raspbian.org/raspbian/ jessie/main libc6 armhf 2.19-18+deb8u6 [4,082 kB]
Get:7 http://archive.raspberrypi.org/debian/ jessie/main libcairo2 armhf 1.14.0-2.1+deb8u1+rpi1 [662 kB]
Get:8 http://mirrordirector.raspbian.org/raspbian/ jessie/main e2fslibs armhf 1.42.12-2 [173 kB]
Get:9 http://mirrordirector.raspbian.org/raspbian/ jessie/main e2fsprogs armhf 1.42.12-2 [728 kB]
Get:10 http://mirrordirector.raspbian.org/raspbian/ jessie/main perl armhf 5.20.2-3+deb8u6 [2,070 kB]
Get:11 http://mirrordirector.raspbian.org/raspbian/ jessie/main perl-base armhf 5.20.2-3+deb8u6 [1,102 kB]
Get:12 http://mirrordirector.raspbian.org/raspbian/ jessie/main perl-modules all 5.20.2-3+deb8u6 [2,547 kB]
Get:13 http://mirrordirector.raspbian.org/raspbian/ jessie/main libmodule-build-perl all 0.421000-2+deb8u1 [265 kB]
Get:14 http://mirrordirector.raspbian.org/raspbian/ jessie/main libapt-pkg4.12 armhf 1.0.9.8.4 [713 kB]
Get:15 http://mirrordirector.raspbian.org/raspbian/ jessie/main gpgv armhf 1.4.18-7+deb8u3 [177 kB]
Get:16 http://mirrordirector.raspbian.org/raspbian/ jessie/main gnupg armhf 1.4.18-7+deb8u3 [1,070 kB]
Get:17 http://mirrordirector.raspbian.org/raspbian/ jessie/main apt armhf 1.0.9.8.4 [1,067 kB]
Get:18 http://mirrordirector.raspbian.org/raspbian/ jessie/main libudev1 armhf 215-17+deb8u5 [52.7 kB]
Get:19 http://mirrordirector.raspbian.org/raspbian/ jessie/main udev armhf 215-17+deb8u5 [850 kB]
Get:20 http://mirrordirector.raspbian.org/raspbian/ jessie/main libcomerr2 armhf 1.42.12-2 [59.7 kB]
Get:21 http://mirrordirector.raspbian.org/raspbian/ jessie/main libss2 armhf 1.42.12-2 [63.2 kB]
Get:22 http://mirrordirector.raspbian.org/raspbian/ jessie/main libgcrypt20 armhf 1.6.3-2+deb8u2 [334 kB]
Get:23 http://mirrordirector.raspbian.org/raspbian/ jessie/main dmsetup armhf 2:1.02.90-2.2+deb8u1 [66.5 kB]
Get:24 http://mirrordirector.raspbian.org/raspbian/ jessie/main libdevmapper1.02.1 armhf 2:1.02.90-2.2+deb8u1 [138 kB]
Get:25 http://mirrordirector.raspbian.org/raspbian/ jessie/main initramfs-tools all 0.120+deb8u2 [96.3 kB]
Get:26 http://mirrordirector.raspbian.org/raspbian/ jessie/main libsystemd0 armhf 215-17+deb8u5 [84.8 kB]
Get:27 http://mirrordirector.raspbian.org/raspbian/ jessie/main systemd armhf 215-17+deb8u5 [2,211 kB]
Get:28 http://archive.raspberrypi.org/debian/ jessie/main libdrm2 armhf 2.4.71-1+rpi1 [32.4 kB]
Get:29 http://archive.raspberrypi.org/debian/ jessie/main firmware-atheros all 0.43+rpi5 [873 kB]
Get:30 http://mirrordirector.raspbian.org/raspbian/ jessie/main systemd-sysv armhf 215-17+deb8u5 [35.6 kB]
Get:31 http://mirrordirector.raspbian.org/raspbian/ jessie/main libapt-inst1.5 armhf 1.0.9.8.4 [166 kB]
Get:32 http://mirrordirector.raspbian.org/raspbian/ jessie/main libssl1.0.0 armhf 1.0.1t-1+deb8u5 [853 kB]
Get:33 http://mirrordirector.raspbian.org/raspbian/ jessie/main libidn11 armhf 1.29-1+deb8u2 [133 kB]
Get:34 http://mirrordirector.raspbian.org/raspbian/ jessie/main file armhf 1:5.22+15-2+deb8u2 [60.1 kB]
Get:35 http://mirrordirector.raspbian.org/raspbian/ jessie/main libmagic1 armhf 1:5.22+15-2+deb8u2 [244 kB]
Get:36 http://mirrordirector.raspbian.org/raspbian/ jessie/main python2.7 armhf 2.7.9-2+deb8u1 [252 kB]
Get:37 http://mirrordirector.raspbian.org/raspbian/ jessie/main python2.7-minimal armhf 2.7.9-2+deb8u1 [1,150 kB]
Get:38 http://mirrordirector.raspbian.org/raspbian/ jessie/main libpython2.7 armhf 2.7.9-2+deb8u1 [930 kB]
Get:39 http://mirrordirector.raspbian.org/raspbian/ jessie/main libpython2.7-stdlib armhf 2.7.9-2+deb8u1 [1,812 kB]
Get:40 http://mirrordirector.raspbian.org/raspbian/ jessie/main libpython2.7-minimal armhf 2.7.9-2+deb8u1 [376 kB]
Get:41 http://mirrordirector.raspbian.org/raspbian/ jessie/main libexpat1 armhf 2.1.0-6+deb8u3 [60.5 kB]
Get:42 http://mirrordirector.raspbian.org/raspbian/ jessie/main sqlite3 armhf 3.8.7.1-1+deb8u2 [99.6 kB]
Get:43 http://mirrordirector.raspbian.org/raspbian/ jessie/main libsqlite3-0 armhf 3.8.7.1-1+deb8u2 [377 kB]
Get:44 http://archive.raspberrypi.org/debian/ jessie/main firmware-brcm80211 all 0.43+rpi5 [1,678 kB]
Get:45 http://mirrordirector.raspbian.org/raspbian/ jessie/main libxml2 armhf 2.9.1+dfsg1-5+deb8u3 [705 kB]
Get:46 http://mirrordirector.raspbian.org/raspbian/ jessie/main fontconfig-config all 2.11.0-6.3+deb8u1 [274 kB]
Get:47 http://mirrordirector.raspbian.org/raspbian/ jessie/main libfontconfig1 armhf 2.11.0-6.3+deb8u1 [312 kB]
Get:48 http://mirrordirector.raspbian.org/raspbian/ jessie/main fontconfig armhf 2.11.0-6.3+deb8u1 [402 kB]
Get:49 http://mirrordirector.raspbian.org/raspbian/ jessie/main curl armhf 7.38.0-4+deb8u5 [196 kB]
Get:50 http://mirrordirector.raspbian.org/raspbian/ jessie/main libcurl3 armhf 7.38.0-4+deb8u5 [232 kB]
Get:51 http://mirrordirector.raspbian.org/raspbian/ jessie/main libcurl3-gnutls armhf 7.38.0-4+deb8u5 [225 kB]
Get:52 http://mirrordirector.raspbian.org/raspbian/ jessie/main libisc-export95 armhf 1:9.9.5.dfsg-9+deb8u8 [124 kB]
Get:53 http://mirrordirector.raspbian.org/raspbian/ jessie/main libdns-export100 armhf 1:9.9.5.dfsg-9+deb8u8 [399 kB]
Get:54 http://mirrordirector.raspbian.org/raspbian/ jessie/main libgd3 armhf 2.1.0-5+deb8u7 [127 kB]
Get:55 http://mirrordirector.raspbian.org/raspbian/ jessie/main libicu52 armhf 52.1-8+deb8u4 [6,556 kB]
Get:56 http://mirrordirector.raspbian.org/raspbian/ jessie/main libisccfg-export90 armhf 1:9.9.5.dfsg-9+deb8u8 [37.7 kB]
Get:57 http://mirrordirector.raspbian.org/raspbian/ jessie/main libirs-export91 armhf 1:9.9.5.dfsg-9+deb8u8 [36.4 kB]
Get:58 http://mirrordirector.raspbian.org/raspbian/ jessie/main libwbclient0 armhf 2:4.2.14+dfsg-0+deb8u2 [117 kB]
Get:59 http://mirrordirector.raspbian.org/raspbian/ jessie/main ntp armhf 1:4.2.6.p5+dfsg-7+deb8u2 [334 kB]
Get:60 http://mirrordirector.raspbian.org/raspbian/ jessie/main samba-common all 2:4.2.14+dfsg-0+deb8u2 [269 kB]
Get:61 http://mirrordirector.raspbian.org/raspbian/ jessie/main openssh-sftp-server armhf 1:6.7p1-5+deb8u3 [33.1 kB]
Get:62 http://mirrordirector.raspbian.org/raspbian/ jessie/main openssh-server armhf 1:6.7p1-5+deb8u3 [313 kB]
Get:63 http://mirrordirector.raspbian.org/raspbian/ jessie/main openssh-client armhf 1:6.7p1-5+deb8u3 [620 kB]
Get:64 http://mirrordirector.raspbian.org/raspbian/ jessie/main ssh all 1:6.7p1-5+deb8u3 [120 kB]
Get:65 http://mirrordirector.raspbian.org/raspbian/ jessie/main multiarch-support armhf 2.19-18+deb8u6 [180 kB]
Get:66 http://mirrordirector.raspbian.org/raspbian/ jessie/main tzdata all 2016f-0+deb8u1 [185 kB]
Get:67 http://mirrordirector.raspbian.org/raspbian/ jessie/main apt-utils armhf 1.0.9.8.4 [353 kB]
Get:68 http://mirrordirector.raspbian.org/raspbian/ jessie/main libxapian22 armhf 1.2.19-1+deb8u1 [863 kB]
Get:69 http://mirrordirector.raspbian.org/raspbian/ jessie/main vim-tiny armhf 2:7.4.488-7+deb8u1 [357 kB]
Get:70 http://mirrordirector.raspbian.org/raspbian/ jessie/main vim-common armhf 2:7.4.488-7+deb8u1 [184 kB]
Get:71 http://mirrordirector.raspbian.org/raspbian/ jessie/main wget armhf 1.16-1+deb8u1 [475 kB]
Get:72 http://mirrordirector.raspbian.org/raspbian/ jessie/main bind9-host armhf 1:9.9.5.dfsg-9+deb8u8 [65.4 kB]
Get:73 http://mirrordirector.raspbian.org/raspbian/ jessie/main libisc95 armhf 1:9.9.5.dfsg-9+deb8u8 [150 kB]
Get:74 http://mirrordirector.raspbian.org/raspbian/ jessie/main libdns100 armhf 1:9.9.5.dfsg-9+deb8u8 [599 kB]
Get:75 http://mirrordirector.raspbian.org/raspbian/ jessie/main libisccc90 armhf 1:9.9.5.dfsg-9+deb8u8 [34.1 kB]
Get:76 http://mirrordirector.raspbian.org/raspbian/ jessie/main libisccfg90 armhf 1:9.9.5.dfsg-9+deb8u8 [50.1 kB]
Get:77 http://mirrordirector.raspbian.org/raspbian/ jessie/main libbind9-90 armhf 1:9.9.5.dfsg-9+deb8u8 [41.1 kB]
Get:78 http://mirrordirector.raspbian.org/raspbian/ jessie/main liblwres90 armhf 1:9.9.5.dfsg-9+deb8u8 [47.6 kB]
Get:79 http://mirrordirector.raspbian.org/raspbian/ jessie/main locales all 2.19-18+deb8u6 [3,945 kB]
Get:80 http://mirrordirector.raspbian.org/raspbian/ jessie/main dpkg-dev all 1.17.27 [1,548 kB]
Get:81 http://archive.raspberrypi.org/debian/ jessie/main firmware-libertas all 0.43+rpi5 [1,842 kB]
Get:82 http://mirrordirector.raspbian.org/raspbian/ jessie/main libdpkg-perl all 1.17.27 [1,075 kB]
Get:83 http://mirrordirector.raspbian.org/raspbian/ jessie/main libnet-ssleay-perl armhf 1.65-1+deb8u1 [259 kB]
Get:84 http://mirrordirector.raspbian.org/raspbian/ jessie/main openssl armhf 1.0.1t-1+deb8u5 [652 kB]
Get:85 http://mirrordirector.raspbian.org/raspbian/ jessie/main wpasupplicant armhf 2.3-1+deb8u4 [778 kB]
Get:86 http://archive.raspberrypi.org/debian/ jessie/main firmware-ralink all 0.43+rpi5 [45.8 kB]
Get:87 http://archive.raspberrypi.org/debian/ jessie/main firmware-realtek all 0.43+rpi5 [209 kB]
Get:88 http://archive.raspberrypi.org/debian/ jessie/main gdb armhf 7.7.1+dfsg-5+rpi1 [1,964 kB]
Get:89 http://archive.raspberrypi.org/debian/ jessie/main gdbserver armhf 7.7.1+dfsg-5+rpi1 [205 kB]
Get:90 http://archive.raspberrypi.org/debian/ jessie/main python-rpi.gpio armhf 0.6.3~jessie-1 [23.5 kB]
Get:91 http://archive.raspberrypi.org/debian/ jessie/main libraspberrypi-dev armhf 1.20161215-1 [397 kB]
Get:92 http://archive.raspberrypi.org/debian/ jessie/main libraspberrypi-doc armhf 1.20161215-1 [31.4 MB]
Get:93 http://archive.raspberrypi.org/debian/ jessie/main raspberrypi-kernel armhf 1.20161215-1 [30.1 MB]
Err http://archive.raspberrypi.org/debian/ jessie/main libraspberrypi-bin armhf 1.20161215-1
500 Internal Server Error [IP: 93.93.130.39 80]
Err http://archive.raspberrypi.org/debian/ jessie/main libraspberrypi0 armhf 1.20161215-1
500 Internal Server Error [IP: 93.93.130.39 80]
Get:94 http://archive.raspberrypi.org/debian/ jessie/main raspberrypi-bootloader armhf 1.20161215-1 [3,260 kB]
Get:95 http://archive.raspberrypi.org/debian/ jessie/main raspi-config all 20161207 [17.7 kB]
Fetched 130 MB in 9min 21s (231 kB/s)
E: Failed to fetch http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/libraspberrypi-bin_1.20161215-1_armhf.deb 500 Internal Server Error [IP: 93.93.130.39 80]
E: Failed to fetch http://archive.raspberrypi.org/debian/pool/main/r/raspberrypi-firmware/libraspberrypi0_1.20161215-1_armhf.deb 500 Internal Server Error [IP: 93.93.130.39 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
root@raspberrypi:/home/pi# apt-get update
Hit http://archive.raspberrypi.org jessie InRelease
Hit http://mirrordirector.raspbian.org jessie InRelease
Hit http://archive.raspberrypi.org jessie/main armhf Packages
Hit http://mirrordirector.raspbian.org jessie/main armhf Packages
Hit http://archive.raspberrypi.org jessie/ui armhf Packages
Hit http://mirrordirector.raspbian.org jessie/contrib armhf Packages
Hit http://mirrordirector.raspbian.org jessie/non-free armhf Packages
Hit http://mirrordirector.raspbian.org jessie/rpi armhf Packages
Ign http://archive.raspberrypi.org jessie/main Translation-en_GB
Ign http://archive.raspberrypi.org jessie/main Translation-en
Ign http://archive.raspberrypi.org jessie/ui Translation-en_GB
Ign http://archive.raspberrypi.org jessie/ui Translation-en
Ign http://mirrordirector.raspbian.org jessie/contrib Translation-en_GB
Ign http://mirrordirector.raspbian.org jessie/contrib Translation-en
Ign http://mirrordirector.raspbian.org jessie/main Translation-en_GB
Ign http://mirrordirector.raspbian.org jessie/main Translation-en
Ign http://mirrordirector.raspbian.org jessie/non-free Translation-en_GB
Ign http://mirrordirector.raspbian.org jessie/non-free Translation-en
Ign http://mirrordirector.raspbian.org jessie/rpi Translation-en_GB
Ign http://mirrordirector.raspbian.org jessie/rpi Translation-en
Reading package lists... Done
root@raspberrypi:/home/pi# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
The following packages have been kept back:
plymouth raspberrypi-sys-mods
The following packages will be upgraded:
apt apt-utils bind9-host curl dmsetup dpkg dpkg-dev e2fslibs e2fsprogs file firmware-atheros firmware-brcm80211 firmware-libertas firmware-ralink
firmware-realtek fontconfig fontconfig-config gdb gdbserver gnupg gpgv initramfs-tools libapt-inst1.5 libapt-pkg4.12 libbind9-90 libc-bin libc-dev-bin
libc6 libc6-dbg libc6-dev libcairo2 libcomerr2 libcurl3 libcurl3-gnutls libdevmapper1.02.1 libdns-export100 libdns100 libdpkg-perl libdrm2 libexpat1
libfontconfig1 libgcrypt20 libgd3 libicu52 libidn11 libirs-export91 libisc-export95 libisc95 libisccc90 libisccfg-export90 libisccfg90 liblwres90
libmagic1 libmodule-build-perl libnet-ssleay-perl libpython2.7 libpython2.7-minimal libpython2.7-stdlib libraspberrypi-bin libraspberrypi-dev
libraspberrypi-doc libraspberrypi0 libsqlite3-0 libss2 libssl1.0.0 libsystemd0 libudev1 libwbclient0 libxapian22 libxml2 locales multiarch-support ntp
openssh-client openssh-server openssh-sftp-server openssl perl perl-base perl-modules python-rpi.gpio python2.7 python2.7-minimal raspberrypi-bootloader
raspberrypi-kernel raspi-config samba-common sqlite3 ssh systemd systemd-sysv tzdata udev vim-common vim-tiny wget wpasupplicant
97 upgraded, 0 newly installed, 0 to remove and 2 not upgraded.
Need to get 1,172 kB/131 MB of archives.
After this operation, 2,800 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.raspberrypi.org/debian/ jessie/main libraspberrypi-bin armhf 1.20161215-1 [331 kB]
Get:2 http://archive.raspberrypi.org/debian/ jessie/main libraspberrypi0 armhf 1.20161215-1 [842 kB]
Fetched 1,172 kB in 32s (36.2 kB/s)
Reading changelogs... Done
Extracting templates from packages: 100%
Preconfiguring packages ...
dpkg: unrecoverable fatal error, aborting:
unable to open files list file for package `libboost-iostreams1.49.0': Input/output error
E: Sub-process /usr/bin/dpkg returned an error code (2)
E: Failed to write temporary StateFile /var/lib/apt/extended_states.tmp
root@raspberrypi:/home/pi# apt-get upgrade
bash: /usr/bin/apt-get: Input/output error
root@raspberrypi:/home/pi# reboot
bash: reboot: command not found
ich musste beide befehle 2x anstossen, bis alle listen/packages da waren. und am ende während "Preconfiguring packages ..." ist es dann passiert. zufall?
vielleicht noch ein hinweis.
da ich bluetooth mal nutzen wollte, war mir gestern durch den nachbar-thread aufgefallen das der hciuart.service beim letzten reboot vor ca 1 woche nicht automatisch von systemd gestartet werden konnte, also nicht lief. es scheint zufall zu sein, dass der service gestartet wird. kurz vor dem crash hatte ich ihn manuell gestartet. vielleicht gibt es hier einen zusammenhang.
@markus
läuft bei dir der hciuart.service, und/oder sollte er laufen und tut es nicht?
Zitatmit welcher karte ist es bei dir aufgetreten, markus?
ich hatte doch gar keine drin ::), sondern über den USB-Stick gebootet.
ZitatMir scheint, dass es nicht an der Hardware(Karte,Leser), sondern an der Software, also jessie, liegt.
Zitatläuft bei dir der hciuart.service, und/oder sollte er laufen und tut es nicht?
puhh, hab mal damit gespielt. Aber bem aktuellen Image :-\ laufen tun 2*hci0 und hci-attach. k.A. was das ist :-[
ZitatIch würde es nicht an jessie, sondern dem "RasPi-Kernel" die Schuld geben.
Ist der Kernel nicht in jessie "enthalten" :-[ Klär mich doch bitte über die Differenzierung näher auf.
stimmt ja, du hattest keine sd drinnen. ok.
Jessi ist eine Distribution, d.h. Kernel + Software. Wenn man pauschal also Jessi "die Schuld" gibt, dann meint man das Gesammtsystem. Also Kernel + Daemons + Anwenungssoftware + .....
Wenn man dagegen den Kernel meint .. dann ist es ein Teilsystem.
Um mal einen Vergleich zu bringen (auch wenn er Hinkt):
Wenn mein Auto einen Platten hat, sage ich auch nicht, das es am Autohersteller liegt, sondern am Reifen.
Edit:
BTW:
Linux ist eigentlich auch "nur der Kernel". Alle Userlandprogramme, wie z.B: schon die Shell (bash) sind eigentlich schon nicht mehr Linux, sondern kommen aus dem Gnu-Umfeld. Deshalb heißt es eigentlich auch "Linux Gnu" .. aber man kann sich sehr darüber streiten
https://de.wikipedia.org/wiki/Linux#Die_Bezeichnung_GNU.2FLinux (https://de.wikipedia.org/wiki/Linux#Die_Bezeichnung_GNU.2FLinux)
Danke. Dann meinten wir quasi das Gleiche und Du hast es noch etwas deutlicher eingegrenzt. ;)
Naja ... der Kernel vom "Team Debian" ist von der "Firma RasPi" verändert worden. Schließlich installiert man auch expliziet einen "RasPi-Kernel" und kein Debian-Kernel ... ;o)
Ich hatte mich nur gestöhrt an der "pauschalen" Schuldzuweisung an einm Team, welches eventuell gar nichts dafür kann ...
Heute hat es mich dann mal wieder erwischt. Kein ssh, kein telnet, kein putty...... nur die "Textdarstellung" von fhem im Browser. Als letzten Eintrag konnte ich den disconnect meines 868CUL im Log sehen. Dieser Eintrag fehlte später im Log. War aber sicherlich nicht der CUL, sondern eher allgemein USB, USB-Hub, Spannung ? ? ? ? ?
Zum Glück konnte ich nach Stecker ziehen problemlos booten.
Und dass ich heute nach langer Zeit ein fhem-update gemacht habe, sollte auch nicht in die Ursache sein, aber wer weiß ?
Grüße Markus
Hast DU denn ausreichend:
ZitatUSB, USB-Hub, Spannun
Hi Werniemann,
mein Post war nur als Info und speziell für Frank gemeint, weil mein System bis gestern ca. 1 Monat problemlos lief. Ich bin mir ziemlich sicher, dass es bei mir an einem "Wackler" in der Kette Rpi-USBPort - Verlängerungskabel - passiver Hub-USB-devices+Verlängerung zum aktiven Hub mit einem weiteren USB-device liegt. Warum dann der Rpi(Jessie auf USB-Stick direkt an USB-Port des Rpi), und das auch nur teilweise, aussteigt, wird vermutlich ein Rätsel bleiben. Ich kann aber damit leben bzw. ein Tausch der Gerätschaften als Lösung wäre mir zu aufwändig.
Frank allerdings hat ja ähnliche Symptome. Und das, obwohl dessen System auf SD läuft.
Jetzt wollt ich grad nochmal recherchieren, weil ich im Hinterkopf hatte, dass die USB-Ports und der Kartenleser "irgendwie" eine physische/logische Verbindung haben und finde
Im Februar 2015 wurde bekannt, dass der Raspberry Pi 2 Model B abstürzt, wenn er mit einem Xenon-Blitz fotografiert wird.[113] Die Raspberry Pi Foundation bestätigte dieses Verhalten. Verursacht wird
es durch ein Bauteil (,,U16"), das für die interne Spannungsversorgung zuständig ist. Dieses erzeugt aus den 5 V des Micro-USB-Anschlusses die intern benötigten Spannungen. Dazu wurde ein Chip ohne
Gehäuse gewählt und direkt auf die Platine gelötet. Wird der Chip angeblitzt, bringt der im freiliegenden Silizium auftretende photoelektrische Effekt die Spannungsregelung aus dem Takt. Die Folge ist
eine Spannungsschwankung, die zum Absturz des Raspberry führt. Problematisch ist dabei die durch einen Xenon-Blitz oder auch einen Laserpointer hervorgerufene rapide Helligkeitsänderung und
der enorme Lichtstrom. Andere helle Lichtquellen bereiten keine Probleme. Es werden verschiedene Lösungen diskutiert, wie künftige Revisionen unempfindlich gegenüber derartigen Lichtquellen
gemacht werden können. Als einfache Lösung empfiehlt der Hersteller, das Bauteil mit einem Tropfen elektrisch nicht leitenden und lichtundurchlässigen Klebers abzudecken.[114]
Und ähnlich seltsam ist das bei mir auch. Ich gehe die Treppe runter, vorbei an meinen USB-Hubs nebst freischwingenden Kabeln und Geräten, Tür öffnen, Licht einschalten, mache etwas im Kellerraum, wo der Rpi residiert, Licht ausschalten, Tür schließen, wieder vorbei an den Hubs und merke per Zufall dann irgendwann, dass fhem nicht mehr richtig geht. Daher mein Gedanke, dass ich den "Wackler" ausgelöst habe. Und wo ich gerade so überlege, wie ich ein Signal erzeugen kann, um den genauen Zeitpunkt des Teilausfalls zu bestimmen, kommt mir in den Sinn, dass eigentlich mein "check-jammer"(keine state-Veränderung seit 30 sek am RFXTRX), ein Klingeln über die FritzBox am Dect-Telefon auslösen müsste. LAN-Verbindung steht ja noch. Tat es aber auch nicht. Schau ich also beim nächsten Teilabsturz mal nach....
Also wie gesagt, mehr ein Erfahrungsbericht als ein Hilfeersuchen ;)
Grüße Markus
pi-USBPort - Verlängerungskabel - passiver Hub-USB-devices+Verlängerung zum aktiven Hub mit einem weiteren USB-device liegt
Wie lang sind eigentlich die USB-Verlängerungskabel?
Es kann sein, das eine Störung im "Langen" Bereich von USB auch den direkt angeschlossenen USB-Stick betrifft, da im PI selber auch ein "Hub" drinsteckt. Es ist eigentlich nur ein USB-Baum. Eine Störung kann also bis zur Wurzel durchschlagen und damit auch den anderen Ast betreffen.
Ich habe z.B. eine Gembird-USB-Steckdose. Wenn diese Induktive-Lasten ausschalttet gibt es durch Induktive Spannungsspitzen ein Problem auf dem USB-Port. Dadurch erfolgt ein kompletter USB-Reset .....
hallo markus,
gut zu wissen, dass es bei dir doch noch passiert, denn bei meinem nächsten "crash" wollte ich eigentlich das booten über usb-stick probieren. das hat sich ja nun leider erstmal erledigt.
das beschriebene lichtproblem ist schon ein hammer, aber das schliesse ich bei mir aus. mein pi hat jetzt schon an unterschiedlichen plätzen gestanden, mit und ohne gehäuse, auch direkt vorm fernseher. auch war er schon ganz allein zu haus, als es passierte.
ich habe übrigens auch einen cul direkt am usb des pi, ein cul433 von busware. allerdings hat der weiterhin seinen dienst getan, soweit ich mich erinnere. intertechno fernbedienung empfangen und aktoren bei dämmerung über fhem eingeschaltet. (gerade gesehen, antwort #7 bestätigt das)
Zitatdass eigentlich mein "check-jammer"(keine state-Veränderung seit 30 sek am RFXTRX), ein Klingeln über die FritzBox am Dect-Telefon auslösen müsste.
könnte das nicht auch bedeuten, dass der rfxtrx weiterhin normal seinen dienst erledigt? so wie bei mir der cul.
wie lässt du dein dect klingeln? ich nutze bei mir das modul FB_SIP, das ich immer im hinterkopf habe, da es damals ziehmlich schwierig war, die notwendigen perlmodule zu installieren.
sollte dein rfxtrx weiterhin am usb funktionieren, so kann der eigentliche usb strang ja nicht gestört sein, sondern nur der datenzugriff über usb auf den stick. also wahrscheinlich auch der kernel, wie wernieman bei mir schon spekulierte. eventuell hängt die sdcard ja auch am internen usbhub, womit unsere konstellationen dann doch sehr ähnlich wären.
allerdings bleibt immer noch die frage nach dem auslöser.
ziehmlich seltenes, unrythmisches auftreten, das anscheinend nur von 2 personen bemerkt wurde. hmm....
wenn ich pi im zusammenhang mit usb höre, muss ich eigentlich immer sofort an netzteil/spannungsversorgung denken. bei den seltenen ereignissen denke ich aber eher an gelegentliche spannungsspitzen oder spannungseinbrüche im netz. mal schauen, an eine usv denke ich schon länger.
gruss frank
Zitatdass der rfxtrx weiterhin normal seinen dienst erledigt?
mein CUL definitiv nicht. Und der RFXTRX ? Weißt ja selber wie man in Panik gerät und so schnell wie möglich das System wieder zum laufen bringen will :-\
Zitatwie lässt du dein dect klingeln?
Ich machs über das FRITZBOX-Modul mit set Fritzbox ring ....
Zitatbei den seltenen ereignissen denke ich aber eher an gelegentliche spannungsspitzen oder spannungseinbrüche im netz.
ähnliche Gedanken hab ich auch immer, aber weniger aus dem Netz, sondern in meinem Keller durch das Einschalten der Energiesparlampe.
@Werniemann
2m (auseinandergeschnitten,durch ein Wandloch geführt und wieder zusammengezwirbelt ::)) + 1m;zwischen den Hubs 1m;am aktiven Hub 2m und angehängtem CO2-Sensor.
ZitatEs kann sein, das eine Störung im "Langen" Bereich von USB auch den direkt angeschlossenen USB-Stick betrifft, da im PI selber auch ein "Hub" drinsteckt. Es ist eigentlich nur ein USB-Baum. Eine Störung kann also bis zur Wurzel durchschlagen und damit auch den anderen Ast betreffen.
So denke ich mir das auch und dann mein Konstrukt :-[
ZitatIch habe z.B. eine Gembird-USB-Steckdose. Wenn diese Induktive-Lasten ausschalttet gibt es durch Induktive Spannungsspitzen ein Problem auf dem USB-Port. Dadurch erfolgt ein kompletter USB-Reset .....
Was es alles so an Fehlerquellen gibt ;)
Was hältst Du von dieser (laienhaften)These zum Teilausfall: Was auch immer legt die USBs lahm. Somit ist das Filesystem(USB-Stick) nicht mehr erreichbar. Alles was auf Dateien zugreifen will geht nicht mehr. Der Kernel und Perl(nebst fhem-Modulen) sind aber im RAM geladen und deshalb gibt es keinen "Vollabsturz" ?
Bin jetzt noch auf den Rpi-Watchdog gestoßen. Zumindest ließe sich damit einfach ein reboot erzwingen. Möchte aber beim nächsten mal gucken, was RFXTRX u. Fritte noch von sich geben.... ;)
Unix ist einerseits empfindlich, was den Verlust seiner root-Partition betrifft, andererseits läuft alles im RAM weiter. Hatte berufsmäßig einen Rechner, wo wir durch Log/Backup/Monitoring-Server im Nachhinein feststellen konnten, das 3 Monate lang die HDD kaputt war (Genauer 2 im Raid 1 Verbund). Diese 3 Monate lief er noch super, bis der RAM "voll" war ...
Wegen USB:
Genau aus dem Grunde bin ich (persöhnlich) gegen Verwendung von USB-Datenträgern für root (/). Bei Ausfall von / ist meistens der Rechner noch pingbar, aber ein einloggen nicht möglich, da dafür auf diverse Files (lesend) zugegriffen werden muss. Ich weiß nur nicht, in wie weit fhem noch läuft, aber eigentlich müsste es eine Zeit X es überleben ...
sooo, mal wieder diverse Abstürze bzw. Hänger in FHEM. Und heute hatte ich Geduld ein paar Sachen auszuprobieren.
Symptome: leicht verändert: kein Browserzugriff seit 11:47, letzter FHEM-log-Eintrag 11:43, letztes Datenlogging 11:47 von einem OBIS-event, SSH und putty-Zugriff problemlos, fhem-Prozess läuft mit 1,7%-3%(normal: 0,3-3% !) Last. dmesg ohne Eintrag.
keine Signalisierung über meine FritzBox, auch nicht nach abziehen des USB-RFXTRX(eigentlich hätte spätestens jetzt mein Telefon klingeln müssen, wenn fhem noch "richtig" läuft)
Mal wieder mit meinem Latein fast am Ende, versucht FHEM mit "fhem stop" zu stoppen. Kein Erfolg. Mehrfach probiert, Nix.
Also Geräte "Schuld". Erst hatte ich mein 1W am GPIO4 und den zugehörigen Prozess im Verdacht. Mal versucht diesen Prozess mit kill -9 zu stoppen: keine Chance.
Und dann kam mir mein immer verrückt spielender CO2-Sensor(alleine an aktivem USB-Hub, der an passivem USB-Hub nebst USB-Transceivern hängt) in den Sinn: Abgezogen und plötzlich klingelt mein Telefon !!! Und siehe da: nun hat sich fhem beendet mit folgenden Logeinträgen
2017.01.27 11:34:19 3: WetterKoeln: 0 result(s) retrieved
2017.01.27 12:51:16 2: co20: read failed 0 (3)
2017.01.27 12:51:16 3: FRITZBOX: set Fritzbox ring 611 10
2017.01.27 12:51:18 0: Server shutdown
2017.01.27 12:51:29 1: BlockingInformParent (BlockingStart): Can't connect to localhost:7072: IO::Socket::INET: connect: Connection refused
2017.01.27 12:51:29 1: BlockingInformParent (FRITZBOX_Set_Cmd_Done): Can't connect to localhost:7072: IO::Socket::INET: connect: Connection refused
fhem hat einen sauberen shutdown(incl. fhem.save) ausgeführt. Vermutlich das Resultat von vorher nicht funktionierenden, aber noch in irgendeiner Befehlsqueue hängenden "fhem stop" ? FHEM Neustart und alles OK.
@Frank: Hast Du auch den (Voltcraft-USB-CO2-Sensor) ?
@Werniemann: Meinst Du, dass es sich um die selbe Fehlerursache, nun aber mit anderen Symptomen handelt, sprich dieser (grundsätzlich undurchschaubare) CO2-Stick den USB-Hub wuschig macht ?
Beim nächsten mal werd ich als erstes den Stick ziehen und gucken, was dann passiert ;D
Grüße Markus
Wenn der Stick , wie alle alten Module, blocking-Zugriffe verwendet ... da hört es sich danach an.
Mit welchem Modul gehst DU denn an den Stick?
Wegen Fehlersuche, gehe mal, bei Problemen, wie folgt vor:
https://forum.fhem.de/index.php/topic,54271.msg467373.html#msg467373 (https://forum.fhem.de/index.php/topic,54271.msg467373.html#msg467373)
Das ging ja flott.
Mit dem 38_CO20.pm. 41-Seiten-Thread https://forum.fhem.de/index.php/topic,13166.0.html
Das Handling erfolgt nicht(so wie ich es sonst kenne) über DEVIO, sondern:
CO20_Connect($)
{
my ($hash) = @_;
my $name = $hash->{NAME};
return undef if( AttrVal($name, "disable", 0 ) == 1 );
$hash->{USB} = Device::USB->new() if( !$hash->{USB} );
if( $hash->{ID} =~ m/(\d.*):(\d.*)/ ) {
my $dirname = $1;
my $filename = $2;
delete $hash->{DEV};
foreach my $bus ($hash->{USB}->list_busses()) {
next if( $bus->{dirname} != $dirname );
foreach my $device (@{$bus->{devices}}) {
next if( $device->idVendor() != $VENDOR );
next if( $device->idProduct() != $PRODUCT );
next if( $device->{filename} != $filename );
$hash->{DEV} = $device;
last;
}
last if( $hash->{DEV} );
}
} else {
$hash->{DEV} = $hash->{USB}->find_device( $VENDOR, $PRODUCT );
}
if( $hash->{DEV} ) {
$hash->{STATE} = "found";
Log3 $name, 3, "$name: CO20 device found";
$hash->{DEV}->open();
$hash->{manufacturer} = $hash->{DEV}->manufacturer();
$hash->{product} = $hash->{DEV}->product();
if( $hash->{manufacturer} && $hash->{product} ) {
$hash->{DEV}->detach_kernel_driver_np(0) if( $hash->{DEV}->get_driver_np(0) );
my $ret = $hash->{DEV}->claim_interface( 0 );
if( $ret == -16 ) {
$hash->{STATE} = "waiting";
Log3 $name, 3, "$name: waiting for CO20 device";
return;
} elsif( $ret != 0 ) {
Log3 $name, 3, "$name: failed to claim CO20 device";
CO20_Disconnect($hash);
}
$hash->{STATE} = "opened";
Log3 $name, 3, "$name: CO20 device opened";
my $interval = AttrVal($name, "interval", 0);
$interval = 60*5 if( !$interval );
$hash->{INTERVAL} = $interval;
RemoveInternalTimer($hash);
InternalTimer(gettimeofday()+10, "CO20_poll", $hash, 0);
my $buf;
$hash->{DEV}->interrupt_read(0x00000081, $buf, 0x0000010, 1000);
} else {
Log3 $name, 3, "$name: failed to open CO20 device";
CO20_Disconnect($hash);
}
} else {
Log3 $name, 3, "$name: filed to find CO20 device";
}
}
und das pollende auslesen über einen internal_timer:
CO20_poll($)
{
my ($hash) = @_;
my $name = $hash->{NAME};
if(!$hash->{LOCAL}) {
RemoveInternalTimer($hash);
InternalTimer(gettimeofday()+$hash->{INTERVAL}, "CO20_poll", $hash, 0);
}
if($hash->{BLOCKED}) {
return undef;
}
if( $hash->{manufacturer} && $hash->{product} ) {
my $buf = "@".sprintf("%c",$hash->{seq2})."TRF?\n@@@@@@@@@";
Log3 $name, 5, "$name: sent $buf / ".ord(substr($buf,0,1));
my $ret = $hash->{DEV}->interrupt_write(0x00000002, $buf, 0x0000010, $hash->{timeout});
if( $ret != 16 ) {
my $ret2 = $hash->{DEV}->interrupt_write(0x00000002, "@@@@@@@@@@@@@@@@", 0x0000010, $hash->{timeout});
$hash->{fail} = $hash->{fail}+1;
Log3 $name, 4, "$name: write error $ret/$ret2 ($hash->{fail})";
RemoveInternalTimer($hash);
InternalTimer(gettimeofday()+30, "CO20_poll", $hash, 1);
if($hash->{fail} >= $hash->{retries}) {
$hash->{fail} = 0;
CO20_Disconnect($hash);
$hash->{RECONNECT} = 1;
CO20_Connect($hash);
}
return undef;
}
if ($hash->{seq2} < 0xFF){ $hash->{seq2}++} else {$hash->{seq2} = 0x67};
my $data="";
for( $a = 1; $a <= 3; $a = $a + 1 ){
$ret=$hash->{DEV}->interrupt_read(0x00000081, $buf, 0x0000010, $hash->{timeout});
if( $ret != 16 and $ret != 0 ) {
Log3 $name, 4, "$name: read error $ret";
}
$data.=$buf;
}
........
Wenn jemand mich mit Ideen zu sinnvolleren Stick-Handling(wo finde ich list_busses oder interrupt_read ?) versorgt, baue ich das Modul gerne auf "FHEM-Erfordernisse" um(bzw. stimme mich mit dem Modul-Maintainer dazu ab).
Zitat@Frank: Hast Du auch den (Voltcraft-USB-CO2-Sensor) ?
nein, am usb habe ich nur einen normalen busware-cul, der auch im fehlerfall perfekt funktioniert.
hi markus,
meiner läuft jetzt seit ca. 8 wochen problemlos. nach dem letzten crash hatte ich apt-get update/upgrade gemacht. vielleicht wurde ja hier etwas entscheidendes verbessert.
kernel: Linux version 4.4.38-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #938 SMP Thu Dec 15 15:22:21 GMT 2016
gibt es für deine usb boot version auch neuerungen?
Hi Frank,
möglich ist das ja. Mein letztes update/upgrade hatte ich glaub ich um den 30.11. rum gemacht, als ich Probleme hatte.
Seit 27.1. läufts bei mir auch wieder problemlos. Mögliche Fehlerquellen: CO2-Stick, generell USB(vielleicht Wackelkontakt), OneWire(hatte da auch mal Problemchen, die auch an einer etwas wackligen Verdrahtung lagen).
Ich bin sicher, wir schreiben uns wieder
Grüße Markus
recht behalten >:( heute war es mal wieder soweit. kein telnet, ssh, fhem nur als nicht funktioniernde Textversion.
zwischendurch auch update/upgrades gemacht.
Bei Dir Frank keine Ausfälle im neuen Jahr ?
Zitat von: KölnSolar am 07 April 2017, 22:25:41
Bei Dir Frank keine Ausfälle im neuen Jahr ?
wahrscheinlich 1 mal mitte märz.
da ich nachts nach einer reise probleme mit fhem bemerkte, hatte ich aber keine lust das näher zu untersuchen, also reboot. alle logs machten aber während meiner abwesenheit ein paar tage pause bis zum reboot.
als nächstes werde ich wohl eine usv besorgen, um spannungsprobleme auszuschliessen.
Hallo frank,
Jahre später.. ;) neue Erkenntnisse.
In letzter Zeit hatte ich wieder alle paar Wochen Abstürze. Zwischenzeitlich den RPi3 auf Stretch upgedated, hatte ich das neue Problem, dass das Syslog mit dwc_otg-Meldungen überflutet und nicht lesbar war :'( Abstürze wurden per Rpi-watchdog abgefangen.
Am Sa. wollte der Rpi alle paar Std. nicht mehr. Zu den dwc_otg fand ich nun etwas im Inet. Das bewegte mich mal wieder ein Rpi-Update zu machen. Tatsächlich hatte ich endlich wieder ein sauberes Syslog. ;D Die Abstürze blieben :'( Jetzt sah ich ab u. zu Voltage-Unterschreitungen(scheint neu im OS zu sein). Dann hab ich meine "fliegende" Verkabelung verbessert. Nix. Am aktiven Hub installiert. keine Veränderung. In WinSCP sah ich, dass kurz vor dem Absturz das Filesystem nicht mehr verfügbar war. Schließlich bin ich nach Jahren des USB-Boot zurück auf SD: Läuft wie am Schnürchen. Vorher hatte ich so 10 freezes(ermittelt über freezemon) je Stunde. Vergangene Nacht keinen einzigen !!! keine undervoltages mehr.
Fazit: Der USB-Stick zwang den PI immer in die Knie. Ich nehme an, dass er Zuviel Strom zog. Aktuell immer mehr/öfter(Stick defekt ?). Ich werde sicherlich wieder auf (neuen) USB umsteigen und berichten.
Grüße Markus
Mal Ehrlich:
In guten SDCard werden bessere Speicher verbaut, als in den USB-Sticks.
hallo markus,
die undervoltage warnungen hören sich interessant an.
vielleicht mal ein grund endlich von jessie auf stretch wechseln.
nach mehreren standortwechseln, diversen jessie updates und umstieg auf ein altes lankabel anstatt wlan lief mein pi dann lange zeit sehr unauffällig und zuverlässig.
seit vielleicht 6 monaten habe ich mir nun aber ein speicherleck eingefangen.
irgendwie wird es ja mit einem pi nie langweilig. da hatte ich beim umstieg von fritzbox eigentlich mehr ruhe erwartet.
gruss frank
Hi Frank,
Zitatdie undervoltage warnungen hören sich interessant an.
vielleicht mal ein grund endlich von jessie auf stretch wechseln.
Das solltest Du definitiv machen. Damit hört dann auch endlich auf, dass wir immer u. immer wieder die Schwachstelle Stromversorgung des Rpi thematisieren müssen.
Ich hab dann natürlich zwischenzeitlich einen weiteren uralten USB-Stick eingesetzt. Keine undervoltages mehr. Keine Abstürze. Es lag also definitiv an dem ururalten USB-Stick.
ZitatMal Ehrlich:
In guten SDCard werden bessere Speicher verbaut, als in den USB-Sticks.
Ich kenne ja Deine Meinung dazu. Ich glaube von Dir stammt auch die Äußerung, dass in USB-Sticks nur Abfälle aus der SD-Kartenproduktion eingesetzt würden. Mich wundert allerdings, dass man dieses Meinungsbild sonst nirgends im Inet findet. Umgekehrt wird eher zu USB geraten(allerdings ohne eine nachvollziehbare Begründung).
Was mir bis jetzt aufgefallen ist:
- Trotz vieler Abstürze war nie etwas am Dateisystem beschädigt. Glück oder vielleicht doch ein Vorteil des USB-Sticks ? :-\
- Zumindest unter Windows kann ich höhere und vor allen Dingen stabilere Schreib-/Lesegeschwindigkeiten bei USB vs. SD feststellen
- mit USB scheint es mehr freezes zu geben. Allerdings habe ich eben auch nur Jahrzehnte alte USB-Sticks und die SD's sind neu. Das teste ich weiter aus.
Vorteil beim USB-Stick sehe ich auch darin, dass über einen aktiven USB-Hub die Stromversorgung sichergestellt ist. Wer weiß schon, was beim Rpi mit dem SD-Reader bei Spannungsspitzen im Netz oder zig stromziehenden Gerätschaften am Rpi etc. passiert.
Grüße Markus
ZitatMich wundert allerdings, dass man dieses Meinungsbild sonst nirgends im Inet findet.
Dann schau z.B. bei heise nach ;o)
Ist natürlich nicht Grundsätzlich so. Es gibt auch supergute USB-Sticks. Diese zu kriegen ist aber nicht einfach ...
Der Nachteil von USB beim Pi ist, das wirklich (fast) alles über USB angebunden ist. Ein Reset des Busses ist damit ....