Mon noeud duniter sous raspberry (Yunohost) plante régulièrement

Support
, , ,
1

Bonjour,
Ces derniers jours j’ai remarqué que, parfois, mon nœud était complètement down. Malgré le fait que je l’ai mis en service/daemon (tel qu’expliqué par @Inso ici ) pour qu’il se lance au démarrage du raspberry Pi2 en cas de reboot de ce dernier. Quand je relance le service (duniter webstart) après avoir remarqué qu’il était down, j’ai une erreur (transaction null line X ou je sais plus quoi). Je suis obligé de faire un reset data, de le sync à nouveau pour le relancer…un peu chiant. J’ai remarqué du coup que ma partition swap (un fichier dans le cas de raspbian) était utilisée à 100%. C’est peut-être lié ? D’autre part, lorsque je lance mon nœud, je peux voir son status “UP” ici. Puis, au bout d’un moment, son status passe à “DOWN” bien que “Duniter is running with PID” et que le nœud a l’air de tourner. Une idée ?

2

Je ne suis pas sur que cela est du au fichier swap. J’ai plus de 30 Raspberry Pis et le problème de swap n’apparait pas seulement que sur mes Raspberry Pis hébergeant les nœuds Duniter.

3

Alors concernant ce dernier point c’est tout a fait normal, ce champ était utilisé (et donc refraichi) par le crawler BMA, comme il n’est plus utilisé il passe automatiquement a DOWN a bout de quelques minutes et y reste, on pourrait le supprime ce champ d’ailleurs, au moins plus personne ne se poserai la question :slight_smile:

1 Like
4

OK merci pour vos réponses. Même si ça ne corrige pas mon problème (aucune idée pourquoi le nœud ne tourne plus au bout d’un moment), j’ai donc lu qu’on pouvait supprimer le fichier swap pour ne pas trop user la carte SD. Est-ce une bonne pratique ? Mon raspberry héberge 3 sites web, un serveur MYSQL, un serveur mail et un nœud duniter. J’en profite pour poser une autre question. Mon nœud a souvent quelques blocs de retard (entre 30 et 150 blocs). Serait-ce dû plutôt à ma connexion ADSL de 4MBs ou à cause de la puissance limitée du raspberry ?

5

C’est la bande passante, surtout si elle est déjà un peu prise par les autres services et ta propre utilisation, ça s’engorge vite !

1 Like
6

Pour un Raspi2, ça me paraît beaucoup. Duniter étant assez gourmand aujourd’hui, si tes sites sont du Wordpress ça peut devenir beaucoup trop.

Quelle version utilises-tu d’ailleurs ? La 1.6.x ? C’est celle qu’il vaut mieux mettre sur un Raspi aujourd’hui, même si ce n’est pas la version officielle. Au moins la consigne CPU sera à peu près respectée.

7

Mon noeud est en 1.6. j’ai 2 wordpress dont qui n’est pas encore utilisé. Le troisième site c’est juste une page HTML avec un peu de javascript et de php qui récupère des images sur FaceBook par l’API. La RAM n’est pas utilisée à fond (enfin presque. Elle est à 93%). Je vais sûrement supprimer le wordpress que je n’utilise pas et le serveur mail. Par contre ce swap alors ? J’en fais quoi ? Je le laisse tel quel ou je le delete ?

8

Finalement je l’ai supprimé en suivant cette méthode. Le serveur n’a pas l’air d’en souffrir. J’ai supprimé quelques services inutilisés et la RAM est utilisée à 89%.

9

@elois ou @florck me disait, quand nous avions justement le swap bien utilisé sur le serveur GitLab, que de toute façon le swap est libéré automatiquement par le système au besoin et donc qu’il n’y a pas lieu de s’en inquiéter.

Par contre si tu swappes, c’est effectivement que tu es court en RAM.

10

Bon, mon nœud est à nouveau tombé ce matin ou cette nuit :

admin@YunoHost:~ $ sudo -u g1 duniter status
Duniter is not running.
admin@YunoHost:~ $ sudo -u g1 duniter webstart
Starting duniter_default daemon...
duniter_default daemon started. PID: 23013
admin@YunoHost:~ $ sudo -u g1 duniter status
Duniter is not running.
admin@YunoHost:~ $ sudo -u g1 duniter stop
duniter_default daemon is not running

Bizarre. DOnc je redémarre pour voir si le service créé à l’aide des conseils d’Inso se lance correctement au démarrage et là ça passe :

admin@YunoHost:~ $ sudo reboot
admin@YunoHost:~ $ sudo -u g1 duniter status
Duniter is running using PID 1824.

Quand je vais voir la webapp, je vois qu’il a 479 blocs de retard.
Une petite idée de ce qui se passe ? Est-ce qu’il va se resync tout seul ou est-ce que je dois le sync manuellement ?

11

Voici un extratit des logs. J’ai viré les lignes en doublons. Certaines d’entre elles ne me paraissent bizarres quand même.

2018-01-12T08:28:51+00:00 warn 
2018-01-12T08:29:01+00:00 info WS2P: Could not connect to peer 9jMbygZe using `WS2P 82.244.12.8 20900: WS2P connection timeout`
2018-01-12T08:29:17+00:00 info WS2P: Could not connect to peer EZBtAeBm using `WS2P g1.monnaielibreoccitanie.org 443: WS2P connection timeout`
2018-01-12T08:29:31+00:00 error WS2P >>> >>> WS ERROR: INCORRECT_PUBKEY_FOR_REMOTE
2018-01-12T08:29:33+00:00 info WS2P: Could not connect to peer 8HTqS38q using `WS2P g1.ifee.fr 443: WS2P connection timeout`
2018-01-12T08:29:48+00:00 info WS2P: Could not connect to peer B4zu8reA using `WS2P 46.162.146.163 20900: WS2P connection timeout`
2018-01-12T08:30:05+00:00 info WS2P: Could not connect to peer 8M6Xmw61 using `WS2P 90.18.15.127 20901: WS2P connection timeout`
2018-01-12T08:30:21+00:00 info WS2P: Could not connect to peer 4f7QLtNB using `WS2P 88.174.120.187 20900: WS2P connection timeout`
2018-01-12T08:30:36+00:00 info WS2P: Could not connect to peer 5q72uSMo using `WS2P 78.200.20.3 20900: WS2P connection timeout`
2018-01-12T08:30:51+00:00 info WS2P: Could not connect to peer 5ngPdGr8 using `WS2P 78.242.14.140 20900: WS2P connection timeout`
2018-01-12T08:31:01+00:00 warn Unknown reference block of peer
2018-01-12T08:31:05+00:00 info SIDE Block #85655-000004E9 added to the blockchain in 1430 ms
2018-01-12T08:31:05+00:00 warn Unknown reference block of peer
2018-01-12T08:31:06+00:00 info WS2P: Could not connect to peer G2RE9nUM using `WS2P g1.imirhil.fr 53011: WS2P connection timeout`
2018-01-12T08:31:06+00:00 warn Unknown reference block of peer
2018-01-12T08:31:10+00:00 info Matched 3 zeros 000C85DF492AC2D2DBEE5579E4BD32D737CEF6F9529D9A3B4C65D6D78ED28E69 with Nonce = 10300000007698 for block#85176 by 4FgeWz
2018-01-12T08:31:10+00:00 warn Unknown reference block of peer
2018-01-12T08:31:12+00:00 info Matched 3 zeros 0005FDA21B590E7EE30CD32B46EA9929FD0829E936D793882B9617E8B2B57CF3 with Nonce = 10100000007721 for block#85176 by 4FgeWz
2018-01-12T08:31:12+00:00 warn Unknown reference block of peer
2018-01-12T08:31:14+00:00 info ✔ PEER 4FgeWzpW
2018-01-12T08:31:14+00:00 warn WS2P OUT => Document detected 2 times: {"version":10,"currency":"g1","status":"UP","statusTS":1515586569,"hash":"8005649D9D1BC89525D9E5054C49A1263A8E299A55DEC40DB328E77906CD6661","first_down":null,"last_try":null,"pubkey":"4FgeWzpWDQ2Vp38wJa2PfShLLKXyFGRLwAHA44koEhQj","block":"85146-0000038F90569609E67503B1EE6441B3C57318A580783A165113B7E5B3F07743","signature":"mMxpQxxtUmuBCMConMDMed9ZajC5O3dmjPa39ZO0WuZj6Cb9Efn+jhuySfeR9AY/zgIR1uVu4+mIduU/bd2rBA==","endpoints":["BASIC_MERKLED_API duniter.rml9-lehavre.tk 82.246.19.84 443","WS2P 8a96aae0 82.246.19.84 20900"],"raw":"Version: 10\nType: Peer\nCurrency: g1\nPublicKey: 4FgeWzpWDQ2Vp38wJa2PfShLLKXyFGRLwAHA44koEhQj\nBlock: 85146-0000038F90569609E67503B1EE6441B3C57318A580783A165113B7E5B3F07743\nEndpoints:\nBASIC_MERKLED_API duniter.rml9-lehavre.tk 82.246.19.84 443\nWS2P 8a96aae0 82.246.19.84 20900\n"}
2018-01-12T08:31:14+00:00 info Next peering signal in 10 min
2018-01-12T08:31:15+00:00 info SIDE Block #85176-000001A2 added to the blockchain in 1217 ms
2018-01-12T08:31:16+00:00 warn Unknown reference block of peer
2018-01-12T08:31:18+00:00 info SIDE Block #85656-000007D8 added to the blockchain in 112 ms
2018-01-12T08:31:18+00:00 warn Unknown reference block of peer
2018-01-12T08:31:21+00:00 info SIDE Block #85657-000003EE added to the blockchain in 1586 ms
2018-01-12T08:31:22+00:00 info WS2P: Could not connect to peer GMyxzVDp using `WS2P 90.18.15.127 20900: WS2P connection timeout`
2018-01-12T08:31:22+00:00 info ⬇ TX 0:9000 from sPdb9y2mK6SiY7YH3mBoNxFwZ592VyLdT3tnsukcYrj
2018-01-12T08:31:22+00:00 warn Unknown reference block of peer
2018-01-12T08:31:23+00:00 info ✘ TX 0:9000 from sPdb9y2mK6SiY7YH3mBoNxFwZ592VyLdT3tnsukcYrj
2018-01-12T08:31:23+00:00 warn Wrong blockstamp for transaction
2018-01-12T08:31:25+00:00 warn Unknown reference block of peer
2018-01-12T08:31:27+00:00 info Block resolution: 1 potential blocks after current#85175...
2018-01-12T08:31:37+00:00 info WS2P: Could not connect to peer pnSrZARn using `WS2P 78.237.23.205 20900: WS2P connection timeout`
2018-01-12T08:31:37+00:00 info Blocks were not applied.
12

Je ne suis pas sous Yunohost mais j’ai le même problème sur un Raspberry Pi3. Et ceci depuis quelques jours.
Bizarre :thinking:

13

Il me semble qu’il faut resynchroniser son noeud avant de le relancer quand il a trop de retard car sinon il reste bloqué là.

14

Cela signifie que ton noeud s’est bloqué dans un fork, une branche qui a été abandonnée, en principe il finit généralement tout seul par dépiler jusqu’a point de fork puis rempiler la bonne branche mais cela peut etre long et ne peut survenir que si ton noeud établi des connections ws2p.

Parfois il faut resync entièrement :

duniter reset data
duniter sync NODE PORT
15

En fait non c’est seulement en cas de fork. Il y a qq jours j’ai un noeud qui a rattraper 7000 blocs de retard sans sync :wink: (il est remonté de 78000 à 85000)