Linux - Administration applicative
Ce que doit maîtriser un responsable technique d'applications : services, logs, droits, cron, scripts et surveillance système - pas un sysadmin, mais pas un débutant.
systemd
Démarrer, arrêter, diagnostiquer un service.
Logs
Lire, filtrer, croiser les journaux.
Droits
Permissions, utilisateurs applicatifs, sudo.
Cron
Planification, syntaxe, diagnostic.
Shell
Lire et modifier des scripts existants.
Surveillance
Mémoire, disque, processus, réseau.
systemd
Gestion des services
Démarrer, arrêter, diagnostiquer - au quotidien
systemd est le gestionnaire de services de Linux. Chaque application (Tomcat, Apache…) tourne comme un service qu'on peut démarrer, arrêter et surveiller. La différence entre restart et reload est importante : restart coupe puis redémarre le processus, reload relit la configuration sans interruption de service.
Commandes essentielles
| sudo systemctl start nom-service | Démarrer un service |
| sudo systemctl stop nom-service | Arrêter un service |
| sudo systemctl restart nom-service | Redémarrer (coupe + relance le processus) |
| sudo systemctl reload nom-service | Relire la config sans couper le service |
| sudo systemctl status nom-service | État détaillé : running / failed + derniers logs |
| sudo systemctl enable nom-service | Démarrage automatique au boot |
| sudo systemctl disable nom-service | Désactiver le démarrage automatique |
| sudo systemctl list-units --type=service | Lister tous les services et leur état |
Lire un status
La commande
systemctl status affiche l'état (active (running) ou failed), depuis combien de temps le service tourne, et les dernières lignes de log. C'est souvent le premier réflexe avant d'aller dans les logs complets.
Logs via journalctl
| journalctl -u tomcat10 | Tous les logs du service Tomcat |
| journalctl -u tomcat10 -f | Suivre les logs en temps réel |
| journalctl -u tomcat10 --since "1 hour ago" | Logs de la dernière heure |
| journalctl -u tomcat10 -n 50 | Les 50 dernières lignes |
| journalctl -p err -u tomcat10 | Uniquement les erreurs |
Logs
Lecture et analyse des logs
Filtrer, croiser, reconstituer un incident
Les logs sont la première source d'information lors d'un incident. L'essentiel est de savoir naviguer rapidement dans /var/log, filtrer ce qui est pertinent et, quand nécessaire, croiser plusieurs fichiers pour reconstituer la chronologie d'un problème.
Se repérer dans /var/log
/var/log/syslog - journal système général
/var/log/auth.log - connexions et sudo
/var/log/apache2/ - logs Apache (access.log, error.log)
/opt/tomcat/logs/ - logs applicatifs Tomcat
/var/log/cron ou journalctl - exécutions cron
/var/log/auth.log - connexions et sudo
/var/log/apache2/ - logs Apache (access.log, error.log)
/opt/tomcat/logs/ - logs applicatifs Tomcat
/var/log/cron ou journalctl - exécutions cron
Commandes de base
| tail -f fichier.log | Suivre en temps réel ★ - lancer avant de reproduire l'erreur |
| tail -n 100 fichier.log | Afficher les 100 dernières lignes |
| less fichier.log | Naviguer dans un fichier (q pour quitter, G pour fin, / pour chercher) |
| cat fichier.log | Afficher tout le fichier - à éviter sur les gros logs |
Filtrer avec grep
| grep "ERROR" fichier.log | Lignes contenant ERROR |
| grep -i "exception" fichier.log | Insensible à la casse |
| grep -v "INFO" fichier.log | Exclure les lignes INFO |
| grep "2026-05-07" fichier.log | Filtrer par date |
| grep -i "exception" fichier.log | tail -50 | Les 50 dernières exceptions - combinaison utile |
| grep -A 5 "ERROR" fichier.log | 5 lignes après chaque erreur (contexte) |
Croiser plusieurs logs pour reconstituer un incident
- 1Identifier l'heure signalée par l'utilisateur
- 2Filtrer catalina.out sur cette heure :
grep "10:45" catalina.out - 3Chercher l'erreur la plus proche :
grep -i "error\|exception" catalina.out | grep "10:4" - 4Vérifier Apache en parallèle :
grep "10:45" /var/log/apache2/error.log - 5Remonter la cause : datasource ? script SQL manquant ? version applicative ?
Droits
Droits et permissions
Lire un ls -l, corriger un accès refusé, utilisateurs applicatifs
Sous Linux, chaque fichier appartient à un propriétaire et à un groupe. Les permissions définissent ce que chacun peut faire : lire (r), écrire (w), exécuter (x). En tant que responsable applicatif, l'essentiel est de comprendre pourquoi une application ne peut pas lire un fichier de config, et comment corriger ça.
Lire un ls -l
Le premier bloc de 9 caractères se découpe en 3 groupes de 3 :
-rwxr-xr-- 1 tomcat tomcat 4096 mai 7 context.xmlLe premier bloc de 9 caractères se découpe en 3 groupes de 3 :
rwx
Propriétaire
peut tout faire
peut tout faire
r-x
Groupe
lit et exécute
lit et exécute
r--
Autres
lecture seule
lecture seule
Commandes courantes
| ls -lh /opt/tomcat/conf/ | Voir les droits et propriétaires des fichiers |
| chown tomcat:tomcat fichier | Changer le propriétaire et le groupe |
| chmod 640 fichier | Droits : propriétaire rw, groupe r, autres rien |
| chmod +x script.sh | Rendre un script exécutable |
| id nom-utilisateur | Voir les groupes d'un utilisateur |
| whoami | Vérifier sous quel utilisateur on tourne |
Utilisateurs applicatifs - pourquoi c'est important
- →Tomcat tourne sous un utilisateur dédié (ex:
tomcat) - jamais root - →Si un fichier de config n'appartient pas à cet utilisateur, Tomcat ne peut pas le lire → erreur au démarrage
- →Après avoir déposé un WAR ou modifié un fichier de config : vérifier que l'utilisateur Tomcat est propriétaire
- →Ne jamais modifier les sudoers sans savoir exactement ce qu'on fait
Cron
Cron et automatisation
Lire la syntaxe, lister les tâches, diagnostiquer une non-exécution
Cron est le planificateur de tâches Linux. Il permet d'exécuter automatiquement des scripts à des horaires définis - sauvegardes, purges de logs, exports de données. En tant que responsable applicatif, l'essentiel est de savoir lire une ligne cron, vérifier qu'une tâche s'est exécutée, et diagnostiquer un oubli.
La syntaxe cron - 5 champs
Chaque ligne cron commence par 5 champs définissant le moment d'exécution :
*Minute
0–59
0–59
*Heure
0–23
0–23
*Jour du mois
1–31
1–31
*Mois
1–12
1–12
*Jour semaine
0=dim
0=dim
Exemples à retenir
- ex
0 2 * * * /opt/scripts/backup.sh- tous les jours à 2h00 - ex
*/15 * * * * /opt/scripts/check.sh- toutes les 15 minutes - ex
0 8 * * 1 /opt/scripts/rapport.sh- chaque lundi à 8h00 - ex
0 0 1 * * /opt/scripts/purge.sh- le 1er de chaque mois à minuit
Commandes utiles
| crontab -l | Lister les crons de l'utilisateur courant |
| crontab -l -u tomcat | Lister les crons d'un utilisateur spécifique |
| crontab -e | Éditer les crons de l'utilisateur courant |
| ls /etc/cron.d/ | Crons système des applications installées |
| ls /etc/cron.daily/ | Scripts exécutés chaque jour par le système |
| journalctl | grep CRON | Vérifier les exécutions cron dans les logs système |
Diagnostiquer une tâche qui ne s'exécute pas
1. Vérifier que la tâche existe bien :
2. Vérifier que le script est exécutable :
3. Chercher une trace dans les logs :
4. Tester le script manuellement sous le bon utilisateur
crontab -l -u tomcat2. Vérifier que le script est exécutable :
ls -lh /opt/scripts/backup.sh3. Chercher une trace dans les logs :
journalctl | grep CRON | grep backup4. Tester le script manuellement sous le bon utilisateur
Shell
Scripts shell - lecture et modification
Comprendre et adapter sans réécrire de zéro
L'objectif n'est pas d'écrire des scripts complexes, mais de savoir lire un script existant et modifier un paramètre sans le casser. Les scripts de déploiement, de sauvegarde ou de purge de logs fournis par les éditeurs suivent tous des patterns similaires.
Les éléments à reconnaître
- #!/La première ligne
#!/bin/bashindique que c'est un script bash - $Les variables :
NOM="valeur"puis utilisées avec$NOM - ifLes conditions :
if [ condition ]; then ... fi - forLes boucles :
for f in /opt/logs/*.log; do ... done - #Les commentaires : tout ce qui suit
#est ignoré - lire les commentaires en premier
Modifier un script en toute sécurité
| cp script.sh script.sh.bak | Toujours sauvegarder avant de modifier |
| nano script.sh | Éditer (ou vim si on est à l'aise) |
| chmod +x script.sh | Rendre exécutable si ce n'est pas déjà le cas |
| bash -n script.sh | Vérifier la syntaxe sans exécuter |
| bash script.sh | Tester manuellement avant de remettre en cron |
| diff script.sh script.sh.bak | Vérifier ce qu'on a changé |
Ce qu'on modifie le plus souvent
Les chemins de répertoires, les noms de bases de données, les identifiants de connexion, les durées de rétention (purge de logs), les adresses de serveurs. Ces valeurs sont généralement en haut du script sous forme de variables - c'est là qu'il faut regarder en premier.
Surveillance
État du système
Mémoire, disque, processus, réseau - détecter avant que ça plante
La surveillance n'est pas le territoire du sysadmin seul. En tant que responsable applicatif, savoir repérer rapidement qu'une partition est pleine, qu'un processus consomme anormalement ou qu'un port ne répond plus fait partie du diagnostic de premier niveau.
Mémoire
| free -h | Vue rapide : RAM utilisée / disponible / swap |
| top | Vue temps réel - processus triés par consommation CPU |
| htop | Comme top, plus lisible - q pour quitter |
| ps aux --sort=-%mem | head -10 | Les 10 processus qui consomment le plus de RAM |
Disque - critique pour les logs
| df -h | Espace disponible par partition ★ - surveiller régulièrement |
| du -sh /opt/tomcat/logs/ | Taille occupée par les logs Tomcat |
| du -sh /var/log/* | Identifier les gros fichiers de logs système |
| du -sh * | sort -hr | head -10 | Top 10 des répertoires les plus lourds |
Processus
| ps aux | grep tomcat | Vérifier que le processus Tomcat tourne |
| kill PID | Arrêter proprement un processus (signal TERM) |
| kill -9 PID | Forcer l'arrêt - dernier recours si kill ne suffit pas |
| pgrep -a tomcat | Trouver le PID de Tomcat avec son chemin |
Réseau et connectivité
| ping serveur-oracle | Tester que le serveur Oracle est joignable |
| telnet serveur-oracle 1521 | Tester que le port Oracle 1521 est ouvert |
| nc -zv serveur-oracle 1521 | Alternative moderne à telnet |
| curl -I http://localhost:8080 | Tester qu'un service HTTP répond |
| ss -tlnp | grep 8080 | Vérifier que Tomcat écoute sur le bon port |
| netstat -tlnp | grep 8080 | Même résultat (commande plus ancienne) |
Réflexe disque plein
Un disque plein est l'une des causes les plus fréquentes de plantage applicatif silencieux - Tomcat tourne mais n'écrit plus rien, les données se perdent. Si une application se comporte bizarrement sans erreur évidente :
df -h en premier.
Les réflexes à avoir
Une application ne répond plus : systemctl status → tail -f catalina.out → df -h. Dans cet ordre.
Un fichier de config illisible : vérifier le propriétaire avec ls -lh, corriger avec chown.
Une tâche planifiée qui ne tourne pas : crontab -l → vérifier les droits du script → tester manuellement.
systemd - services
Logs - grep et tail
Droits - chown et chmod
Cron - planification
Shell - lire et adapter
Surveillance - df et free