Quand Service Commander, un serveur MCP et une locale pakistanaise décident de compliquer votre journée
Ces derniers jours, j’ai installé un serveur MCP IBM i en m’appuyant sur Service Commander. Une opération qui, sur le papier, semblait relativement simple : installer le serveur MCP, créer le service par service commander pour faciliter l’exploitation.
Pourtant, je me suis retrouvé face à un comportement particulièrement déroutant. Et c’est là que l’utilisation de l’IA (BOB en l’occurrence) s’est révélée extrêmement intéressante.
Le symptôme : ça marche… sauf quand ça ne marche pas
Le serveur MCP démarrait parfaitement lorsque je lançais cette commande avec le profil MCPSERVER créé pour l’occasion :
sc start ibmi-mcp-server
Mais avec mon profil habituel, j’obtenais systématiquement un message d’erreur, ou alors un message de complétion mais le serveur MCP était inactif.
Le détail intriguant était que le service était pourtant configuré pour soumettre le job sous le profil MCPSERVER :
sbmjob_opts: 'JOBQ(QUSRNOMAX) USER(MCPSERVER)'
En théorie, le profil appelant n’aurait donc pas dû avoir d’importance.
La tentation du mauvais diagnostic
Le premier réflexe est de suspecter :
- un problème de droits ;
- un problème de PATH ;
- une configuration npm ;
- Node.js ;
- la configuration MCP ;
- ou encore Service Commander lui-même.
J’ai commencé à analyser les jobs, les spools, les variables d’environnement et les traces de démarrage.
Rapidement, une chose est apparue : le job était bien soumis sous MCPSERVER, mais l’environnement du processus n’était pas toujours cohérent.
Une découverte intéressante
Les premiers logs montraient que lorsque le démarrage était demandé par NB, certaines informations restaient liées à ce profil :
HOME=/home/NB
USER=nb
LOGNAME=nbalors que le job tournait sous MCPSERVER.
J’ai donc modifié la configuration pour désactiver l’héritage implicite de l’environnement :
environment_is_inheriting_vars: false
et défini explicitement les variables nécessaires.
Le comportement a changé, mais le problème n’était toujours pas totalement résolu.
Le vrai coupable : la commande de démarrage
Pendant plusieurs itérations, j’ai tenté de simplifier la définition du service :
start_cmd: /QOpenSys/pkgs/bin/bash -lc 'exec npx ...'
Curieusement :
- la commande fonctionnait sous MCPSERVER ;
- la même commande échouait lorsqu’elle était lancée par NB.
J’ai alors déplacé toute la logique de démarrage dans un wrapper (un shell script start-mcp.sh) :
#!/QOpenSys/pkgs/bin/bash
export HOME=/home/MCPSERVER
export USER=MCPSERVER
cd /projet/ibmi-mcp-server
exec npx -y @ibm/ibmi-mcp-server@latest \
--transport http \
--tools ./toolsPuis :
start_cmd: /projet/ibmi-mcp-server/start-mcp.sh
Et là, miracle :
- démarrage depuis MCPSERVER : OK ;
- démarrage depuis NB : OK.
La configuration devenait à la fois plus robuste et plus lisible.
Le deuxième mystère : une locale pakistanaise
Comme si cela ne suffisait pas, les logs contenaient également des messages du type :
Objet introuvable. L'objet est FR_FR.UTF-8.
warning: setlocale: LC_ALL: cannot change locale (ur_PK.UTF-8)
Pourquoi un serveur IBM i situé en France essayait-il d’utiliser une locale pakistanaise ?
Après investigation, j’ai découvert que Service Commander contient la logique suivante :lorsque aucune locale UTF-8 n’est définie dans l’environnement, Service Commander choisit simplement… la dernière locale (par ordre alphabétique) UTF-8 trouvée sur le système.
Sur ma machine, c’était : ur_PK.UTF-8, c’est-à-dire :
- ur = ourdou
- PK = Pakistan
D’où le message surprenant.
La solution a finalement consisté à définir explicitement :
export LC_ALL=FR_FR.UTF-8@euro
dans ~/.profile et ~/.bashrc
Depuis, plus aucun avertissement.
Et BOB dans tout ça alors ?
Ce que l’IA m’a réellement apporté ?
La partie la plus intéressante de cette aventure n’est pas le problème technique lui-même, j’aurais fini par trouver la solution. Les indices étaient là :
- les spools ;
- les joblogs ;
- les variables d’environnement ;
- le comportement différent selon le profil utilisé.
Mais cela m’aurait probablement pris plusieurs heures supplémentaires, que j’aurais réparti sur plusieurs jours.
L’IA n’a pas « résolu le problème à ma place ». Elle n’a pas eu accès à ma machine (je vous rappelle que j’installais le serveur MCP à ce moment là), à mes commandes ou à la documentation interne de mon environnement.
En revanche, elle a joué un rôle extrêmement utile :
- proposer des pistes d’investigation ;
- analyser rapidement les spools ;
- repérer les incohérences ;
- suggérer des vérifications ciblées ;
- éliminer de nombreuses hypothèses ;
- structurer le raisonnement.
En pratique, elle s’est comportée comme un collègue expérimenté assis à côté de moi, capable de relire instantanément chaque log et de suggérer la prochaine étape.
J’hallucine ?
Pas beaucoup sur cette affaire là ! Pas de commande (shell ou IBM i) extravagante, de boucle dans les réponse, d’idée totalement saugrenue.
Attention, plusieurs critères à prendre en compte :
- je connais le sujet
- j’ai fait des prompts verbeux et précis
- j’ai détecté les mauvaises pistes ET donner les informations pour que BOB comprenne pourquoi c’est une mauvaise piste
Ce que je retiens
L’apport principal de BOB dans ce type de situation n’est pas le remplacement de l’expertise.
C’est l’accélération du diagnostic.
Mon expertise IBM i m’a permis d’interpréter les résultats, de comprendre les implications et de valider les solutions. L’IA, elle, m’a aidé à parcourir beaucoup plus rapidement l’arbre des hypothèses possibles.
Résultat :
- un serveur MCP fonctionnel ;
- une configuration Service Commander plus robuste ;
- une anomalie de locale identifiée et corrigée ;
- et quelques heures gagnées sur une enquête qui aurait probablement été bien plus longue en solitaire.
Et, accessoirement, j’ouvrirais une issue sur la gestion des locales par service commander !
