Diagnose eines Bittorrent-Clients

Probleme mit Samba, NFS, FTP und Co.
Antworten
Benutzeravatar
noobadix
Beiträge: 33
Registriert: 03.02.2009 03:23:22

Diagnose eines Bittorrent-Clients

Beitrag von noobadix » 13.04.2018 08:49:47

Liebe Debianer,

aus Dankbarkeit für Debian hoste ich Debian-Images zum Download per Torrent-System. Dabei lasse ich ein Tinker Board (ein SoC á la Raspberry Pi) mit TinkerOS (eine Art Debian in der Version "Jessie") hinter meinem Router laufen, das mittels der Software Transmission die Torrents von einer per USB angeschlossenen 2,5''-Festplatte bereitstellt. Meine Upload-Geschwindigkeit beträgt 2Mbit.

Das Tinker Board stürzt aber regelmäßig ab, d.h. es verliert die Netzwerkverbindung und ich möchte mich nun an die Diagnose machen. Im Hinblick auf meine Ausbildung zum Fachinformatiker steht dabei für mich der pädagogische Aspekt im Vordergrund. :-)

0. Fragen zum Hardware Setup
Optional, weil nicht Debian-spezifisch: :D
  1. Wie heißt der Computer in solch einer Funktion, bzw. gibt es dafür einen Fachbegriff? Ein Proxy ist es ja nicht, auch kein Gateway oder eine Firewall.
  2. Welche Eigenschaften sind maßgeblich für den Einsatz des Computers in dieser Funktion? Braucht es besonders viel RAM, viele CPU-Kerne, schnelle CPU-Kerne, irgendwelche besonderen Caches? Ich habe darauf geachtet, dass es eine Multi-Core CPU ist und mutmaße, dass es vorteilhaft ist, dass im Gegensatz zum Raspberry Pi die Ethernet-Netzwerkverbindung nicht über den USB-Bus läuft.
  3. Welche Dimensionierung der Lesegeschwindigkeit der Festplatte haltet ihr für ausreichend? Wie ist die zu ermitteln? Wäre eine Flash-HDD besser? Braucht eine HDD in solch einer Funktion sonstige besondere Eigenschaften?
  4. Welches Dateisystem ist für die HDD in diesem Fall geeignet?
1.Fragen zur Software/Administration
  1. Auch wenn die Frage recht unbedarft daherkommt: Woran liegt es, dass das Tinker Board nach ca. 24h nicht mehr in meinem Heimmnetzwerk (ssh, ping) zu erreichen ist? Die Energiespar-Modi von systemd habe ich alle mittels "systemctl mask [modi]" deaktiviert. Ein Raspberry Pi hatte diese Problematik nicht, es scheint an TinkerOS oder dem Tinker Board zu liegen. Die Sys-Logs haben einen Systemneustart nicht überlebt. Ich habe nun das Logging auf persistent gestellt, in etwa 24h sollten dementsprechende Ergebnisse vorliegen.
  2. Eine statische IP lasse ich durch einen entsprechenden Eintrag in /etc/network/interfaces verlangen. Ist das der "richtige", zeitgemäße Weg? Mein Eintrag sieht da so einsam aus, das macht mich stutzig.
  3. Wie analysiere ich, wie viele versendete Pakete gedroppt wurden? Auf welchen Zeitraum beziehen sich die Angaben darüber von der Ausgabe des Befehls ifconfig? Sprich: Wenn dort unter TX dropped: 0 steht, heißt das, dass seit dem letzten Boot noch nie ein Paket gedroppt wurde?
  4. Anscheinend gibt es Buffer im OS zum Empfangen/Senden von Paketen, zumindest habe ich die Größenwerte solcher erhöht, weil sich Transmission im syslog darüber beklagt hat, dass die angeforderte Buffer-Größe nicht gewährt wurde. Dazu habe ich in /etc/sysctl.conf "net.core.rmem_max=4194304" und "net.core.wmem_max=1048576" eingetragen, weil eben diese Werte laut syslog von Transmission verlangt wurden. Was sind das für Buffer, von welchen (Sub-)Systemen werden die genutzt? Warum sind das so krumme Zahlen?
  5. Wie kann ich diese Buffer mittels systemd-journald loggen und woran merke ich, ob sie angemessen dimensioniert wurden? Oder muss ich das selbst händisch loggen? Wenn ja, was ist zu empfehlen, wenn das logging ressourcenschonend (CPU- und HDD-Schreib-Last) verlaufen soll?
  6. Wie lässt sich Netzwerkverkehr loggen, bietet systemd-journald dazu etwas an? Mit welcher Größe habe ich dann zu rechnen, wenn ich z.B. die letzten sieben Tage loggen lassen möchte? Ich möchte mich gerne in der regen Nutzung meiner Dienstleistung sonnen können. :-)
  7. Welche Daten sollte ich noch im Auge behalten?
Bonusfragen
  1. Warum zum Geier sind Debian-DVD #2 und #3 recht weit oben in meinem Upload ranking? Wer braucht die?
  2. Die Torrents ziehe ich momentan einzeln und händisch von https://cdimage.debian.org/debian-cd/. Bei ca. 40 Torrents ist das schon eine langweilige Mühe, die bei jedem Update/Versionssprung ansteht. Bekomme ich die Torrents irgendwie eleganter und effizienter?
Es würde mich freuen, wenn sich jemand findet, der die vielen vermutlich zeitintensiven Antworten aus Spaß an der Freude oder ähnlichem bereitstellt. Ich bin dabei völlig empfänglich und dankbar für schon nur Verweise auf Lektüre oder andere Quellen, aus denen ich mir die Antworten dann selbst erarbeiten kann.

Lieben Gruß!
Jedes OS ist brauchbar und sei es nur als schlechtes Bespiel.

Benutzeravatar
Lord_Carlos
Beiträge: 3961
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Diagnose eines Bittorrent-Clients

Beitrag von Lord_Carlos » 13.04.2018 09:55:41

noobadix hat geschrieben: ↑ zum Beitrag ↑
13.04.2018 08:49:47
Wie heißt der Computer in solch einer Funktion, bzw. gibt es dafür einen Fachbegriff? Ein Proxy ist es ja nicht, auch kein Gateway oder eine Firewall.
Einfach Server oder Torrent-client? Torrent-server? Torrent-node?
noobadix hat geschrieben: ↑ zum Beitrag ↑
13.04.2018 08:49:47

Welche Eigenschaften sind maßgeblich für den Einsatz des Computers in dieser Funktion? Braucht es besonders viel RAM, viele CPU-Kerne, schnelle CPU-Kerne, irgendwelche besonderen Caches? Ich habe darauf geachtet, dass es eine Multi-Core CPU ist und mutmaße, dass es vorteilhaft ist, dass im Gegensatz zum Raspberry Pi die Ethernet-Netzwerkverbindung nicht über den USB-Bus läuft.

Welche Dimensionierung der Lesegeschwindigkeit der Festplatte haltet ihr für ausreichend? Wie ist die zu ermitteln? Wäre eine Flash-HDD besser? Braucht eine HDD in solch einer Funktion sonstige besondere Eigenschaften?
Bei 2 mbit upload ist das doch alles egal. Du must weder viel cachen oder schnell lesen.
Ich habe meinen torrent clienten gesagt er soll mehr ram benutzten, dann wird weniger von der HDD gelesen. Aber eigentlich auch egal.
noobadix hat geschrieben: ↑ zum Beitrag ↑
13.04.2018 08:49:47

[*] Welches Dateisystem ist für die HDD in diesem Fall geeignet?
XFS imd EXT4 sind solide.
Snapshots oder integritets checks sind bei torrent Daten nicht so wichtig.
noobadix hat geschrieben: ↑ zum Beitrag ↑
13.04.2018 08:49:47

[*] Auch wenn die Frage recht unbedarft daherkommt: Woran liegt es, dass das Tinker Board nach ca. 24h nicht mehr in meinem Heimmnetzwerk (ssh, ping) zu erreichen ist?
Besteht das Problem wenn der Torrent client aus ist?
noobadix hat geschrieben: ↑ zum Beitrag ↑
13.04.2018 08:49:47
Eine statische IP lasse ich durch einen entsprechenden Eintrag in /etc/network/interfaces verlangen. Ist das der "richtige", zeitgemäße Weg? Mein Eintrag sieht da so einsam aus, das macht mich stutzig.
Zeitgemäß waere dhcp-client ;-)
noobadix hat geschrieben: ↑ zum Beitrag ↑
13.04.2018 08:49:47

[*] Wie lässt sich Netzwerkverkehr loggen, bietet systemd-journald dazu etwas an? Mit welcher Größe habe ich dann zu rechnen, wenn ich z.B. die letzten sieben Tage loggen lassen möchte? Ich möchte mich gerne in der regen Nutzung meiner Dienstleistung sonnen können. :-)
DebianWireshark und sein cli client. Glaube nennt sich t=shark?
Naja, wenn du 50gb in 7 Tagen hochlaedst, dann wird 50gb gelogged.
noobadix hat geschrieben: ↑ zum Beitrag ↑
13.04.2018 08:49:47

Die Torrents ziehe ich momentan einzeln und händisch von https://cdimage.debian.org/debian-cd/. Bei ca. 40 Torrents ist das schon eine langweilige Mühe, die bei jedem Update/Versionssprung ansteht. Bekomme ich die Torrents irgendwie eleganter und effizienter?
Veilleicht einfach ein bash script das zusammen mit wget alle torrent daten runterlaedt?
Ich glaube wget kannst du sagen er soll alles rekursive von https://cdimage.debian.org/debian-cd/ runterladen was mit *.torrent ended.

Neuer b+ raspberry pi kann uebrigens 300mbit via USB lesen/schreiben.
Der "alte" kann auch torrent mit 100mbit / ~11MB/s, was bei dir ausreichend ist.
Ich benutzte deluge als Torrent Client. Netter remote client. Dann muss ich kein webinterface oder aehnliches benutzten.
Seede momentan 500 - 600 torrents. Aber mit einem Intel Pentium G4560, Die 300mbit vom rPi3 waeren mir noch zu langsam.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

Benutzeravatar
hikaru
Beiträge: 9557
Registriert: 09.04.2008 12:48:59

Re: Diagnose eines Bittorrent-Clients

Beitrag von hikaru » 13.04.2018 10:40:27

noobadix hat geschrieben: ↑ zum Beitrag ↑
13.04.2018 08:49:47
Bonusfragen
  1. Warum zum Geier sind Debian-DVD #2 und #3 recht weit oben in meinem Upload ranking? Wer braucht die?
  2. Die Torrents ziehe ich momentan einzeln und händisch von https://cdimage.debian.org/debian-cd/. Bei ca. 40 Torrents ist das schon eine langweilige Mühe, die bei jedem Update/Versionssprung ansteht. Bekomme ich die Torrents irgendwie eleganter und effizienter?
Ich vermute, es gibt nicht so viele Leute, die DVD 2 und 3 überhaupt verteilen. Ich mache das z.B. nicht. Nun könnte man mal untersuchen, ob das Verhältnis von DVD1 Seedern/Leechern größer oder kleiner ist als das von DVD2&3 Seedern/Leechern. Je nach Ergebnis hättest du dann eine mögliche Erklärung für deine Beobachtung.

Um die Torrents zu beschaffen, habe ich mir ein Script geschrieben, das alle DVD1, sowie die CD1 und netinstalls aller Architekturen herunterlädt. Da meine Verbindung ebenfalls nicht die schnellste ist, würde es per Torrent ca. 2 Tage dauern, alles herunterzuladen. Das würde mich an sich nicht stören, aber während der Zeit kann ich kaum sinnvoll was anderes machen.
Daher hole ich mir die Images neuer Point-Releases per Jidgo, basierend auf dem jeweiligen Vorgängerimage. Das dauert dann nur ein paar Stunden, wieviele genau weiß ich nicht, da ich das Script morgens bzw. abends anstoße und wenn ich von der Arbeit komme bzw. am nächsten Morgen ist alles fertig.
Einen vollen Satz hole ich per Torrent nur noch beim Releasewechel.

Benutzeravatar
noobadix
Beiträge: 33
Registriert: 03.02.2009 03:23:22

Re: Diagnose eines Bittorrent-Clients

Beitrag von noobadix » 13.04.2018 10:47:42

Lord_Carlos, hab mal wieder vielen Dank für rasche Antwort!
Besteht das Problem wenn der Torrent client aus ist?
Uhm, das habe ich noch gar nicht in Betracht gezogen. :facepalm: Wenn mir die Logs nicht beim nächsten crash nützliche Hinweise liefern, wird das der nächste 24h-Test.
Einfach Server oder Torrent-client? Torrent-server? Torrent-node?
Server klingt doch gut.
Bei 2 mbit upload ist das doch alles egal. Du must weder viel cachen oder schnell lesen.
Hier in dem konkreten Fall ja, vermutlich. Aber es ist ja auch noch Buddelkasten mit Welpenschutz. :-) Ich bereite mich auf professionellen Einsatz vor, wo der Klient dann wissen soll, wie er sein Geld am effizientesten einsetzt und dazu muss ich die einzelnen Komponenten dann beherrschen, also kennen, analysieren und prognostizieren können. Schätze ich mal.
XFS imd EXT4 sind solide.
Snapshots oder integritets checks sind bei torrent Daten nicht so wichtig
Interessante Worte. Ich muss die hälfte erstmal nachschlagen. :-D
Zeitgemäß waere dhcp-client
Mmmhm. Wird per default ja auch so gehandhabt. Nur so aus dem Bauch heraus dachte ich, dass mein Router sich die "Arbeit" sparen kann, stündlich die Gültigkeit des lease zu checken. Ach, "client" schreibst du? Das kenne ich nur vom Konzept her. Welche konkrete Software erledigt diesen Job in Debian?
Wireshark und sein cli client. Glaube nennt sich t=shark?
Naja, wenn du 50gb in 7 Tagen hochlaedst, dann wird 50gb gelogged.
In Wiresahrk werde ich mich dann mal also einlesen. Ich hatte auf eine ins Debian-Grundsystem fest eingebaute Lösung gehofft.
ch glaube wget kannst du sagen er soll alles rekursive von https://cdimage.debian.org/debian-cd/ runterladen was mit *.torrent ended.
Ja, das klingt machbar und interessant. Danke für den Tipp, ich denke noch zu sehr wie ein Windows-Nutzer und komme manchmal nicht auf banale Ideen, wenn sie nicht mit der Maus erledigt werden können. :-D
Ich benutzte deluge als Torrent Client. Netter remote client. Dann muss ich kein webinterface oder aehnliches benutzten.
Das Webinterface ist für mich momentan Kino, da gucke ich einfach gerne ab und an drauf. Aber wenn ich nun andere Methoden finde, den Traffic zu analysieren, ist das keine Bedingung mehr und dann lasse ich deluge gerne mal gegen Transmission im Performance-Test antreten.
Jedes OS ist brauchbar und sei es nur als schlechtes Bespiel.

Benutzeravatar
noobadix
Beiträge: 33
Registriert: 03.02.2009 03:23:22

Re: Diagnose eines Bittorrent-Clients

Beitrag von noobadix » 13.04.2018 11:09:38

hikaru hat geschrieben: ↑ zum Beitrag ↑
13.04.2018 10:40:27
Ich vermute, es gibt nicht so viele Leute, die DVD 2 und 3 überhaupt verteilen. Ich mache das z.B. nicht. Nun könnte man mal untersuchen, ob das Verhältnis von DVD1 Seedern/Leechern größer oder kleiner ist als das von DVD2&3 Seedern/Leechern. Je nach Ergebnis hättest du dann eine mögliche Erklärung für deine Beobachtung.

Um die Torrents zu beschaffen, habe ich mir ein Script geschrieben, das alle DVD1, sowie die CD1 und netinstalls aller Architekturen herunterlädt. Da meine Verbindung ebenfalls nicht die schnellste ist, würde es per Torrent ca. 2 Tage dauern, alles herunterzuladen. Das würde mich an sich nicht stören, aber während der Zeit kann ich kaum sinnvoll was anderes machen.
Daher hole ich mir die Images neuer Point-Releases per Jidgo, basierend auf dem jeweiligen Vorgängerimage. Das dauert dann nur ein paar Stunden, wieviele genau weiß ich nicht, da ich das Script morgens bzw. abends anstoße und wenn ich von der Arbeit komme bzw. am nächsten Morgen ist alles fertig.
Einen vollen Satz hole ich per Torrent nur noch beim Releasewechel.
Hi und danke für die Antwort!

Wenn mein System läuft, schaue ich mir das Verhältnis gerne mal an, klingt plausibel. Ich hatte gedacht, dass ich vielleicht irgendetwas übersehen habe.

Solch ein Script würde ich mir dann aus Spaß an der Freude auch mal basteln. Aber eigentlich finde ich, dass Debian-Projekt da auch mal einen kompakten Satz bereitstellen könnte. Wo stelle ich solch eine Anfrage?
Wie erhält du Nachricht über ein neues Release, bzw. hast du eine Idee, wie man das per Script lösen kann? Notfalls natürlich über den Dateinamen der Torrents, was mir aber recht brachial erscheint. Kann man nicht irgendwie deinen Debian-Server fragen, wie die aktuelle Versionsnummer lautet?
Jedes OS ist brauchbar und sei es nur als schlechtes Bespiel.

Benutzeravatar
Lord_Carlos
Beiträge: 3961
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Diagnose eines Bittorrent-Clients

Beitrag von Lord_Carlos » 13.04.2018 11:10:05

noobadix hat geschrieben: ↑ zum Beitrag ↑
13.04.2018 10:47:42
Hier in dem konkreten Fall ja, vermutlich. Aber es ist ja auch noch Buddelkasten mit Welpenschutz. :-) Ich bereite mich auf professionellen Einsatz vor, wo der Klient dann wissen soll, wie er sein Geld am effizientesten einsetzt und dazu muss ich die einzelnen Komponenten dann beherrschen, also kennen, analysieren und prognostizieren können. Schätze ich mal.
SeedBox, wie man torrent server die man mietet gerne nennt, brauchen als aller erstes schnelles internet. Dann sollte man auch lesen und schreiben koennen mit der Internet Geschwindichkeit.
Bei mir zu Hause waere das ~65MB/s lesen/schreiben. Also reicht eine gute alte Festplatte. Archive Festplatten (SMR drive?) z.B. Seagate Archive koennen da vielleicht schon zu langsam sein. Je nach Datensystem und mehr kann man noch eine SSD zwischen haegen und als lese und schreib Cache benutzten.
Ram ist nett weil dann oft abgefragte teile nicht von der HDD gelesen werden muessen.
Z.B. seede ich ~500 torrents, aber Ubuntu CD wird fast immer hochgeladen. Da ist immer jemand der das Haben will. Das liest mein torrent Client aus dem Ram. Ich habe Deluge so ca. ~4GiB ram gegeben.

noobadix hat geschrieben: ↑ zum Beitrag ↑
13.04.2018 10:47:42
XFS imd EXT4 sind solide.
Snapshots oder integritets checks sind bei torrent Daten nicht so wichtig
Interessante Worte. Ich muss die hälfte erstmal nachschlagen. :-D
Ein richtig nettes Datensystem ist ZFS. Aber wenn man einfach nur Debian torrents Seeden will braucht man die meisten netten sachen nicht. Aber liest mal das hier: https://de.wikipedia.org/wiki/ZFS_(Date ... rkorrektur

Torrent hat schon checksum / Datenfehlerkorrektur eingebaut.
Und wenn die Festplatte abraucht kann man die Torrents einfach wieder runterladen. Da braucht man keine backups oder raid.
Bei anderen dingen kann das aber richtig edel sein.
noobadix hat geschrieben: ↑ zum Beitrag ↑
13.04.2018 10:47:42
Zeitgemäß waere dhcp-client
Mmmhm. Wird per default ja auch so gehandhabt. Nur so aus dem Bauch heraus dachte ich, dass mein Router sich die "Arbeit" sparen kann, stündlich die Gültigkeit des lease zu checken. Ach, "client" schreibst du? Das kenne ich nur vom Konzept her. Welche konkrete Software erledigt diesen Job in Debian?
Naja, das braucht jetzt keine ressourcen. Ich sehen das so das man eine feste IP nur wenige Anwendungsfaelle hat:

* Nischen loesungen
* Fehlerfinden (warum geht X/Y nicht?)
* Alte Menschen, die gibt es hier im Debianforum zuhauf.
Wireshark und sein cli client. Glaube nennt sich t=shark?
Naja, wenn du 50gb in 7 Tagen hochlaedst, dann wird 50gb gelogged.
In Wiresahrk werde ich mich dann mal also einlesen. Ich hatte auf eine ins Debian-Grundsystem fest eingebaute Lösung gehofft.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

Benutzeravatar
hikaru
Beiträge: 9557
Registriert: 09.04.2008 12:48:59

Re: Diagnose eines Bittorrent-Clients

Beitrag von hikaru » 13.04.2018 11:31:58

noobadix hat geschrieben: ↑ zum Beitrag ↑
13.04.2018 11:09:38
Solch ein Script würde ich mir dann aus Spaß an der Freude auch mal basteln. Aber eigentlich finde ich, dass Debian-Projekt da auch mal einen kompakten Satz bereitstellen könnte. Wo stelle ich solch eine Anfrage?
Ich denke, ein Wishlist-Bugreport gegen den Debian-Installer könnte eine passende Adresse sein.
noobadix hat geschrieben: ↑ zum Beitrag ↑
13.04.2018 11:09:38
Wie erhält du Nachricht über ein neues Release
Meist aus der Presse. Debian-Releases kommen ja meist am Wochenende. Da reduziere ich meine IT-Aktivität gern auf ein Minimum, so dass ich teils erst am Montag wieder Nachrichten lese und dann merke: "Huch! Schon wieder ein neues Debian!"
noobadix hat geschrieben: ↑ zum Beitrag ↑
13.04.2018 11:09:38
bzw. hast du eine Idee, wie man das per Script lösen kann?
Du könntest die Debian-News [1] (Webseite oder E-Mail) auswerten.


[1] https://www.debian.org/News/

Benutzeravatar
Lord_Carlos
Beiträge: 3961
Registriert: 30.04.2006 17:58:52
Lizenz eigener Beiträge: GNU Free Documentation License
Wohnort: Dänemark

Re: Diagnose eines Bittorrent-Clients

Beitrag von Lord_Carlos » 13.04.2018 11:42:51

Oder einfach taeglich alle torrent Dateien runterladen. Wenn es neue Dateien gibt merkt es der Torrent Klient schon.
Ich koennte mir vorstellen das es ein Einzeiler wird.

Torrent Klient laesst sich so einstellen das es in einem Verzeichnis nach neuen Torrent Daten sucht.
Da muss man nichts parsen. Das das ganze viel viel einfacher.

Code: Alles auswählen

╔═╗┬ ┬┌─┐┌┬┐┌─┐┌┬┐╔╦╗
╚═╗└┬┘└─┐ │ ├┤ │││ ║║
╚═╝ ┴ └─┘ ┴ └─┘┴ ┴═╩╝ rockt das Forum!

Benutzeravatar
Dogge
Beiträge: 1834
Registriert: 13.09.2010 11:07:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Diagnose eines Bittorrent-Clients

Beitrag von Dogge » 14.04.2018 15:00:24

Semi-OT:

Code: Alles auswählen

cat /usr/local/bin/get_debian_torrents 
#! /bin/bash
cd /var/lib/transmission-daemon/watchdir
wget -A torrent -m -p -E -k -K -np -nd https://cdimage.debian.org/debian-cd/current/
wget -A torrent -m -p -E -k -K -np -nd https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/current/
chmod 644 /var/lib/transmission-daemon/watchdir/*
service transmission-daemon restart
Debian Testing + Gnome | Linux-Anfänger seit 04/2003
http://files.mdosch.de/2014-07/0xE13D657D.asc

Benutzeravatar
noobadix
Beiträge: 33
Registriert: 03.02.2009 03:23:22

Re: Diagnose eines Bittorrent-Clients

Beitrag von noobadix » 17.04.2018 01:05:27

Cool! :D
In Kombination mit dem RSS-Feed von Debian, der über neue Releases berichtet, könnte man nun bei jedem neuen Eintrag und vorsichtshalber alle zwei Monate auch unabhängig davon die ggF. aktualisierten Torrents routiniert durch systemd-timer ziehen lassen.
Die Info, ob der RSS-Feed aktualisiert worden ist, wird durch den Parameter -N von wget ersichtlich, weil nur bei akutellerem Timestamp die lokale RSS-Datei überschrieben wird. Wie man mit der Info in einem Shell-Skript arbeiten kann, finde ich heute Abend aber wohl nicht mehr heraus.

@Lord_Carlos
Tatsächlich läuft das Board >24h stabil, wenn transmission nicht läuft.
Hier das journalctl-log seit 13.04.: https://pastebin.com/w188K0mv
Vor allen dort aufgeführten Reboots lief transmission, seit dem letzten Reboot nicht mehr. Die letzten Meldungen vor dem Netzwerkverbindungsverlust geben mir wenig Aufschluss, bzw. sehen für mich unbedenklich aus:

Code: Alles auswählen

Apr 14 04:30:05 linaro-alip kernel: rk3288-dmc ff610000.dmc: rk3288_dmcclk_round_rate(533000000) vco: (24 MHz * 133) / 3 = 1064000000 Hz => clk: vco / 2 = 532000000 Hz
Apr 14 04:30:07 linaro-alip kernel: rk3288-dmc ff610000.dmc: rk3288_dmcclk_round_rate(200000000) vco: (24 MHz * 50) / 1 = 1200000000 Hz => clk: vco / 6 = 200000000 Hz
Apr 14 04:37:22 linaro-alip sudo[3356]: pam_unix(sudo:session): session closed for user root
Apr 14 04:37:26 linaro-alip sshd[3343]: Received disconnect from 192.168.0.55: 11: disconnected by user
Apr 14 04:37:26 linaro-alip sshd[3324]: pam_unix(sshd:session): session closed for user linaro
Apr 14 04:37:26 linaro-alip systemd-logind[1192]: Removed session c6.
Apr 14 04:37:26 linaro-alip systemd[3331]: Reached target Shutdown.
Apr 14 04:37:26 linaro-alip systemd[3331]: Stopped target Default.
Apr 14 04:37:26 linaro-alip systemd[3331]: Stopped target Basic System.
Apr 14 04:37:26 linaro-alip systemd[3339]: pam_unix(systemd-user:session): session closed for user linaro
Apr 14 04:37:26 linaro-alip systemd[3331]: Stopped target Timers.
Apr 14 04:37:26 linaro-alip systemd[3331]: Stopped target Sockets.
Apr 14 04:37:26 linaro-alip systemd[3331]: Stopped target Paths.
Apr 14 04:37:26 linaro-alip systemd[3331]: Starting Exit the Session...
Apr 14 04:37:26 linaro-alip systemd[3331]: Received SIGRTMIN+24 from PID 3458 (kill).
Apr 14 05:42:03 linaro-alip systemd-timesyncd[1143]: Timed out waiting for reply from [2a02:2028:ff00:a00::5]:123 (2.debian.pool.ntp.org).
Apr 14 05:42:13 linaro-alip systemd-timesyncd[1143]: Timed out waiting for reply from [2a01:4f8:13b:3ba6::2]:123 (2.debian.pool.ntp.org).
Apr 14 05:42:23 linaro-alip systemd-timesyncd[1143]: Timed out waiting for reply from [2001:638:502:137:21b:78ff:fe77:c6ec]:123 (2.debian.pool.ntp.org).
Apr 14 05:42:33 linaro-alip systemd-timesyncd[1143]: Timed out waiting for reply from [2001:418:3ff::53]:123 (2.debian.pool.ntp.org).
Apr 14 05:42:44 linaro-alip systemd-timesyncd[1143]: Timed out waiting for reply from 78.47.94.77:123 (2.debian.pool.ntp.org).
Apr 14 05:42:54 linaro-alip systemd-timesyncd[1143]: Timed out waiting for reply from 173.212.196.208:123 (2.debian.pool.ntp.org).
Apr 14 05:43:04 linaro-alip systemd-timesyncd[1143]: Timed out waiting for reply from 185.233.106.45:123 (2.debian.pool.ntp.org).
Apr 14 05:43:14 linaro-alip systemd-timesyncd[1143]: Timed out waiting for reply from 213.251.52.43:123 (2.debian.pool.ntp.org).
-- Reboot --
Das Tinker Board ist für Temperaturanfälligkeit bekannt, diese habe ich bereits überwacht und ist unbedenklich. Bekannt ist das Tinker Board aber auch für sein angeblich schlechtes OS "TInkerOS". Nichts desto weniger würde ich den Fehler gerne finden und würde mich über Vorschläge weiterhin freuen. Die Frage habe ich auch im entsprechenden Forum gestellt, aber da komm keine weitere Antwort bislang.
Und vielleicht ist es auch Quatsch hier überhaupt das Tinker Board samt dubiosem OS zu nutzen, wenn der Raspi, der die Aufgabe bislang fehlerfrei meisterte, ausreichend dimensioniert war. Wie weit die Hardware ausreicht, kann ich nicht einschätzen, weil ich nicht weiß, wie sich mehrere Leecher auswirken.
Jedes OS ist brauchbar und sei es nur als schlechtes Bespiel.

Benutzeravatar
hikaru
Beiträge: 9557
Registriert: 09.04.2008 12:48:59

Re: Diagnose eines Bittorrent-Clients

Beitrag von hikaru » 17.04.2018 07:22:38

noobadix hat geschrieben: ↑ zum Beitrag ↑
17.04.2018 01:05:27
Das Tinker Board ist für Temperaturanfälligkeit bekannt, diese habe ich bereits überwacht und ist unbedenklich.
Davon würde ich nicht so ohne Weiteres ausgehen. Was ist, wenn eine Komponente ein Temperaturproblem hat, für die das Board gar keinen Sensor hat?
Ich würde einen Test mit Zwangsbelüftung machen, wenn ich einen Anfangsverdacht auf ein Temperaturproblem hätte.
noobadix hat geschrieben: ↑ zum Beitrag ↑
17.04.2018 01:05:27
Bekannt ist das Tinker Board aber auch für sein angeblich schlechtes OS "TInkerOS".
Läuft darauf vielleicht auch ein gewöhnliches Debian?

Benutzeravatar
Dogge
Beiträge: 1834
Registriert: 13.09.2010 11:07:33
Lizenz eigener Beiträge: MIT Lizenz

Re: Diagnose eines Bittorrent-Clients

Beitrag von Dogge » 17.04.2018 08:43:50

Ich hätte in meinem vorigen Beitrag noch hinzuschreiben sollen, dass bei mir (debian stretch) die Optionen für eine watchdir nicht in der mitgelieferten config (auch nicht deaktiviert) vorhanden waren und dich erst einfügen musste. Danach läuft es aber wie es soll.
Läuft darauf vielleicht auch ein gewöhnliches Debian?
Ich kenne armbian nicht und kann nicht sagen in wie weit das einem gewöhnlichen Debian entspricht, aber zumindest bieten die wohl stretch-basierte images an: https://tinkerboarding.co.uk/wiki/index ... re#Armbian+
Debian Testing + Gnome | Linux-Anfänger seit 04/2003
http://files.mdosch.de/2014-07/0xE13D657D.asc

Benutzeravatar
noobadix
Beiträge: 33
Registriert: 03.02.2009 03:23:22

Re: Diagnose eines Bittorrent-Clients

Beitrag von noobadix » 19.04.2018 01:59:05

Dann auf ein Neues:
Das Board läuft nun mit aktiver Lüftung und Armbian und dank wget vielen Images mehr.

Armbian ist dritte Wahl, weil nicht aus offizieller Quelle. Ich hatte das Original-Debian ausprobiert, aber das bootete nicht. Ich schätze, dass es an spezieller Firmware und dem Bootloader lag.
Jedes OS ist brauchbar und sei es nur als schlechtes Bespiel.

Antworten