 |
C'est passé en réessayant ce matin, mais je laisse ouvert pour qu'on ait un moyen plus fiable que d'attender 24 heures. |
 |
C'est qu'il y avait une tâche de backup déjà en cours. Si ça prend 24h, il faut attendre que ça finisse : arrêter un rdiff-backup en cours, c'est flinguer TOUS les backups suivants. |
|
|
Hmmm, dans ce cas faudrait un moyen fiable de savoir quand un backup "régulier" est toujours en cours ou non. Mais de toute évidence faudrait trouver un autre moyen pour le runner d'accéder aux vidéos en lecture seule sur Shelter plutôt, ça éviterait ce genre de soucis. Je sais pas quel est le moyen le plus fiable pour le runner d'y avoir accès sans que ça soit trop chiant à gérer. Ou alors il faut lancer ce job-là (et uniquement celui-là) sur Shelter et pas sur Bunker. C'est pas le plus consommateur en ressources (il prend 6 minutes à tout casser) |
|
|
J'ai ajouté du verbose sur le script. Pour ce qui est de lancer le job sur Shelter, il bouffe quand même pas mal de ressource car beaucoup d'accès I/O : si tu veux te retrouver dans la même situation que l'ancien shelter, je ne prends plus la responsabilité du support et j'enverrai chier toute personne qui se plaindra de lenteur. |
|
|
Est-ce que c'est mieux niveau verbosité / détail ? |
|
|
J'avais noté le message indiquant qu'un backup était déjà en cours et que du coup c'était "bloqué" ce qui est cool. Je suis allé voir un log de job et ouais c'est pas mal. Un truc bien serait d'ajouter date et heure à ce qui est affiché, histoire de, après on pourra fermer l'issue je pense, vu qu'on aura une meilleure visibilité sur pourquoi ça bloque. |
|
|
J'ajoute ça tout à l'heure |
|
|
Change poussé et plus de debug, on ferme |
- Anonymous
