Réparer l'agent
Rétablissez un serveur injoignable en réparant ou réinstallant l'agent Servor depuis la barre supérieure ou les paramètres du serveur.
Quand un serveur affiche injoignable, c'est que son agent ne communique plus avec Servor. Cette page explique ce que signifie cet état et comment ramener le serveur en connecté en réparant ou réinstallant l'agent — généralement en moins d'une minute.
Ce que signifie « injoignable »
Tout ce que vous faites au quotidien — le terminal web, l'exécution de commandes et les métriques de ressources en temps réel — transite par l'agent installé sur le serveur, et non par SSH. Ainsi, quand l'agent cesse de répondre, Servor marque le serveur injoignable, même si la machine se porte bien et que vous pouvez toujours vous y connecter en SSH.
Raisons courantes pour lesquelles l'agent se tait :
- Le serveur a redémarré et le service de l'agent n'est pas remonté.
- Le processus de l'agent a planté ou a été arrêté.
- La machine a perdu son accès Internet sortant (l'agent se connecte vers Servor).
- L'agent a été désinstallé ou ses fichiers ont été supprimés.
« Injoignable » concerne l'agent, pas la machine
Un serveur peut être parfaitement sain et afficher malgré tout « injoignable » : cela signifie seulement que Servor ne parvient pas à joindre l'agent. Si SSH fonctionne mais que le serveur est injoignable dans Servor, la solution est de réparer l'agent, pas de repasser par SSH.
Réparer depuis la barre supérieure
Lorsqu'un de vos serveurs devient injoignable, Servor le signale dans la barre supérieure pour que vous puissiez agir sans fouiller votre liste.
Ouvrez l'alerte dans la barre supérieure
Un serveur injoignable apparaît dans la barre supérieure. Cliquez dessus pour ouvrir l'invite de réparation de ce serveur.
Choisissez Réparer l'agent
Servor vous fournit une nouvelle commande d'installation — la même commande en une ligne que lors de l'ajout du serveur. Copiez-la.
Exécutez-la sur le serveur
Collez la commande dans un shell sur la machine et lancez-la. L'installeur remplace l'agent par une version propre et redémarre le service. L'exécution est sans risque même sur une installation existante.
Regardez-le se reconnecter
En quelques secondes, le serveur repasse en connecté avec un statut vert.
Réparer depuis les paramètres du serveur
Vous pouvez aussi réparer depuis les paramètres du serveur lui-même — pratique si vous êtes déjà sur sa page.
Ouvrez les paramètres du serveur
Dans vos serveurs, ouvrez le serveur, puis cliquez sur l'icône engrenage pour ouvrir les paramètres. On y trouve les informations du serveur, les seuils de surveillance, la réparation de l'agent et la suppression.
Choisissez Réparer l'agent
Dans la section de l'agent, choisissez Réparer l'agent pour obtenir la commande de réinstallation.
Exécutez la commande et patientez
Lancez-la sur la machine comme ci-dessus. Le serveur se reconnecte de lui-même dès que l'agent est de nouveau opérationnel.
Réinstaller est sans danger
La commande d'installation est idempotente : la relancer sur une machine qui avait déjà l'agent ne fait que le réparer. Vous ne perdez ni le serveur, ni son historique, ni ses moniteurs.
Un agent qui ne se met plus à jour
L'agent se met à jour tout seul : une nouvelle version est prise en compte en moins d'une minute, puis il redémarre dès qu'aucune commande ni aucun terminal n'est en cours. S'il tourne toujours sur une ancienne version 30 minutes après la publication, la page du serveur affiche un bandeau L'agent n'arrive pas à se mettre à jour, avec la version installée et celle disponible.
L'ancienne version continue de fonctionner : surveillance, terminal et commandes restent disponibles. Elle peut donc installer la nouvelle elle-même.
Cliquez sur Mettre à jour l'agent et confirmez
Réservé aux administrateurs, sur les serveurs Linux. Votre coffre doit être déverrouillé : la mise à jour est une commande signée, comme toutes les autres. L'agent redémarre sans attendre d'être inactif : les terminaux ouverts et les commandes en cours sur le serveur sont coupés, d'où la confirmation.
Le binaire est contrôlé avant d'être installé
Votre navigateur contrôle que le binaire est signé par la clé de publication de
Servor — la même vérification que fait l'agent lors d'une mise à jour
automatique, ni plus ni moins — puis signe une commande qui ne remplace l'agent
que si le fichier téléchargé correspond exactement à cette version. L'ancien
binaire est conservé à côté, sous /opt/servor-agent/servor-agent.prev.
L'agent redémarre sur la nouvelle version
Le bandeau disparaît dès que l'agent se reconnecte, en quelques secondes. La commande apparaît dans l'historique des commandes et le journal d'audit.
Sur Windows, ou si la mise à jour échoue (utilisateur sans sudo sans mot de
passe, machine sans systemd…), utilisez Réparer l'agent dans le même bandeau.
Un e-mail au bout d'un jour
Si des agents restent en retard plus de 24 heures, les administrateurs et le propriétaire de l'équipe reçoivent un seul e-mail qui liste tous les serveurs concernés. Chaque agent bloqué n'est signalé qu'une fois ; il ne le sera de nouveau que s'il se bloque encore après s'être remis à jour.
Quand la réparation ne suffit pas
Si l'agent se reconnecte puis retombe, ou ne revient jamais après réinstallation, le problème vient généralement de la machine ou du réseau :
- Redémarrages fréquents ? Assurez-vous que le service de l'agent est activé au démarrage (l'installeur le configure ; une machine durcie sur mesure peut le bloquer).
- Pas d'accès sortant ? L'agent doit pouvoir joindre Servor sur Internet. Vérifiez les pare-feux et les règles de sortie.
- Problème de pare-feu ou d'amorçage SSH ? Suivez la liste complète dans Problèmes de connexion.
Lire le journal de l'agent
L'agent écrit dans son propre espace de noms de journal, pour qu'une boucle de logs ne puisse jamais chasser les journaux du reste de la machine. Conséquence à connaître : la commande habituelle ne montre rien de l'agent.
# Ce que tout le monde tape — et qui ne renvoie que les lignes de systemd :
journalctl -u servor-agent
# Ce qu'il faut taper pour voir l'agent lui-même :
journalctl --namespace=servor -u servor-agent -n 100
journalctl --namespace=servor -u servor-agent -f # en directLa commande exacte figure aussi dans la description de l'unité : systemctl status servor-agent l'affiche en première ligne. Sur un hôte dont systemd est antérieur à
la version 245, il n'y a pas d'espace de noms et journalctl -u servor-agent suffit.
Ce que vous y cherchez en cas de terminal injoignable :
tunnel authenticated— le tunnel est monté ; le problème est ailleurs.tunnel heartbeat timed out — reconnecting— le canal est mort et l'agent le reprend tout seul.tunnel down for 120s — 12 attempt(s), still retrying— il réessaie sans y arriver : regardez l'accès sortant vers Servor en WebSocket.tunnel flapped … pausing reconnects— deux agents partagent le même serveur. Réinstallez l'agent sur un seul hôte.