Administrateur & Développeur système UNIX/Linux

Parfois, il est indispensable de tester son application sous un environnement précis. Si cela ne tourne pas rond, un debug est nécessaire. Pour conserver les mêmes conditions d’exécution, un debug distant depuis son IDE est possible. Le principe est qu’une connexion réseau est faite entre le frontend du débogueur (IDE) et un backend au niveau de la JVM (JDPA, Java Debug Architecture). Deux méthodes sont possibles  :

• « Socket attach » : une socket est en écoute au niveau de la JVM. L’IDE va s’y connecter pour contrôler le flux d’exécution et récupérer les informations de debug.
• « Socket listen » : une socket est en écoute sur la machine de développement. Dans ce cas, la JVM s’y connecte pour ensuite être contrôlée.

Le choix entre les 2 méthodes dépend du filtrage réseau présent entre les 2 postes. Des options spécifiques sont donc à fournir à la JVM dont l’adresse IP / port de la socket et la méthode de remote debug.

Avec Eclipse, un remote debug par socket attach se fait ainsi :

1. Compilation des sources avec les options de debug (sans blague)
2. Déploiement / lancement de l’application sur la machine de test :
   

   java -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=8000 [...]

3. Lancer l’application depuis l’IDE avec une configuration de remote debug en précisant l’IP + port du serveur d’exécution : menu Run -> Debug … -> Remote Java Application.

Le reste s’effectue comme un debug traditionnel.

Screenshot 1 : lancement de la JVM d’exécution avec backend JDPA
Screenshot 2 : configuration debug avec l’IP/port du serveur d’exécution
Screenshot 3 : session de debug distante

Le démon nscd chargé de gérer le cache de résultats des services de noms a la fâcheuse tendance de crasher toutes les 10 minutes +/- sur un système Linux 64 bits. Ceci est très problématique dans le cas d’un serveur LDAP, car il permet justement d’optimiser les requêtes LDAP courantes. Son crash interrompt de plus le fonctionnement du serveur (et des clients LDAP).

L’unique solution est de privilégier un équivalent – mieux codé – dénommé unscd.

Voici le script de démarrage  que j’utilise pour Gentoo/amd64 et qui manque dans le port :

#!/sbin/runscript
#
# Boris HUISGEN, <bhuisgen@hbis.fr>

depend() {
   use dns ldap net slapd
}

checkconfig() {
   if [ ! -d /var/run/nscd ] ; then
      mkdir -p /var/run/nscd
      chmod 755 /var/run/nscd
   fi
}

start() {
   checkconfig
   ebegin "Starting Micro Name Service Cache Daemon"
   start-stop-daemon --start --quiet --exec /sbin/unscd
   eend $?
}

stop() {
   ebegin "Shutting down Micro Name Service Cache Daemon"
   start-stop-daemon --stop --quiet --exec /sbin/unscd
   eend $?
}

# vim:ts=4

Un joli commentaire de la part de son auteur :

It is well known that nscd provided with glibc is buggy.

This leads people to invent babysitters which restart crashed/hung nscd. This is ugly.

After looking at nscd source in glibc I arrived to the conclusion that it’s flawed by design and cannot be fixed. Even if nscd’s own code is 100.00% perfect and bug-free, it can still suffer from bugs in libraries it calls.