[cozy-collect] - Connection Error


#1

Bonjour,

je suis en train de mettre en place les connecteur vers :

  • Darty
  • Direct Energie
  • Free
  • Free Mobile
  • Leclerc Drive
  • Netflix
  • OVH

Lorsque je tente de faire la synchronisation, j’ai systématiquement la même erreur à savoir “Connection Error”, quelque soit le connecteur.

J’ai donc activé les logs via : cozy-stack instances debug moncozy.mondomaine.com true

Pourtant la connexion semble bien se faire car pour free il me retourne bien des noms de factures :

cozy[4732]: time=“2018-10-18T11:12:06+02:00” level=debug msg=“response: {“total_rows”:46,“offset”:13,“rows”:[\r\n{“id”:“bc3c287d9bf7ac5441595f511800915e”,“key”:[“bc3c287d9bf7ac5441595f5118003a4d”,“file”,“201810_free.pdf”],“value”:null,“doc”:{”_id":“bc3c287d9bf7ac5441595f511800915e”,"_rev":“2-a023b70f7f0e01825788001740eff65b”,“type”:“file”,“name”:“201810_free.pdf”,“dir_id”:“bc3c287d9bf7ac5441595f5118003a4d”,“created_at”:“2018-10-17T20:33:00Z”,“updated_at”:“2018-10-17T20:33:00Z”,“size”:“31718”,“md5sum”:“OpBqMmLd6HylLQvSv/DfvA==”,“mime”:“application/pdf”,“class”:“pdf”,“executable”:false,“trashed”:false,“tags”:[]}}\r\n]}" domain=moncozy.mondomaine.com nspace=couchdb

Oct 18 11:12:10 vps248101 cozy[4732]: time=“2018-10-18T11:12:10+02:00” level=debug msg=“File /Administrative/Free/monidentifiant/201710_free.pdf does not exist yet or is not valid” domain=moncozy.mondomaine.com job_id=bc3c287d9bf7ac5441595f51180471b8 nspace=jobs slug=free worker_id=konnector/0

Et j’ai l’erreur suivante :
level=error msg=“error while performing job: exit status 109”

Le connecteur a déjà fonctionné puisque j’avais des factures dans le dossier (Factures que j’ai supprimées pour faire le test)

Merci d’avance pour votre aide


[TUTORIEL] Mise en place COZY V3 en auto-hébergé
#2

En fouillant un peu sur le forum je me rends compte que les logs sont plutôt côté JS.
Quels sont les logs nécessaires pour comprendre le status 109?


#3

Hello,

J’ai invoqué @aeris mais là on ne comprend pas ce qui se passe.

D’après le journal, le connecteur s’exécute correctement, récupère bien des fichiers depuis le site distant, puisqu’on voit des lignes où il regarde si ces fichiers existent déjà sur ton serveur… Je ne comprend pas à quoi correspondent ces exit status 109 :frowning:


#4

Merci @Clochix

je n’ai mis qu’une partie des logs, je peux faire un gros copier coller si cela peut aider à analyser.


#5

Hello,

Je viens de me rendre compte que je n’ai plus eu d’import de docs depuis fin aout.
J’avoue avoir rarement des docs nouveaux…

Après avoir désinstallé les connecteurs et désactiver les comptes, lorsque j’essaie de les réinstaller, rien ne se synchronise. même en mode debug j’ai peu d’infos dans stack.debug.log

Voici le log au moment d’une tentative de synchro de digiposte.

Oct 19 12:40:27 cozyServer cozy[10610]: time=“2018-10-19T12:40:27+02:00” level=info msg=“Konnector failure: exit status 109” account_id=e23c03be498a17d046431d61c7014b36 domain=cozy.domaine.fr job_id=e23c03be498a17d046431d61c701571b nspace=jobs slug=digiposte worker_id=konnector/3
Oct 19 12:40:27 cozyServer cozy[10610]: time=“2018-10-19T12:40:27+02:00” level=error msg=“error while performing job: exit status 109” domain=cozy.domaine.fr job_id=e23c03be498a17d046431d61c701571b nspace=jobs worker_id=konnector/3

Par contre, dans mon cas, il n’y a à aucun moment dans les logs de la stacks des noms de fichiers qui apparaissent.


#6

Hello,

@glelostec je veux bien que tu m’envoies des journaux un peu plus complets à contact chez cozycloud.cc , afin que je soumette aux expert·e·s. Merci !


#7

Hello @cpique,

Merci, vu, ça confirme qu’il semble y avoir un souci en auto-hébergement avec les connecteurs. Nous allons regarder.


#8

Hello @Clochix

Les logs sont envoyés par mail.
Un test sur free et un test sur freemobile.

Bonne recherche !!


#9

Hello @Clochix,

je viens de faire un update upgrade sur le serveur, et les connecteurs refonctionnent, vous avez du embarquer une correction de l’anno dans le dernier package.


#10

… Chez moi cela ne fonctionne toujours pas …
Pour essayer de voir à quel niveau cela coince, dans quel log suis je censé voir les appels pour la connexions aux comptes (Digiposte, Free, etc.) ?

Je m’explique : lorsque je renseigne un mdp qui est erroné, j’ai exactement le même comportement que lorsqu’il est correct.
Même error code 109, même délai, etc.

J’ai trouvé ça :

error 109 Invalid cartridge types

source : https://access.redhat.com/documentation/en-US/OpenShift_Online/2.0/html/Cartridge_Specification_Guide/Exit_Status_Codes.html

Web cartridges are available for a variety of programming languages and frameworks, and an application requires at least one web cartridge to listen to HTTP requests. The type of web framework cartridge must be specified when an application is created. Cartridges that listen to incoming traffic are placed on one or more gears, while other cartridges can be placed across multiple gears of an application.

NodeJS version 0.1

source : https://access.redhat.com/documentation/en-us/openshift_enterprise/2/html/user_guide/chap-cartridges

Pas certain du tout que cela fasse avancer le schmilblick …


#11

Hello,

@glelostec merci, nous avons bien reçu les journaux, mais n’y avons rien trouvéqui explique cette erreur 109 :frowning:

Æris a publié hier vers 17:30 une mise à jour des paquets, qui corrige l’erreur de requête à CouchDB qui crée de gros journaux. Est-ce cette version que tu as installée ?

@cpique merci pour tes recherches, j’avoue ne pas voir le rapport. Et personne dans l’équipe n’est disponible pour creuser :crying_cat_face:


#12

Bonjour @Clochix,

en effet c’est bien vers cette heure là que j’ai mis à jour les packets. Il y a forcément un lien de cause à effet …


#13

\o/
On ne comprend pas plus pourquoi cette mise-à jour pourrait avoir réparé que pourquoi c’était cassé, mais tant mieux si ça fonctionne.

@cpique lorsque tu dis que ça ne fonctionne toujours pas, est-ce après avoir mis à jour ?


#14

@Clochix Oui c’était bien après mise à jour …

Je viens de me rendre compte que les erreurs nginx n’apparaissaient pas dans mondomaine.fr.log mais dans mondomaine.fr.error.log…

Voici ce que j’ai.

2018/10/23 22:28:55 [error] 669#669: *2859 connect() failed (111: Connection refused) while connecting to upstream, client: 2a01:cb08:210:2300:6591:1164:b029:91c2, server: *.cozy.domaine.fr, request: “POST /jobs/triggers/dcc3c405e59c48f81a5c82522200d6cc/launch HTTP/2.0”, upstream: “http://[::1]:8080/jobs/triggers/dcc3c405e59c48f81a5c82522200d6cc/launch”, host: “cozy.domaine.fr”, referrer: “https://collect.cozy.domaine.fr/

En parallèle dans /var/log/couchdb/couchdb.log j’ai ça :

[notice] 2018-10-23T20:31:00.893208Z couchdb@127.0.0.1 <0.10226.7369> aa42e2b5a7 127.0.0.1:5984 127.0.0.1 cozy GET /cozy69187d0eaa5e1b37b3c920c7b0104a8d%2Fio-cozy-konnectors/io.cozy.konnectors%2Fdigiposte 200 ok 29

Est ce que le fait que par moment mon serveur est en IPv6, et d’autres en IPv4 peut être à l’origine de cela ?


#15

La ligne d’erreur dans le journal Nginx est intéressante mais a priori sans rapport avec l’exécution des connecteurs proprement dite.

Tu as essayé depuis l’application Cozy Collect de lancer manuellement l’exécution d’un connecteur (POST /jobs/triggers/dcc3c405e59c48f81a5c82522200d6cc/launch) mais Nginx n’a pas réussi à transmettre la requête au serveur cozy-stack écoutant sur http://[::1]:8080.

C’est une piste.

Mais pas forcément en rapport avec l’erreur rencontrée par le connecteur durant son exécution.


#16

Bon cela fait quelques temps mais voici où j’en suis :
Un curl http://127.0.0.1:8080/version fonctionne bien mais pour un curl http://[::1]:8080/version
j’obtiens bien connection refused !

J’ai modifié ip6tables qui apparemment bloquait tout par défaut.
Cependant cela n’a pas modifié le comportement…

J’ai désactivé complètement ipV6 sur mon serveur (sur les différentes interfaces), J’obtiens maintenant une erreur critique :
2018/11/14 11:18:08 [crit] 661#661: *10 connect() to [::1]:8080 failed (99: Cannot assign requested address) while connecting to upstream, client: x.x.x.x, server: *.cozy.domaine.ovh, request: “GET /assets/fonts/fonts.css HTTP/2.0”, upstream: “http://[::1]:8080/assets/fonts/fonts.css”, host: “cozy.domaine.ovh”, referrer: “https://home.cozy.domaine.ovh.ovh/

Cependant dans cozy.yml j’ai bien
host : 127.0.0.1
port: 8080

Pourquoi diable tente-t-il d’y accéder via l’ipv6 ?


#17

Là j’ai l’impression que le souci ne vient pas de Cozy mais du reverse proxy, non ? Voire du DNS.

Si depuis ton serveur, tu fais un nslookup cozy.domaine.ovh est-ce qu’il te répond une adresse v4 ou v6 ?