Les commandes Linux que tout dev doit connaître

1. Présentation générale

Tout dev a déjà SSH’d sur un serveur, ouvert un terminal pour déboguer ou déployer une appli, puis cherché pendant des heures la bonne commande. Cet article récapitule les commandes Linux les plus utilisées au quotidien : gestion de fichiers, recherche, traitement de texte, suivi des processus, vérification réseau, consultation des logs. Après sa lecture, vous aurez un ensemble de commandes « de survie » pour déboguer rapidement sans avoir besoin de Google à chaque fois.

J’utilise bash sur Ubuntu/Debian comme exemple principal, ces commandes sont pratiquement identiques sur toutes les distributions.

2. Opérations basiques sur les fichiers et dossiers

mkdir -p ~/projects/order-service/src/main/java
cd ~/projects/order-service
touch application.properties
ls -la

mkdir -p crée tout l’arborescence imbriquée, sans erreur si le dossier existe déjà.
touch crée un fichier vide (ou met à jour l’horodatage s’il existe).
ls -la liste tous les fichiers (y compris les fichiers cachés .env, .git) avec les permissions, propriétaire et taille.

drwxr-xr-x  3 nonla nonla 4096 Oct  5 10:00 .
-rw-r--r--  1 nonla nonla    0 Oct  5 10:00 application.properties

Certaines commandes de déplacement/suppression nécessitent de la prudence :

cp -r src/ src-backup/     # copie récursive du dossier
mv OrderService.java OrderServiceImpl.java   # renommage ou déplacement
rm -rf target/            # suppression récursive, sans confirmation

Attention : rm -rf n’a pas de corbeille, une suppression est définitive. Vérifiez toujours le chemin avec pwd avant de l’exécuter, surtout si vous copiez-collez des commandes d’ailleurs.

3. Recherche avec find et grep

3.1. find — rechercher des fichiers selon des critères

find . -name "*.java" -newer pom.xml

Cette commande trouve tous les fichiers .java modifiés après pom.xml — utile quand on veut savoir quel fichier a changé juste avant de committer.

find . -type f -size +10M

Trouve les fichiers plus grands que 10 MB, généralement utilisé pour nettoyer les logs ou les artefacts de build qui consomment de l’espace.

3.2. grep — rechercher du contenu dans les fichiers

grep -rn "PaymentService" --include="*.java" src/

-r recherche de manière récursive dans les sous-dossiers.
-n affiche avec les numéros de ligne.
--include limite à seulement les fichiers .java, évite de fouiller dans target/.

src/main/java/com/nonla/OrderController.java:15:    private final PaymentService paymentService;

Combinez grep avec find via un pipe quand vous avez besoin d’un filtrage plus complexe :

find . -name "*.log" | xargs grep -l "OutOfMemoryError"

xargs passe la liste des fichiers de find à grep -l (affiche seulement le nom du fichier contenant le motif, pas le contenu).

4. Traitement de texte avec awk, sed, cut

Voici un ensemble de commandes « qui mangent les logs » — très puissant quand on a besoin d’extraire des données d’une sortie verbeux.

cat access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -5

awk '{print $1}' récupère la première colonne (généralement l’IP) de chaque ligne de log.
sort | uniq -c groupe et compte les occurrences.
sort -rn trie en ordre décroissant par nombre, head -5 prend les 5 premiers.

    152 192.168.1.10
     98 10.0.0.5
     47 172.16.0.3

C’est le moyen le plus rapide de trouver l’IP qui fait le plus de requêtes sans écrire de script.

sed est utilisé pour remplacer du texte directement dans un fichier :

sed -i 's/spring.profiles.active=dev/spring.profiles.active=prod/' application.properties

-i modifie le fichier directement (in-place). Si vous voulez être plus prudent, utilisez sed -i.bak '...' pour créer automatiquement un fichier de sauvegarde .bak.

cut divise les colonnes par délimiteur, plus léger que awk si vous n’avez besoin que d’une seule colonne :

cat /etc/passwd | cut -d: -f1 | head -3

5. Suivi des processus et ressources système

ps aux | grep java

Affiche tous les processus, filtre les lignes contenant java — moyen rapide de savoir si votre appli Spring Boot est en cours d’exécution et quel est son PID.

nonla    12345  2.1  5.3 2345678 432100 ?      Sl   10:00   0:15 java -jar order-service.jar

La deuxième colonne est le PID. Utilisez ce PID pour killer ou consulter les détails :

kill -15 12345     # envoie SIGTERM, permet à l'appli un arrêt gracieux
kill -9 12345       # force kill, à utiliser seulement si -15 ne fonctionne pas

Attention : kill -9 n’exécute pas les shutdown hooks de l’appli (par exemple fermer le pool de connexions, vider les logs). Essayez toujours -15 en premier.

Voir les ressources en temps réel :

top -o %MEM

-o %MEM trie les processus par utilisation RAM décroissante — utile en cas de soupçon de fuite mémoire. Si vous voulez une meilleure interface, installez htop.

Vérifier le disque :

df -h
du -sh /var/log/*

df -h voit l’utilisation de chaque partition (lisible). du -sh montre la place occupée par chaque sous-dossier de /var/log/ — très utile quand le serveur dit « no space left on device ».

6. Vérification réseau et ports

ss -tulnp | grep 8080

ss remplace l’ancien netstat, plus rapide.
-t TCP, -u UDP, -l en écoute, -n numérique (sans résoudre DNS), -p avec le processus.

tcp   LISTEN  0  128  0.0.0.0:8080  0.0.0.0:*  users:(("java",pid=12345,fd=45))

Sachez immédiatement que le port 8080 est utilisé par le processus Java PID 12345 — très utile en cas d’erreur « Address already in use ».

Testez rapidement une API avec curl :

curl -s -X POST http://localhost:8080/api/orders \
  -H "Content-Type: application/json" \
  -d '{"customerId":1,"amount":99.5}'

-s silencieux (masquer la barre de progression), -X POST choisir la méthode, -d corps JSON. Ajoutez -i si vous voulez aussi voir les en-têtes de réponse.

La commande lsof est utile quand on a besoin de savoir exactement quel fichier/socket un processus a ouvert :

lsof -i :8080

7. Permissions des fichiers

chmod +x deploy.sh
chown nonla:nonla application.properties
chmod 640 .env

chmod +x autoriser l’exécution du script.
chown user:group change le propriétaire — généralement besoin de sudo si le fichier appartient à un autre utilisateur.
chmod 640 signifie propriétaire lecture/écriture (6), groupe lecture seule (4), autres aucune (0) — standard pour les fichiers sensibles comme .env.

-rw-r----- 1 nonla nonla 128 Oct  5 10:00 .env

Attention : ne faites jamais chmod 777 en production. C’est le moyen le plus rapide pour que tout utilisateur sur la machine lise/modifie vos fichiers sensibles.

8. Compression et décompression

tar -czvf order-service.tar.gz order-service/
tar -xzvf order-service.tar.gz -C /opt/apps/

-c créer une archive, -x décompresser, -z utiliser gzip, -v verbose, -f spécifier le nom du fichier.
-C lors de la décompression, spécifiez le dossier de destination au lieu de décompresser dans le dossier courant.

Lors du déploiement, combinez-le avec scp ou rsync pour pousser les fichiers sur le serveur :

scp order-service.tar.gz user@10.0.0.5:/opt/apps/
rsync -avz --progress target/*.jar user@10.0.0.5:/opt/apps/

rsync ne transfère que les modifications (delta transfer), beaucoup plus rapide que scp quand on met à jour de gros fichiers plusieurs fois.

9. Consultation des logs en temps réel

tail -f /var/log/order-service/app.log

-f (follow) garde le terminal ouvert et affiche les nouvelles lignes au fur et à mesure de l’écriture dans le fichier — commande essentielle à connaître pour déboguer en production.

Filtrez les logs par motif lors d’une lecture tail :

tail -f app.log | grep --line-buffered "ERROR"

--line-buffered est nécessaire car grep met en buffer par bloc par défaut. Sans ce drapeau, la sortie peut être retardée lors d’une redirection avec tail -f.

Si l’appli s’exécute sous systemd, utilisez journalctl au lieu de chercher les fichiers de log manuellement :

journalctl -u order-service -f --since "10 minutes ago"

-u spécifier l’unité de service, -f suivi, --since limiter la plage de temps — évitez de lire des millions de lignes de logs anciennes.

10. Exécuter des commandes Linux depuis Java

Parfois, vous devez appeler des commandes shell directement depuis le code Java, par exemple vérifier le disque avant d’écrire un gros fichier :

import java.io.BufferedReader;
import java.io.InputStreamReader;
import java.util.List;

public class ShellRunner {

    public static String run(List<String> command) throws Exception {
        ProcessBuilder builder = new ProcessBuilder(command);
        builder.redirectErrorStream(true);
        Process process = builder.start();

        try (BufferedReader reader =
                new BufferedReader(new InputStreamReader(process.getInputStream()))) {
            String output = reader.lines().reduce("", (a, b) -> a + b + "\n");
            process.waitFor();
            return output;
        }
    }
}

ProcessBuilder accepte une liste d’arguments (pas une chaîne de commande assemblée, pour éviter l’injection shell).
redirectErrorStream(true) fusionner stderr dans stdout pour lire un seul flux.
process.waitFor() bloque le thread courant jusqu’à la fin du processus enfant.

Test avec JUnit 5 + AssertJ :

import org.junit.jupiter.api.Test;
import java.util.List;
import static org.assertj.core.api.Assertions.assertThat;

class ShellRunnerTest {

    @Test
    void shouldReturnCurrentDirectoryListing() throws Exception {
        String output = ShellRunner.run(List.of("ls", "-la"));

        assertThat(output).contains("total");
    }
}

Ce test exécute vraiment ls -la sur le système et vérifie que la sortie contient la ligne total (la première ligne que ls -la affiche toujours le nombre total de blocs) — confirme que ProcessBuilder peut vraiment appeler des commandes shell.

Attention : appeler des commandes shell depuis du code Java en production est une arme à double tranchant — facile à dépendre de l’OS, difficile à tester, et risque d’injection si l’argument vient de l’entrée utilisateur. À utiliser seulement pour des outils internes ou des scripts d’exploitation, évitez la logique métier principale.

11. Erreurs fréquentes

Exécuter rm -rf avec une variable d’environnement vide, par exemple rm -rf $DIR/* quand $DIR n’est pas défini — supprime accidentellement le répertoire racine. Utilisez toujours set -u dans les scripts ou vérifiez les variables avant.
Oublier sudo quand on a besoin de droits root, entraîne une erreur flou « Permission denied » — vérifiez avec ls -la avant de blâmer l’application.
Utiliser kill -9 par habitude, empêchant Spring Boot de fermer le pool de connexions, cause une fuite sur la base de données.
Rediriger grep après tail -f en oubliant --line-buffered, pensez que les logs ne tournent pas mais sont en réalité en buffer.
Exécuter chmod 777 pour « contourner rapidement l’erreur de permission » — crée une faille de sécurité, particulièrement dangereuse avec les fichiers .env ou les clés SSH.

12. Conclusion

Les commandes de cet article — find, grep, awk/sed, ps/kill, ss/curl, tar, tail -f, journalctl — sont l’ensemble minimal d’outils pour déboguer seul sans attendre l’équipe DevOps. Les maîtriser ne signifie pas mémoriser tous les drapeaux, il suffit de savoir quelle commande résout quel problème et de consulter la page man pour les détails. Le terminal est toujours l’outil de débogage le plus rapide, même si vous avez Grafana, Kibana et des outils APM tout autour.