Hallo Zusammen,
ich habe mein System neu aufgesetzt und die Config wieder eingespielt. Nun musste ich jedoch feststellen dass FHEM viele Geräte bei denen ich in der Device DEF den DNS-Namen statt der IP verwendet habe, nicht mehr erreichen kann. Anfangs ging es noch mit ein paar Geräten und mittlerweile findet FHEM keins mehr und ich musste alle auf IP umstellen.
Zusätzlich hängt sich mein komplettes System nach der Umstellung auf SSD per SATA regelmäßig auf. Ich kann dann stellenweise nicht mal mehr einen Shutdown per Putty ausführen oder per WinSCP die Logfiles anschauen. Erst dachte ich, es läge an der HDD. Also habe ich alles nochmal neu aufgesetzt und diesmal auf eine SSD installiert. Die Probleme sind jedoch die Gleichen. :-\
Hat jemand Erfahrung oder eine Idee?
Vielen Dank schon mal und beste Grüße
was sagen denn die Logs zu den Ausfällen. Was sagt nslookup SERVERNAME zu Deinem DNS Problem? Was steht in der /etc/resolve.conf als nameserver und search Domäne drin?
Hi CoolTux,
habe jetzt mal nslookup ausgeführt.
nslookup LEDController
ergibt:
Server: 192.168.152.1
Address: 192.168.152.1#53
Name: LEDController.fritz.box
Address: 192.168.152.28
nslookup LGwebOSTV
ergibt:
Server: 192.168.152.1
Address: 192.168.152.1#53
Name: LGwebOSTV.fritz.box
Address: 192.168.152.69
In der /etc/resolve.conf steht:
nameserver 8.8.8.8
nameserver 192.168.152.1
search fritz.box
Kannst du damit was anfangen? :)
VG, Thomas
Sagt mir das Dein fhem Server die FQDN's auflösen kann. Soweit alles ok. Wieso das aus FHEM heraus nicht klappen soll ist mir ein Rätsel.
Die 8.8.8.8 kannst im übrigen rausnehmen. Die Fritzbox alleine als DNS passt schon.
Du kannst im global Device von FHEM ja mal Deine Fritzbox als DNS eintragen. Gibt da so ein Attribut, irgendwas mit DNS
Hi CoolTux,
habe ich probiert - sowohl mit DNS-Namen der FritzBox als auch die IP. Hilft beides nicht. TV nicht erreichbar. Sobald ich dann aber die IP in meinem LGTV_WebOS Device eintrage, funktioniert die Kommunikation mit dem TV wieder.
Kann es sein dass ich irgendein Perl-Modul dafür brauche damit es aus FHEM heraus damit klappt?
Wobei es bei meiner HUE-Bridge komischerweise funktioniert.
Die ist so definiert:
defmod hueBridge1 HUEBridge
VG, Thomas
Was steht denn im FHEM Log drin wenn es nicht geht. Mir ist da nichts bekannt mit einem Perl Modul.
Was ist denn wenn Du genau das
LGwebOSTV.fritz.box
ein trägst
Dann funktioniert es auch nicht. Aber ich weiß dass es auch nach meiner Neuinstallation anfangs funktioniert hatte.
Stück für Stück sind mir dann die Geräte nicht mehr per DNS erreichbar gewesen und liefen dann erst wieder mit der IP.
Hast Du die 8.8.8.8 schon aus der resolv.conf rausgenommen?
Ich bekomme da nämlich:
Zitat> nslookup LGwebOSTV 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
** server can't find LGwebOSTV: NXDOMAIN
Mach mal ping lgtvblabla
Und nimm den Google Nameserver raus.
Guten Morgen Zusammen,
Ping auf den TV liefert: Name or Service not found.
Den google Namensserver habe ich jetzt mal rausgenommen und dann funktioniert es. :)
Allerdings ist der Eintrag nach Systemneustart wieder drin.
Soll ich den Eintrag aus der /etc/network/interfaces.d/* (siehe Screenshot) löschen?
VG, Thomas
Da ist er ja schon auskommentiert. Den Nameserver bekommt er entweder über DHCP vom DHCP Server zugewiesen oder hier rüber (https://wiki.archlinux.de/title/Systemd/systemd-resolved).
ZitatDen Nameserver bekommt er entweder über DHCP vom DHCP Server zugewiesen oder hier rüber.
Hi CoolTux, da ist auch alles auskommentiert. Es muss also noch irgendwo einen Punkt geben wo er das her holt.
# This file is part of systemd.
#
# systemd is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as published by
# the Free Software Foundation; either version 2.1 of the License, or
# (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See resolved.conf(5) for details
[Resolve]
#DNS=
#FallbackDNS=8.8.8.8 8.8.4.4 2001:4860:4860::8888 2001:4860:4860::8844
#Domains=
#LLMNR=yes
#DNSSEC=no
#Cache=yes
#DNSStubListener=udp
VG, Thomas
Dann mach mal ein grep -R "8.8.8.8" /etc/
Ich vermute, es kommt vom dhcp-Server.
Kann man mit
dhclient -v
prüfen, ob da als Antwort die 8.8.8.8 mit dabei ist.
Um die DHCP-Nameserver zu ignorieren und statisch konfigurierte zu nutzen, klingt das hier hilfreich:
https://unix.stackexchange.com/questions/174349/what-overwrites-etc-resolv-conf-on-every-boot/174356#174356 (https://unix.stackexchange.com/questions/174349/what-overwrites-etc-resolv-conf-on-every-boot/174356#174356)
Guten Abend Zusammen,
@CoolTux: leider hat deine Lösung auch nicht geholfen.
@Happy Fhem User: Dein Befehl liefert mir folgendes Ergebnis:
Internet Systems Consortium DHCP Client 4.3.5
Copyright 2004-2016 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/bond0/3a:99:76:56:c6:6e
Sending on LPF/bond0/3a:99:76:56:c6:6e
Listening on LPF/eth0/02:d2:08:c0:e1:c7
Sending on LPF/eth0/02:d2:08:c0:e1:c7
Sending on Socket/fallback
DHCPDISCOVER on bond0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
DHCPREQUEST of 192.168.152.54 on eth0 to 255.255.255.255 port 67
DHCPOFFER of 192.168.152.54 from 192.168.152.1
DHCPACK of 192.168.152.54 from 192.168.152.1
RTNETLINK answers: File exists
Warning: systemd-timesyncd.service changed on disk. Run 'systemctl daemon-reload' to reload units.
bound to 192.168.152.54 -- renewal in 382595 seconds.
fhem@bananapi:~$
VG, Thomas
Ich habe jetzt nochmal dnsmasq installiert und nach der Anleitung von dieser Seite konfiguriert:
https://forum.ubuntuusers.de/topic/dnsmasq-namensserver-hinzufuegen/
Aber auch das hilft nicht. Selbst wenn ich dort unter /etc/resolvconf/resolv.conf.d/base die IP der FritzBox als Nameserver eintrage.
Vermutlich muss ich das Thema abhaken und weiter mit den IP Adressen leben.
Trotzdem nochmal vielen Dank für eure Hilfe.
Hallo Thomas,
mir sind ein paar Dinge aufgefallen. Wenn deine Fritzbox dhcp macht, brauchst du auf deinem Armbian keinen dnsmasq. Dieser sollte die nötigen Infos per DHCP verpasst bekommen und DNS etc. der Fritzbox nutzen. Weiterhin gehe ich davon aus, dass du keine Bündelung benötigst (bound0), da dein Server bestimmt bloß eine Netzwerkkarte hat. Deinstalliere alles, was du nicht benötigst. Dein Linux schreit auch nach einem 'systemctl daemon-reload', also tu ihm den Gefallen und führe den Befehl aus. Zur Sicherheit deaktiviere auch noch den DHCP6-Server in der Fritzbox, falls dieser aktiv ist.
Gruß Jens
Hallo dirigent,
habe dnsmasq jetzt wieder deinstalliert, in der FritzBox den DHCP6-Server deaktiviert und systemctl daemon-reload ausgeführt.
Aber wenn ich ein Gerät in meinem Netzwerk anhand des Namens anpingen möchte, bekomme ich immer noch die Meldung dass der Name oder Dienst nicht bekannt ist.
Externer ping von irgendwelchen Webseiten funktioniert hingegen perfekt.
VG, Thomas
Wie sieht ifconfig und route aus? Hast du versucht, die Adressen mal in /etc/hosts einzutragen?
ZitatWie sieht ifconfig und route aus? Hast du versucht, die Adressen mal in /etc/hosts einzutragen?
Habe das mal als Screenshot angehängt.
In meiner Hosts steht folgendes (letzter Eintrag von mir):
127.0.0.1 localhost bananapi
::1 localhost bananapi ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
192.168.152.1 fritz.box
VG, Thomas
Trag mal in /etc/hosts folgendes ein
192.168.152.28 LEDController
und versuche einen weiteren Ping. Deaktiviere temporär IPv6 durch den folgenden Befehl auf der Linuxkonsole
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
ZitatTrag mal in /etc/hosts folgendes ein
Okay cool das funktioniert jetzt schon mal. :)
Das wäre eine Notlösung. Aber eig. möchte ich nicht unbedingt alle meine Geräte dort manuell eintragen. Weil dann könnte ich ja auch gleich bei der IP bleiben.
Du hast doch da jetzt sicher noch eine Lösung für mich...? ;)
Jetzt nicht aber "morgen". Gute Nacht.
Gruß Jens
Hallo Thomas,
zuerst solltest du auf der Fritzbox den DHCP-Server prüfen. Wo befindet sich der Leasebereich, wird der DNS-Server dynamisch aktualisiert?
Dann vergebe den FHEM-Server eine statische Adresse außerhalb des Lease-Bereichs. Trage die DNS-Infos und natürlich das Gateway in die Datei /etc/network/interfaces ein.
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 192.168.152.254
netmask 255.255.255.0
broadcast 192.168.152.255
gateway 192.168.152.1
dns-nameservers 192.168.152.1
dns-search fritz.box
Dann ändere die Datei /etc/hosts
127.0.0.1 localhost
192.168.152.254 bananapi
In der Datei /etc/resolv.conf sollte folgendes stehen:nameserver 192.168.152.1
domain fritz.box
search fritz.box
Gruß Jens
PS: Ich gehe davon aus, dass in der Datei /etc/hostname bananapi steht.
PPS: Neustart nicht vergessen.
Hi Jens,
das war irgendwie nichts. Jetzt ist mein System per SSH gar nicht mehr erreichbar. Weder unter der alten noch unter der neuen IP, noch unter dem DNS-Namen.
Habe alles so gemacht wie du gesagt hast, bis auf die Anpassung der /etc/resolv.conf, da die Anpassung nach dem Neustart sowieso immer wieder weg ist.
VG, Thomas
Na dann häng mal einen Monitor dran und schau in die syslog. Gruß Jens
Habe jetzt auch mal die FritzBox neu gestartet und anschließend den Pi mit nem Hardreset. Jetzt bin ich wieder drauf. :)
Aber ein
ping LEDController
liefert immer noch
ping: LEDController: Der Name oder der Dienst ist nicht bekannt
VG, Thomas
echo 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
nslookup LEDController
route -n
ping -I 192.168.152.254 LEDController
ping -I 192.168.152.254 LEDController.fritz.box
Zitatecho 1 > /proc/sys/net/ipv6/conf/all/disable_ipv6
habe ich ausgeführt.
Aber nslookup liefert wieder den google namensserver
fhem@bananapi:~$ nslookup LEDController
Server: 8.8.8.8
Address: 8.8.8.8#53
** server can't find LEDController: NXDOMAIN
fhem@bananapi:~$
fhem@bananapi:~$ ping -I 192.168.152.254 LEDController
ping: LEDController: Der Name oder der Dienst ist nicht bekannt
fhem@bananapi:~$ ping -I 192.168.152.254 LEDController.fritz.box
ping: LEDController.fritz.box: Der Name oder der Dienst ist nicht bekannt
fhem@bananapi:~$
VG, Thomas
nslookup LEDController 192.168.152.1
Das liefert folgendes Ergebnis:
fhem@bananapi:~$ nslookup LEDController 192.168.152.1
Server: 192.168.152.1
Address: 192.168.152.1#53
Name: LEDController
Address: 192.168.152.28
fhem@bananapi:~$
Also sind wir schon mal einen kleinen Schritt weiter. :)
Zitat von: dirigent am 25 Februar 2018, 10:51:35
In der Datei /etc/resolv.conf sollte folgendes stehen:nameserver 192.168.152.1
domain fritz.box
search fritz.box
Ich kann diese Datei aber nicht anpassen.
Das ist noch einem Neustart immer wieder raus.
Die Datei ist ein Link auf /run/resolvconf/resolv.conf[/tt
Aber auch wenn ich es darin anpasse, bleibt das nach einem Neustart nicht bestehen.
VG, Thomas
Als root solltest du das können. sudo mcedit /etc/resolv.confNatürlich kann noch in irgendeinem up-Script der Google-DNS stehen.sudo grep -R 8.8.8.8 /etc
Ich hatte es als root über WinSCP editiert.
Aber auch wenn ich es direkt über die Console editiere, wurde es nach einem Neustart nicht übernommen.
Nun habe ich die gleichen Daten in /etc/resolvconf/resolv.conf.d/base und /etc/resolvconf/resolv.conf.d/head eingetragen und dort die google namensserver rausgeschmissen.
Jetzt funktioniert es endlich auch mit:
ping LEDController
:)
Vielen Dank!
Jedoch habe ich nun ein Problem dass Putty ab und an die Verbindung verliert. :o
Weiß nicht ob das jetzt mit der Umstellung auf die statische IP zusammenhängt oder so.
Muss das mal beobachten.
dpkg-reconfigure ssh
Gruß Jens
Irgendwie ist der Service nicht als Paket installiert.
fhem@bananapi:~$ sudo dpkg-reconfigure ssh
dpkg-query: Paket »ssh« ist nicht installiert und es ist keine Information verfügbar
Verwenden Sie dpkg --info (= dpkg-deb --info) zum Untersuchen von Archiven
und dpkg --contents (= dpkg-deb --contents) zum Auflisten ihres Inhalts.
/usr/sbin/dpkg-reconfigure: ssh ist nicht installiert
fhem@bananapi:~$
VG, Thomas
dpkg-reconfigure openssh-server
Okay, das hat funktioniert.
Es wird zwar keine Ausgabe zurück geliefert, aber zumindest auch kein Fehler. :)
Werde mal beobachten ob die Verbindung jetzt wieder stabil bleibt.
Vielen Dank für dein Hilfe, Jens. :)
Leider habe ich immer noch das Problem dass der Pi ab und an nicht per Putty erreichbar ist. Das kommt sogar extrem häufig vor (alle paar Minuten). Dann heißt es warten und nach 30 Sekunden ca. komme ich wieder per HTTP (Weboberfläche) und SSH drauf. Per IP kann ich ihn in der Zeit aber anpingen.
Interessanterweise wenn ich von meinem Laptop aus
ping bananapi
aufrufe, versucht er noch zur alten IP aufzulösen statt zu der neuen. Obwohl die neue auch in der FritzBox korrekt angezeigt wird und ich diese neu gebootet habe.
VG, Thomas
ipconfig /flushdns
Gruß Jens
Hat leider nicht geholfen.
C:\Users\ToM_ToM>ipconfig /flushdns
Windows-IP-Konfiguration
Der DNS-Auflösungscache wurde geleert.
C:\Users\ToM_ToM>ping bananapi
Ping wird ausgeführt für bananapi.fritz.box [192.168.152.54] mit 32 Bytes Daten:
Antwort von 192.168.152.70: Zielhost nicht erreichbar.
Antwort von 192.168.152.70: Zielhost nicht erreichbar.
Antwort von 192.168.152.70: Zielhost nicht erreichbar.
Antwort von 192.168.152.70: Zielhost nicht erreichbar.
Ping-Statistik für 192.168.152.54:
Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
(0% Verlust),
C:\Users\ToM_ToM>
nslookup bananapi.fritz.box 192.168.152.1
Guten Morgen Jens
C:\Users\ToM_ToM>nslookup bananapi.fritz.box 192.168.152.1
Server: fritz.box
Address: 192.168.152.1
DNS request timed out.
timeout was 2 seconds.
Name: bananapi.fritz.box
Address: 192.168.152.54
C:\Users\ToM_ToM>
Da mein Pi mehr "nicht erreichbar" ist als "erreichbar", werde ich wohl wieder zur dynamischen IP zurückgehen müssen.
Es sei denn, du hast noch irgendwie eine Idee für mich. Aktuell läuft nämlich meine gesamte Automatisierung nur noch sporadisch.
VG, Thomas
Kleine Fragte: Ist der Pi per WLAN erreichbar?
Kenne solche Berichte genau in dem Zusammenhang ... und Du solltest IPv6 dauerhaft deaktivieren
https://www.thomas-krenn.com/de/wiki/IPv6_deaktivieren (https://www.thomas-krenn.com/de/wiki/IPv6_deaktivieren)
ZitatKleine Fragte: Ist der Pi per WLAN erreichbar?
Nein, der hängt nur am LAN. IPV6 hatte ich an der FritzBox auch deaktiviert.
VG, Thomas
Ah... ich glaube, ich bin gerade einen entscheidenen Schritt weiter gekommen. :)
Hatte mich jetzt mal per VPN verbunden und gesehen dass mir dann der Bananapi in der Übersicht der bekannten Geräte mit der alten IP-Adresse angezeigt wird.
Nun habe ich diesen dort gelöscht und wollte ihn neu hinzufügen und dann kommt die Meldung dass die IP mit der 254 am Ende bereits dem Fritz NAS-Server zugewiesen ist.
Demnach lag es wohl die ganze Zeit an einem IP-Konflikt. Jetzt werde ich heute Abend nochmal die IP des PIs ändern und dann mal weiterschauen.
VG, Thomas
So, gerade von der Arbeit heimgekommen und festgestellt dass der Pi wieder nicht erreichbar war. >:(
Also Monitor angebaut und feststellen müssen dass der wieder komplett aufgehängt war da der Grafikchip nichts ausgegeben hat.
Irgendwas ist dort faul an dem System.
Habe jetzt mal den kompletten Pi getauscht. Vielleicht hat der Alte einfach ein Ding weg.
Im FHEM-Log finden sich aber viele solcher Einträge:
ping: sendmsg: Kein Hauptspeicher für den Puffer verfügbar
Kann es sein dass da irgendein Modul meinen RAM ausreizt?
wie aktuell ist das Gerät?
Gab ansonsten hier im Forum schon2 Thread zum Memory-Verbrauch bei aktuellem PIs. Vor allem wenn apptime verwendet wurde ....
Zitatwie aktuell ist das Gerät?
BananaPi mit akuteller Armbian-Version - alles aktualisiert
Die letzten Einträge des syslog deuten irgendwie darauf hin dass der intern irgendwie die Prozesse neu gestartet hat.
Feb 28 15:17:07 bananapi kernel: [ 0.000000] Booting Linux on physical CPU 0x0
Feb 28 15:17:07 bananapi systemd-modules-load[211]: Inserted module 'brcmfmac'
Feb 28 15:17:07 bananapi kernel: [ 0.000000] Linux version 4.14.18-sunxi (root@xeon) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #24 SMP Fri Feb 9 16:24:32 CET 2018
Feb 28 15:17:07 bananapi kernel: [ 0.000000] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=50c5387d
Feb 28 15:17:07 bananapi kernel: [ 0.000000] CPU: div instructions available: patching division code
Feb 28 15:17:07 bananapi kernel: [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Feb 28 15:17:07 bananapi kernel: [ 0.000000] OF: fdt: Machine model: LeMaker Banana Pi
Feb 28 15:17:07 bananapi kernel: [ 0.000000] Memory policy: Data cache writealloc
Feb 28 15:17:07 bananapi kernel: [ 0.000000] cma: Reserved 128 MiB at 0x77800000
Feb 28 15:17:07 bananapi kernel: [ 0.000000] On node 0 totalpages: 260119
Feb 28 15:17:07 bananapi kernel: [ 0.000000] free_area_init_node: node 0, pgdat c0dd8b00, node_mem_map ef703000
Feb 28 15:17:07 bananapi systemd-modules-load[211]: Inserted module 'bonding'
Feb 28 15:17:07 bananapi kernel: [ 0.000000] Normal zone: 1728 pages used for memmap
Feb 28 15:17:07 bananapi kernel: [ 0.000000] Normal zone: 0 pages reserved
Feb 28 15:17:07 bananapi kernel: [ 0.000000] Normal zone: 196608 pages, LIFO batch:31
Feb 28 15:17:07 bananapi systemd-udevd[266]: Invalid rule /etc/udev/rules.d/z60_usbmount.rules:3: unknown key 'BUS'
Feb 28 15:17:07 bananapi kernel: [ 0.000000] HighMem zone: 63511 pages, LIFO batch:15
Feb 28 15:17:07 bananapi kernel: [ 0.000000] psci: probing for conduit method from DT.
Feb 28 15:17:07 bananapi kernel: [ 0.000000] psci: Using PSCI v0.1 Function IDs from DT
Feb 28 15:17:07 bananapi kernel: [ 0.000000] random: fast init done
...
Feb 28 15:17:12 bananapi systemd[1]: Started Getty on tty1.
Feb 28 15:17:12 bananapi systemd[1]: Started Serial Getty on ttyS0.
Feb 28 15:17:12 bananapi systemd[1]: Reached target Login Prompts.
Feb 28 15:17:12 bananapi kernel: [ 22.201098] random: crng init done
Feb 28 15:17:12 bananapi ntpd[803]: ntpd 4.2.8p10@1.3728-o Sat Sep 23 21:50:14 UTC 2017 (1): Starting
Feb 28 15:17:12 bananapi ntpd[803]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:110
Feb 28 15:17:12 bananapi ntp[756]: Starting NTP server: ntpd.
Feb 28 15:17:12 bananapi systemd[1]: Started LSB: Start NTP daemon.
Feb 28 15:17:12 bananapi ntpd[813]: proto: precision = 1.125 usec (-20)
Feb 28 15:17:12 bananapi ntpd[813]: Listen and drop on 0 v6wildcard [::]:123
Feb 28 15:17:12 bananapi ntpd[813]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Feb 28 15:17:12 bananapi ntpd[813]: Listen normally on 2 lo 127.0.0.1:123
Feb 28 15:17:12 bananapi ntpd[813]: Listen normally on 3 eth0 192.168.152.250:123
Feb 28 15:17:12 bananapi ntpd[813]: Listen normally on 4 lo [::1]:123
Feb 28 15:17:12 bananapi ntpd[813]: Listen normally on 5 eth0 [2a02:8071:8a7:fd00:9:4ff:fe80:e0fc]:123
Feb 28 15:17:12 bananapi ntpd[813]: Listen normally on 6 eth0 [fe80::9:4ff:fe80:e0fc%2]:123
Feb 28 15:17:12 bananapi ntpd[813]: Listening on routing socket on fd #23 for interface updates
Feb 28 15:17:13 bananapi systemd[1]: Started Samba NMB Daemon.
Feb 28 15:17:13 bananapi systemd[1]: Starting Samba SMB Daemon...
Feb 28 15:17:13 bananapi systemd[1]: Created slice User Slice of root.
Feb 28 15:17:13 bananapi systemd[1]: Started Session 2 of user root.
Feb 28 15:17:13 bananapi systemd[1]: Starting User Manager for UID 0...
Feb 28 15:17:14 bananapi ntpd[813]: Soliciting pool server 52.0.56.137
Feb 28 15:17:14 bananapi mysqld[856]: 2018-02-28 15:17:14 3063787520 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 856 ...
Feb 28 15:17:14 bananapi ntpd[813]: Soliciting pool server 66.7.96.1
Feb 28 15:17:14 bananapi ntpd[813]: Soliciting pool server 195.137.195.251
Feb 28 15:17:15 bananapi systemd[864]: Reached target Paths.
Feb 28 15:17:15 bananapi systemd[864]: Listening on GnuPG cryptographic agent (access for web browsers).
Feb 28 15:17:15 bananapi systemd[864]: Reached target Timers.
Feb 28 15:17:15 bananapi systemd[864]: Listening on GnuPG cryptographic agent and passphrase cache.
Feb 28 15:17:15 bananapi systemd[864]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
Feb 28 15:17:15 bananapi systemd[864]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
Feb 28 15:17:15 bananapi systemd[864]: Listening on GnuPG network certificate management daemon.
Feb 28 15:17:15 bananapi systemd[864]: Reached target Sockets.
Feb 28 15:17:15 bananapi systemd[864]: Reached target Basic System.
Feb 28 15:17:15 bananapi systemd[864]: Reached target Default.
Feb 28 15:17:15 bananapi systemd[864]: Startup finished in 1.431s.
Feb 28 15:17:15 bananapi systemd[1]: Started User Manager for UID 0.
Feb 28 15:17:16 bananapi ntpd[813]: Soliciting pool server 93.185.134.36
Feb 28 15:17:16 bananapi ntpd[813]: Soliciting pool server 192.146.137.13
Feb 28 15:17:16 bananapi ntpd[813]: Soliciting pool server 2a00:d5c0:10:10::100
Feb 28 15:17:16 bananapi kernel: [ 25.782501] usb 1-1.1: device descriptor read/64, error -110
Feb 28 15:17:16 bananapi kernel: [ 26.002488] usb 1-1.1: new full-speed USB device number 4 using ehci-platform
Feb 28 15:17:17 bananapi ntpd[813]: Soliciting pool server 2a04:d140::1
Feb 28 15:17:17 bananapi ntpd[813]: Soliciting pool server 176.9.1.211
Feb 28 15:17:17 bananapi ntpd[813]: Soliciting pool server 80.240.216.155
Feb 28 15:17:17 bananapi ntpd[813]: Soliciting pool server 5.34.248.224
Feb 28 15:17:17 bananapi systemd[1]: smbd.service: Supervising process 1050 which is not our child. We'll most likely not notice when it exits.
Feb 28 15:17:18 bananapi ntpd[813]: Soliciting pool server 149.210.142.45
Feb 28 15:17:18 bananapi ntpd[813]: Soliciting pool server 2001:648:2ffc:2104::2
Feb 28 15:17:18 bananapi ntpd[813]: Soliciting pool server 162.210.110.4
Feb 28 15:17:18 bananapi systemd[1]: Started Samba SMB Daemon.
Feb 28 15:17:19 bananapi ntpd[813]: Soliciting pool server 13.55.50.68
Feb 28 15:17:19 bananapi ntpd[813]: Soliciting pool server 2001:1af8:2100:b070:7::12c
Feb 28 15:17:19 bananapi systemd[1]: Started MariaDB database server.
Feb 28 15:17:19 bananapi ntpd[813]: Soliciting pool server 77.78.107.252
Feb 28 15:17:19 bananapi ntpd[813]: Soliciting pool server 45.33.84.208
Feb 28 15:17:21 bananapi kernel: [ 31.142910] usb 1-1.1: device descriptor read/64, error -110
Feb 28 15:17:21 bananapi systemd[1]: Started LSB: Armbian gathering hardware information.
Alle Einträge zu posten wäre jetzt etwas viel. Könnt ihr Linux-Gurus dort etwas herauslesen? :)
Wenn Du die Dienste Deiner Fritte nutzt (willst), wozu installierst Du dann ähnliche (Server-)Dienste auf dem Pi ???
DNS- und NTP-Server gehören auf 1 Server, nicht mehrere.
Gleiches mit Samba, wenn Du die Fritte als NAS nutzt.
Wenn man sowas nicht sauber konfiguriert, klappt das garantiert nicht.
Außerdem hast Du ein USB Problem, entweder Device selbst oder Spannungsversorgung.
Also eigentlich würden mich die Zeilen VOR dem Neustart viel mehr interessieren ...
ZitatDNS- und NTP-Server gehören auf 1 Server, nicht mehrere.
Gleiches mit Samba, wenn Du die Fritte als NAS nutzt.
Also installiert habe ich da nichts extra. Das ist alles bei Armbian standardmäßig mit drauf gewesen.
Samba habe ich installiet weil ich Daten auf den Pi schieben möchte. Sowohl die Sonos-Sprachausgaben als auch die Bilder meiner Kamera.
NAS der FritzBox habe ich deaktiviert. Aber selbst wenn ich den Dienst mal aktivieren sollte, sollte das eig. kein Problem sein. Wüsste nicht was gegen mehrere Fileserver sprechen soll.
Soll ich NTP deaktivieren? DNS konnte ich in der Liste der Services nicht finden (Screenshot anbei).
ZitatAlso eigentlich würden mich die Zeilen VOR dem Neustart viel mehr interessieren ...
Hier nochmal die Zeilen davor mit dabei. Leider gibt's da mehrere Stunden lang keine Logeinträge. Und als ich gegen 08:00 heute morgen meine Wohnung verlies, lief das System noch.
Feb 28 05:45:45 bananapi systemd[1]: Starting Daily apt download activities...
Feb 28 05:46:20 bananapi systemd[1]: Started Daily apt download activities.
Feb 28 05:46:20 bananapi systemd[1]: apt-daily.timer: Adding 5h 13min 11.281063s random time.
Feb 28 05:46:20 bananapi systemd[1]: apt-daily.timer: Adding 47min 40.137837s random time.
Feb 28 05:55:01 bananapi CRON[7887]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Feb 28 06:05:01 bananapi CRON[8386]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Feb 28 06:15:01 bananapi CRON[8890]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Feb 28 06:17:01 bananapi CRON[9003]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly)
Feb 28 06:25:01 bananapi CRON[9395]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily ))
Feb 28 06:25:01 bananapi CRON[9396]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Feb 28 15:17:07 bananapi kernel: [ 0.000000] Booting Linux on physical CPU 0x0
Feb 28 15:17:07 bananapi systemd-modules-load[211]: Inserted module 'brcmfmac'
Feb 28 15:17:07 bananapi kernel: [ 0.000000] Linux version 4.14.18-sunxi (root@xeon) (gcc version 7.2.1 20171011 (Linaro GCC 7.2-2017.11)) #24 SMP Fri Feb 9 16:24:32 CET 2018
Feb 28 15:17:07 bananapi kernel: [ 0.000000] CPU: ARMv7 Processor [410fc074] revision 4 (ARMv7), cr=50c5387d
Feb 28 15:17:07 bananapi kernel: [ 0.000000] CPU: div instructions available: patching division code
Feb 28 15:17:07 bananapi kernel: [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Feb 28 15:17:07 bananapi kernel: [ 0.000000] OF: fdt: Machine model: LeMaker Banana Pi
Feb 28 15:17:07 bananapi kernel: [ 0.000000] Memory policy: Data cache writealloc
Feb 28 15:17:07 bananapi kernel: [ 0.000000] cma: Reserved 128 MiB at 0x77800000
Feb 28 15:17:07 bananapi kernel: [ 0.000000] On node 0 totalpages: 260119
Feb 28 15:17:07 bananapi kernel: [ 0.000000] free_area_init_node: node 0, pgdat c0dd8b00, node_mem_map ef703000
VG, Thomas
Zitat von: ToM_ToM am 28 Februar 2018, 20:49:18
Also installiert habe ich da nichts extra. Das ist alles bei Armbian standardmäßig mit drauf gewesen...
Wahrscheinlich ist das der Grund, warum ich lieber ein minimal-System nehme und dann benötigte Dienste nachinstalliere.
Ich möchte wissen, was auf meinem Rechner läuft, umso einfacher kann man auch Probleme eingrenzen.
ZitatIch möchte wissen, was auf meinem Rechner läuft, umso einfacher kann man auch Probleme eingrenzen.
Da bin ich zu 100% bei dir.
Im Linux-Bereich bin ich jedoch noch nicht ganz so fit. Daher kämpfe ich mich da noch durch.
Soll ich den NTP-Service deaktivieren?
VG, Thomas
nee .. konfigurieren .. als CLient gut, als Server schlecht. Das unterscheidet sich bei ntp nur nach der Config.
Anders aber ... brauchst Du wirklich samba?
Was mir jetzt erst auffällt ... "network-manager"????????
Hast Du einen Desktop oder Server Image genommen?
Das ist ein Debian-Server-Image.
Was habt ihr denn alle gegen Samba? Kann mir das mal jemand erklären?
Zu dem "network-manager" kann ich nichts sagen. Ist wohl Standard.
VG, Thomas
Ich glaube aktuell nicht, das Networkmanager bei Debian mitlerweile standard ist .... außerdem sprachst Du von einem Armbian-Version Image. Bist Du Dir WIRKLICH sicher, das Du nicht den Desktop genommen hast? Denn da würde es "Sinn" machen ...
Samba braucht relativ viel Recourcen ... um nur mal "configs" zu bearbeiten sind gerade positiv. Zusätzlich bekommst Du, gerade bei configs, schwierigkeiten mit dem Berechtigungen ...
Also ein winscp o.A. ist deutlich angenehmer ... wenn Du unter Linux arbeitest, kannst Du auch sshfs o.A. verwenden ...
ZitatBist Du Dir WIRKLICH sicher, das Du nicht den Desktop genommen hast?
Ja klar. Den Desktop brauche ich ja nicht für meine Zwecke.
Begrüßung nach Anmeldung:
Welcome to ARMBIAN 5.38 stable Debian GNU/Linux 9 (stretch) 4.14.18-sunxiZu Samba: Ich verwende Samba ja nicht um Configs zu bearbeiten. Das mache ich alles per WinSCP. Samba dient nur dass ich mir einen Share für die Sonos-Sprachausgaben anlegen kann und zum Ablegen von Kamerafotos die von meinen Androidtablets gemacht werden.
Dad sagt leider nur, das Du armbian verwendest, nicht was es für ein Installationsmedium war. Aus "Server" kann man auch Desktop machen ...
Besser wäre eine Ausgabe von:
dpkg -l | grep X11
ZitatBesser wäre eine Ausgabe von:
Liefert nichts zurück.
DAD ist guuuud ..... also nix mit Desktop ...
Wenn Du jetzt netzwerk bearbeitest, soltest Du es mit NetworkManager tuhen. Abr .. dabei kann ich nicht helfen ...
Moin ToM_ToM,
hatte nach Wechsel auf Armbian mit meinem BPI auch Probleme. ( War unregelmäßig nicht erreichbar )
Erst der Wechsel auf ein neues 5V 12Watt Netzteil hat geholfen. Das System läuft wieder stabil.
Viele Grüße
Sunny
Hi Sunny,
ich verwende das original Raspberry Netzteil (2,5A). Das sollte eig. stark genug sein. Bei meinen Eltern betreibe ich die Banane nur mit nem alten Handynetzteil das gerade mal 500 mA schafft und da läuft die Kiste seit jahren stabil. Es verreckt nur einmal im Jahr die SD-Karte. Dort läuft es aber aktuell eben nur auf SD.
VG, Thomas
Moin Thomas,
durch den Thread Titel und Deiner Signatur ging ich vom BPI aus.
Sorry, fürs "rein grätschen".
Sunny
Hi Sunny, ja es ist auch ein BPI.
Aber da es kein BPI-Netzteil gibt, habe ich ein original RPI-Netzteil verwendet. ;)
Das sollte aber nicht das Problem sein.
Zitat von: ToM_ToM am 01 März 2018, 18:45:04
... habe ich ein original RPI-Netzteil verwendet. ;)
Das sollte aber nicht das Problem sein.
Warum bist Du Dir da so sicher?
Angebliche Leistung ist das eine, Qualität etwas anderes.
Mein Hinweis bezog sich auf evtl. Probleme mit den USB-Geräten, sofern die sonst in Ordnung sind.
ZitatWarum bist Du Dir da so sicher?
Angebliche Leistung ist das eine, Qualität etwas anderes.
Ich meinte damit dass ich ein RPI Netzteil für einen BPI verwendet habe und das nicht das Problem sein sollte. ;D
Das mit dem USB..
Ich habe an einem Port einen passiven USB-Hub dranhängen an dem noch ein USB-Stick und ein Bluetooth-Stick hängen.
An dem anderen Port hängt der Cul-Stick.
VG, Thomas
Zitatpassiven USB-Hub
Mach daraus bitte mal einen aktiven ....
Wo hängt jetzt eigentlich Deine SSD?
lsusb -t
ZitatMach daraus bitte mal einen aktiven ....
Das wollte ich eig. vermeiden um nicht noch ein Netzteil mehr zu haben.
Aber sollte der Pi wieder abschmieren, werde ich wohl diesen Wege gehen müssen.
Wobei ich den HUB schon vorher hatte als das Ganze noch ohne SSD lief. Und da hatte es ja auch funktioniert.
Bisher nach dem Wechsel des Pis läuft alles noch stabil (seit Mittwoch Abend). In der Regel war dieser nach ca. 12 bis 48 Stunden tod.
Also mal abwarten und Tee trinken. ^^
Die SSD hängt am SATA-Port und bekommt Strom von den 2 extra dafür vorgesehenen Pins am Pi.
ZitatWobei ich den HUB schon vorher hatte als das Ganze noch ohne SSD lief
Aber Du hast jetzt mehr Stromverbrauch .....
Wenn es jetzt läuft, dann ist es gut. Allerdings hätte ich persönlich trotzdem ein ungutes Gefühl.
Zitat von: ToM_ToM am 02 März 2018, 12:07:46
...
Die SSD hängt am SATA-Port und bekommt Strom von den 2 extra dafür vorgesehenen Pins am Pi.
Damit habe ich schlechte Erfahrungen gemacht, weil die Banane in unregelmäßigen Abständen einfach plötzlich wegstarb.
Habe das aber auf dei verwendete SSD und kurzzeitige zu hohe Stromaufnahme geschoben.
ZitatAber Du hast jetzt mehr Stromverbrauch .....
Ja das stimmt. Es waren vorher 400 mAh (2 Watt) und sind jetzt ca. 600 - 700mAh (ca. 3,5 Watt)
Das Netzteil schafft aber 2,5 Ah.
Also ist noch genug Luft nach oben.
VG, Thomas
ZitatDamit habe ich schlechte Erfahrungen gemacht, weil die Banane in unregelmäßigen Abständen einfach plötzlich wegstarb.
Habe das aber auf dei verwendete SSD und kurzzeitige zu hohe Stromaufnahme geschoben.
Wie hast du es jetzt gelöst? Oder bist wieder zurück zur SD-Karte?
Wie hast DU gemessen? Zwischen 0,7 und 2,5A sind zwar Reserven, aber das heißt nicht, das bei Spitzenbelastung diese nicht überschritten werden könnten.
Du kannst ja mal ein Programm wie "stress" starten und dann gucken, was Dein System macht.
Hinweis: stress macht, je nach startparameter, CPU, io, memory oder sonstige Last, auch gerne in Kombination. Kommt eigentlich aus der x86-Welt, ist aber auch zu arm portiert worden und sollte in jeder Standarddistri vorhanden sein.
Da es den Server in den "Grenzbereich" bringt, besser vorher FHEM abschalten (und Backup vorhalten)
Zitat von: ToM_ToM am 02 März 2018, 12:28:15
Wie hast du es jetzt gelöst? Oder bist wieder zurück zur SD-Karte?
Genau, brachte nicht den erhofften Unterschied; sollte eh nur Übergangslösung sein
FHEM wandert eh auf den Server, sobald ich endlich mal auf einem Raspi/Banana eine "eierlegende Wollmilchsau" für die Audio-Dinge funktionstüchtig bekomme.
ZitatWie hast DU gemessen? Zwischen 0,7 und 2,5A sind zwar Reserven, aber das heißt nicht, das bei Spitzenbelastung diese nicht überschritten werden könnten.
Mit einem Energiemessgerät von Voltcraft (Energy Logger 4000). Und wie gesagt... bei meinen Eltern habe ich das gleiche System ohne SSD und dort läuft es monatelang stabil mit einem alten 500mAh Netzteil.
Das mit dem Stress-Test ist eine gute Idee. Das werde ich mal ausprobieren. :)
@Hollo: Ich bin extra auf SSD umgestiegen da mich das nervt dass die SD-Karten nach einigen Monaten immer defekt sind. Daher wäre der Wege zurück zur SD-Karte bei mir nur die letzte Lösung.
Moin Thomas,
Zitat von: ToM_ToM am 02 März 2018, 13:14:38
Und wie gesagt... monatelang stabil mit einem alten 500mAh Netzteil.
Auch mit Armbian und ähnlicher CPU-Last?
Bei mir lief Jessi mit SSD auch mit 1A Netzteil stabil.
Erst der Wechsel zu Armbian brauchte mehr Ampere bei gleicher Hardware und FHEM Einrichtung...
Vielleicht kannst Du Dir auch:
/etc/default/cpufrequtilsanschauen und dort etwas anpassen.
Damit kann die Leistung der CPU eingestellt werden und dies ändert auch den Stromverbrauch.
Viele Grüße
Sunny
PS: Netzteil steckt zwischen Sata und "Sata Strom" ?
ZitatAuch mit Armbian und ähnlicher CPU-Last?
Der Pi mit dem 500mAh Netzteil läuft mit Bananian ohne SSD
Mein Pi lief aber auch monatelange stabil mit Armbian und ohne SSD.
Erst der Umstieg auf SSD machte jetzt bei mir Probleme. Allerdings habe ich beim Umstieg das System komplett neu aufgesetzt und nicht nur die alten Daten von der SD-Karte rüberkopiert.
ZitatAuch mit Armbian und ähnlicher CPU-Last?
Netzteil steckt ganz normal am USB-Power-Input.
Die SSD bekommt den Strom über den 5V SATA-Output der direkt neben dem Power Input ist.
VG, Thomas
Und damit mehr Stromverbrauch und damit mehr Probleme ... s.o. ...
ZitatUnd damit mehr Stromverbrauch und damit mehr Probleme ... s.o. ...
Naja mal schauen... Wenn ich alle paar Monate eine SD-Karte tauschen muss, ist auch nervig.
Und mit der SSD läuft alles nochmal ca. 10 mal so schnell wie vorher.
Also mal abwarten wie lange er jetzt durchhält. :) Vielleicht hatte der Andere ja tatsächlich ein Ding weg.
Hallo Zusammen,
hier mal ein Zwischenstand. Seit dem Wechsel der Banane sind keine Probleme mehr aufgetreten. Die plötzlichen Abstürzte nach ca. 12 bis 24 Stunden sind bisher ausgeblieben.
Die Kiste läuft jetzt seit 5 Tagen stabil. Demnach scheint die andere Banane wohl entweder am SATA oder an der SATA Stromversorgung ein Ding weg zu haben.
VG, Thomas
Geht doch...! ;D
Gruß Jens