Btsync Vs Veille

[manu71]

Bonjour,

J'utilise BTSync pour synchroniser mes fichiers de travail. J'ai remarqué que quand BTSync tourne, mon NAS n'entrait jamais en veille. J'ai trouvé sur le net que ceci est lié au fait que BTSync est très bavard sur le réseau et empêche donc la veille.

Par soucis d'économie d'énergie, je souhaite mettre en place une tâche planifiée pour stopper le service le soir et le redémarrer le matin. Mais je ne sais pas mettre ça en place... Quelqu'un peut m'aider ?

Manu

[PiwiLAbruti]

Planifie l'exécution du script du paquet dans Panneau de configuration > Planificateur de tâches pour arrêter/démarrer BTsync :

/var/packages/btsync/scripts/start-stop-status stop

/var/packages/btsync/scripts/start-stop-status start

[manu71]

Super ! Merci beaucoup.

[CoolRaoul]

Je m'immisce dans le fil car je viens d'installer ce bidule (pas pris le package mais je ne pense pas que ça fasse de différence)

J'ai pu constater que le process btsync se réveille exactement toutes les secondes.

A chaque cycle il ne fait *strictement aucune entrée/sortie* (pas plus réseau que disque) mais consomme par contre du CPU.

Je me demande bien ce qu'il peut foutre. En tous cas ça confirme la remarque (le NAS n'entre jamais en veille) mais pas le diagnostic (tres bavard sur le réseau) puisque aucun traffic réseau n'est produit en absence de modifications à propager.

**EDIT**

J'ai déjà posé la question sur le forum de btsync, mais apparemment ça ne passionne pas les foules:

http://forum.bittorrent.com/topic/25171-daemon-never-sleeping-longer-than-1-second/?p=73000

Modifié le 26 novembre 2013 par CoolRaoul

[PiwiLAbruti]

En fait il y a bien des E/S réseau.
Fais un tcpdump sur le port d'écoute :

DiskStation> netstat -netplu|grep btsync
tcp	   0    0 0.0.0.0:{port}    0.0.0.0:*    LISTEN    {pid}/btsync
tcp	   0    0 0.0.0.0:8888      0.0.0.0:*    LISTEN    {pid}/btsync
udp        0    0 0.0.0.0:57126     0.0.0.0:*              {pid}/btsync
udp        0    0 0.0.0.0:3838      0.0.0.0:*              {pid}/btsync
DiskStation> tcpdump port {port} or udp port 3838 -nq

Modifié le 26 novembre 2013 par PiwiLAbruti

[CoolRaoul]

En fait il y a bien des E/S réseau.

Fais un tcpdump sur le port d'écoute :

DiskStation> netstat -netplu|grep btsync
tcp	   0    0 0.0.0.0:{port}    0.0.0.0:*    LISTEN    {pid}/btsync
tcp	   0    0 0.0.0.0:8888      0.0.0.0:*    LISTEN    {pid}/btsync
udp        0    0 0.0.0.0:57126     0.0.0.0:*              {pid}/btsync
udp        0    0 0.0.0.0:3838      0.0.0.0:*              {pid}/btsync
DiskStation> tcpdump port {port} or udp port 3838 -nq

Si il y avait des E/S réseau impliquant le process btsync le strace ne devrait-il-pas capturer les appels systèmes correspondants (read, write, ou sendto/recvfrom dans le cas de sockets udp) ?

Ce n'est pas parce que le process est en écoute sur des socket qu'il y a forcément du traffc.

Normalement il devrait y avoir du traffic uniquement lorsque'il y a des modifications de fichiers à propager, déclenché coté NAS un une notification inotify et coté client par l'arrivée de données de signalement des clients via le réseau.

Là, en mode standby, je constate un réveil toutes les secondes et les seuls appels système exécutés à chaque cycle sont pour lire l'heure et re-armer une alarme.

[PiwiLAbruti]

Ce n'est pas parce que le process est en écoute sur des socket qu'il y a forcément du traffc.

Ce n'est pas ce que j'ai dit, tu n'as pas du voir cette ligne :

DiskStation> tcpdump port {port} or udp port 3838 -nq

[CoolRaoul]

Ce n'est pas ce que j'ai dit, tu n'as pas du voir cette ligne :

DiskStation> tcpdump port {port} or udp port 3838 -nq

Avec le tcpdump je vois effectivement un broadcast UDP sur le port 3838 émis toutes les secondes mais comment se fait-t-il que strace n'y voit que du feu?

Un process peut faire des E/S réseau sans que cela implique le moindre appel système?

Mis à part cette question, je me demande à quoi cela peuvent bien servir ces broadcasts.

Les démon cloudstation bouclent en attente sur un select() avec timeout de 3 seconde, ça me semble plus approprié pour ce type d'application.

[PiwiLAbruti]

Un process peut faire des E/S réseau sans que cela implique le moindre appel système?

Un process peut faire des E/S réseau sans que strace ne l'affiche?

Mis à part cette question, je me demande à quoi cela peuvent bien servir ces broadcasts.

Les démon cloudstation bouclent en attente sur un select() avec timeout de 3 seconde, ça me semble plus approprié pour ce type d'application.

Contrairement à Cloud Station, BitTorrent Sync est décentralisé. Leurs fonctionnements respectifs sont donc complétement différents et difficilement comparables.

L'adresse du serveur Cloud Station est renseignée dans chaque client, alors que chaque nœud BitTorrent Sync doit découvrir ses pairs.

C'est pour ça que du broadcast est émis afin de détecter d'autres nœuds avec lesquels communiquer. De plus lorsque des noeuds communiquent entre eux, du trafic est émis toutes les 10 secondes par chaque nœud. Je n'ai pas vérifié l'intervalle de détection auprès des trackers.

Essaye de décocher les options suivantes dans les préférences des dossiers synchronisés :

• Utiliser le serveur de relais si nécessaire
• Utiliser le serveur de suivi
• Rechercher sur le LAN
• Recherche sur le réseau THD

[CoolRaoul]

Un process peut faire des E/S réseau sans que strace ne l'affiche?

La fonction de base de strace est justement de tracer les appels système, si on en peux même pas lui faire confiance pour ça, ça craint un peu. Inversement, qu'une E/S ne provoque pas d'appel système, j'ai du mal à imaginer.

Essaye de décocher les options suivantes dans les préférences des dossiers synchronisés :

• Utiliser le serveur de relais si nécessaire
• Utiliser le serveur de suivi
• Rechercher sur le LAN
• Recherche sur le réseau THD

J'ai bien peur qu'en supprimant tout ça je me retrouve avec plus de synchro du tout in fine.

Peut-être que btsync n'est simplement pas la bonne solution pour mon besoin: je cherche à maintenir sur le NAS un miroir d'un certain nombre de dossiers bien identifiés de mon smartphone Androïd.

Et DsCloud n'est pas adapté dans le cas de dossiers "éparpillés" comme ceux-la.

[PiwiLAbruti]

J'ai bien peur qu'en supprimant tout ça je me retrouve avec plus de synchro du tout in fine.

Si tu souhaites pouvoir faire des synchronisations depuis l'extérieur de ton réseau local, ton NAS ne sera plus détecté. Il te faut au minimum le serveur de suivi (tracker) et un serveur de relai si le port utilisé par BitTorrent Sync n'est pas NATé.

Si (comme moi) tu ne l'utilise qu'en local tu peux tout désactiver car c'est ton smartphone Android qui le détectera.

D'ailleurs il y a une fonctionnalité manquante sur l'application mobile (du moins sur iOS, je ne sais pas pour Android), c'est la possibilité de définir une liste de nœuds prédéfinis. Ainsi le NAS pourrait être détecté depuis internet sans utiliser de tracker.

[Fravadona]

Le NAS ne peut-il pas faire lui-meme office de tracker pour nos appareils ?

[CoolRaoul]

Si (comme moi) tu ne l'utilise qu'en local

En effet ça suffit à mon besoin

tu peux tout désactiver car c'est ton smartphone Android qui le détectera.

Je vais essayer ça des que possible.

[PiwiLAbruti]

Le NAS ne peut-il pas faire lui-meme office de tracker pour nos appareils ?

Non, aucun nœud ne peut pas avoir le rôle de tracker.

[CoolRaoul]

Un process peut faire des E/S réseau sans que strace ne l'affiche?

Je déterre ce vieux fil car je viens de m'apercevoir que par défaut, "strace" trace uniquement l'activité du *thread principal*.

Pour avoir une vision complete faut le switch "-f"

strace -f -p <pid>

que j'avais sans doute oublié, ce qui explique mes observations.

(j'étais persuadé que la seule fonction de "-f" était de tracer les process fils en suivant les "fork", je n'avais pas percuté qu'il y avait aussi un rapport avec les threads, mea culpa)