Annotation: Apple Remote Desktop client ne répond plus

{0 Comments}

 

ARDSi l’on administre à distance de Macs régulièrement par le biais de Apple Remote Desktop, tôt ou tard il est statistiquement probable qu’une de ces machines ne réponde plus à la prise de contrôle.

Les raisons peuvent être multiples selon l’environnement réseau de ces machines, mais en principe, si le problème est clairement localisé au niveau du client ARD, la solution de réparation à distance passe souvent par un bon coup de kickstart

Solution efficace nécessitant d’une connexion ssh sur le client récalcitrant, elle est clairement documentée par Apple dans le kb suivant:

http://support.apple.com/kb/HT2370?viewlocale=fr_FR

Il existe, néanmoins un déclencheur bien plus sournois, immun au kickstart qui se manifeste régulièrement;
Raison qui me pousse à l’annoter ici.

Il s’agit du blocage par session « accrochée »

Je m’expliqué: le problème se manifeste aussi par de longues tentatives de connexion vouées à l’échec, mais dans ce cas le kickstart ne résolut pas la situation.

Pour cause: l’indice qui caractérise ce problème est la présence de deux instances ARDAgent (Apple Remote Desktop Agent) sur la machine récalcitrante.

Présence multiple conflictuelle qui empêche toute connexion et interaction avec le client.

Cet état de fait est vérifiable sur la machine par la ligne de commande suivante:

ps -ax | grep ARDAgent

Résultat:

72696 ?? 0:00.05 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgen

72697 ?? 0:00.01 /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/MacOS/ARDAgent

La caractéristique qui rend plus insidieux ce problème est la suivante:

Launchd est chargé de suivre et de redémarrer le service ARD en cas de stop inopiné rendant ainsi inefficace toute tentative de kill des processus. (!)

Dans un tel cas de figure normalement la seule issue est un redémarrage, chose aisée sur un post client, mais pas toujours réalisable sur un serveur.

Quand toutes les options habituelles de récupérations échouent, la seule option possible si l’on exclut le redémarrage est de comprendre la cause sous-jacente au problème.

La présence de deux instances est effectivement un indice probable d’une session de contrôle à distance qui est resté « bloquée » suite à extinction inopinée ou coupure réseau.

À fin de vérifier cette hypothèse un premier réflexe consiste à « convaincre » Launchd a ne pas redémarrer les ARDAgent automatiquement

En regardant de prêt la plist chargée d’indiquer le mode de fonctionnement de ARD à Launchd (/System/Library/LaunchAgents/com.apple.RemoteDesktop.plist) nous constatons que ce dernier se base sur la présence du fichier /etc/RemoteManagement.launchd pour savoir si le client est activé ou pas (si la case Gestion à distance est activée dans système Preferences–> réseau dans le GUI)

En effet ce fichier qui ne contient qu’une simple énoncé « Enabled », par sa présence indique à Launchd que le service est présent et qu’il faut, donc, le garder en vie.

Il suffit, donc, de le renommer avec un

sudo mv /etc/RemoteManagement.launchd /etc/RemoteManagement.launchdOLD

pour déclencher la désactivation automatique du service.

Ainsi faisant nous désactivons le redémarrage automatique et probablement avant de quitter, Launchd arrivera a stopper un des deux services.
Le cas échéant nous pouvons procéder maintenant par un kill sélectif qui devrais, cette fois, avoir raison de un de deux daemons.

Cette première démarche nous a permit d’isoler le ARDAgent bloquée. Moitié du chemin.

Nous somme intervenu au niveau du lanceur, cherchons maintenant le déclencheur: à ce fin un bon indice consiste à vérifier qui est connecté à la machine, typiquement par la ligne commande who

Si cette dernière nous signale la présence d’un utilisateur en mode console (session graphique) et que la date d’ouverture de cette dernière est ancienne et/ou si l’on sait que personne est sensé être connecté en mode graphique, nous pouvons vraisemblablement affirmer que c’est bien cette session qui a du bloquer.

En ayant établi le diagnostic nous pouvons résoudre le problème en travaillant à l’amont.

Effectivement pour une connexion ARD correspondent probablement une session graphique ouverte et techniquement l’agent ARD est dépendent de cette dernière.

Il suffit, donc, de s’attaquer à la session graphique bloquée par un kill du service qui la gère: loginwindow

Nous pouvons procéder par la ligne de commande suivante:

sudo killall loginwindow

Ce reset vas libérer le ARDAgent bloqué et nous permettre de le nettoyer.

Nous pouvons des à present réactiver le service ARD en remettant à ça place le fichier précédemment renommée:

sudo mv /etc/RemoteManagement.launchdOLD /etc/RemoteManagement.launchd

Cette fois un seule et légitime ARDAgent devrais démarrer et la prise de contrôle à distance devrait être rétablie.

Leave a Comment

Your email address will not be published.

*