Les API système Linux à connaître pour tout développeur

En 1969, Ken Thompson et Dennis Ritchie étaient assis dans un bureau des Bell Labs et prenaient une série de décisions de conception qui allaient survivre à presque toutes les autres technologies de cette époque. Le PDP-7 sur lequel ils ont écrit Unix est aujourd'hui une pièce de musée. Les langages avec lesquels ils ont commencé sont éteints. Mais l'interface d'appels système qu'ils ont conçue — open, read, write, close, fork, exec — reste le socle de chaque serveur Linux, de chaque téléphone Android et de chaque conteneur en production aujourd'hui.

La plupart des développeurs interagissent avec ces API à travers d'épaisses couches d'abstraction. Le open() de Python, le fs.readFile() de Node, le os.Open() de Go — tous finissent par appeler les mêmes appels système du noyau. Comprendre ces appels système ne sert pas qu'à assouvir une curiosité intellectuelle. Cela vous rend nettement meilleur en débogage, en optimisation de performances et en conception de systèmes qui tiennent vraiment sous pression.

Descripteurs de fichiers : tout est un nombre

L'abstraction la plus importante d'Unix est le descripteur de fichier. Ce n'est qu'un entier — un petit nombre positif qui désigne une ressource ouverte. Mais le mot « ressource » est ici volontairement vague. Un descripteur de fichier peut pointer vers un fichier sur disque, une socket réseau, un tube (pipe) entre processus, un terminal, un minuteur ou même un mécanisme de signalisation. Le noyau s'en moque. Pour votre programme, ce ne sont que des nombres sur lesquels vous pouvez faire read() et write().

#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
int main() {
// fd 0 = stdin, 1 = stdout, 2 = stderr (always)
// open() returns the next available fd, typically 3
int fd = open("data.txt", O_RDONLY);
if (fd == -1) {
perror("open");
return 1;
}
char buf[1024];
ssize_t n;
// read() works the same whether fd is a file,
// a socket, a pipe, or a device
while ((n = read(fd, buf, sizeof(buf))) > 0) {
write(STDOUT_FILENO, buf, n);
}
close(fd);
return 0;
}

C'est ce design qui rend Unix composable. Comme tout partage la même interface, vous pouvez rediriger la sortie d'un fichier vers une socket, envoyer la stdout d'un programme dans la stdin d'un autre, ou remplacer la stderr d'un processus par un fichier de logs — sans que les programmes eux-mêmes le sachent ou s'en soucient. C'est la raison pour laquelle les pipelines shell fonctionnent, et pourquoi des outils comme Docker peuvent capturer la sortie des conteneurs aussi facilement.

Quand vous tombez sur une erreur « too many open files » en production, vous atteignez la limite de descripteurs de fichiers. Quand vous traquez une fuite de sockets, vous cherchez des descripteurs ouverts mais jamais fermés. Quand lsof vous montre ce que fait un processus, il liste en réalité ses descripteurs de fichiers. Comprendre cette abstraction rend soudain lisible toute une famille de problèmes de production.

Fork et exec : la naissance des processus

Unix crée de nouveaux processus d'une manière qui paraît bizarre à la plupart des gens la première fois qu'ils la voient. Au lieu d'un unique appel « créer un processus avec ce programme », Unix découpe l'opération en deux étapes : fork() clone le processus courant, et exec() remplace le programme du clone par un autre. Ça semble détourné, mais cette séparation est ce qui permet tout le modèle de processus d'Unix.

#include <unistd.h>
#include <sys/wait.h>
#include <stdio.h>
#include <fcntl.h>
int main() {
pid_t pid = fork();
if (pid == 0) {
// Child process: redirect stdout to a file
// This happens BETWEEN fork and exec —
// that's the whole point of the split
int fd = open("output.log", O_WRONLY | O_CREAT | O_TRUNC, 0644);
dup2(fd, STDOUT_FILENO);  // stdout now goes to the file
close(fd);
// Replace this process with 'ls'
execlp("ls", "ls", "-la", NULL);
// If we get here, exec failed
perror("exec");
return 1;
}
// Parent: wait for child to finish
int status;
waitpid(pid, &status, 0);
printf("Child exited with status %d\n",
WEXITSTATUS(status));
return 0;
}

La magie opère dans l'intervalle entre fork() et exec(). Dans cette fenêtre, le processus fils peut rediriger des descripteurs de fichiers, modifier des variables d'environnement, fixer des limites de ressources, abandonner des privilèges ou rejoindre un autre namespace — le tout avant que le nouveau programme ne démarre. C'est exactement ainsi que votre shell implémente ls > output.txt. C'est ainsi que les conteneurs mettent en place l'isolation. C'est ainsi que sudo abandonne ses privilèges.

Linux moderne propose aussi clone() (pour un contrôle fin de ce qui est partagé entre parent et enfant), posix_spawn() (pour le schéma courant fork+exec sans le surcoût) et vfork() (une optimisation en grande partie historique). Mais le modèle mental reste fork+exec. Chaque gestionnaire de processus, système d'init et runtime de conteneurs sous Linux utilise une variante de ce schéma.

Signaux : le système d'interruptions du noyau

Les signaux sont le mécanisme Unix de notifications asynchrones. Quand vous appuyez sur Ctrl+C, le noyau envoie SIGINT au processus au premier plan. Quand vous lancez kill, vous envoyez un signal. Quand un processus fils se termine, le parent reçoit SIGCHLD. Ce sont essentiellement des interruptions logicielles : votre code arrête ce qu'il fait, exécute un gestionnaire de signal, puis reprend.

La partie délicate, c'est que les gestionnaires de signaux s'exécutent dans un contexte particulier. Vous ne pouvez pas appeler en toute sécurité la plupart des fonctions de bibliothèque depuis un gestionnaire, car elles ne sont pas forcément réentrantes. malloc(), printf() et tout ce qui prend un verrou sont interdits. L'approche sûre consiste à lever un drapeau dans le gestionnaire et à le vérifier dans votre boucle principale :

#include <signal.h>
#include <stdio.h>
#include <unistd.h>
static volatile sig_atomic_t shutdown_requested = 0;
void handle_sigterm(int sig) {
// Only set a flag — don't do real work here
shutdown_requested = 1;
}
int main() {
struct sigaction sa = {0};
sa.sa_handler = handle_sigterm;
sigaction(SIGTERM, &sa, NULL);
sigaction(SIGINT, &sa, NULL);
printf("Server running (PID %d)...\n", getpid());
while (!shutdown_requested) {
// Do actual work here
sleep(1);
}
printf("Graceful shutdown complete.\n");
return 0;
}

Ce schéma — gérer SIGTERM pour un arrêt gracieux — est indispensable pour tout processus tournant dans un conteneur. Kubernetes envoie un SIGTERM avant de tuer un pod. Systemd en envoie un avant d'arrêter un service. Si votre application ne le gère pas, elle se fait tuer brutalement après un délai, ce qui entraîne des connexions coupées, des écritures partielles et de la corruption de données. J'ai vu des pannes en production causées uniquement par des applications qui ignoraient SIGTERM et se faisaient tuer sans ménagement lors de déploiements de routine.

Sockets : le réseau comme descripteur de fichier

L'API des sockets Berkeley, introduite dans 4.2BSD en 1983, fait partie de ces designs qui font encore tourner le monde. Chaque connexion TCP, chaque paquet UDP, chaque requête HTTP que vous avez jamais faite passe au final par cette API. Et comme les sockets sont des descripteurs de fichiers, elles fonctionnent avec tous les mêmes outils — read(), write(), select(), close().

Un serveur TCP minimal en C est étonnamment lisible une fois qu'on comprend ce que fait chaque appel :

#include <sys/socket.h>
#include <netinet/in.h>
#include <unistd.h>
#include <string.h>
#include <stdio.h>
int main() {
// Create a socket (returns a file descriptor)
int server_fd = socket(AF_INET, SOCK_STREAM, 0);
// Allow address reuse (avoid "address already in use")
int opt = 1;
setsockopt(server_fd, SOL_SOCKET, SO_REUSEADDR, &opt, sizeof(opt));
// Bind to port 8080
struct sockaddr_in addr = {
.sin_family = AF_INET,
.sin_addr.s_addr = INADDR_ANY,
.sin_port = htons(8080)
};
bind(server_fd, (struct sockaddr*)&addr, sizeof(addr));
// Start listening (backlog of 128 pending connections)
listen(server_fd, 128);
printf("Listening on :8080\n");
while (1) {
// Accept a connection (returns a NEW file descriptor)
int client_fd = accept(server_fd, NULL, NULL);
const char *response =
"HTTP/1.1 200 OK\r\n"
"Content-Length: 13\r\n\r\n"
"Hello, world!";
write(client_fd, response, strlen(response));
close(client_fd);
}
}

Voici un serveur HTTP complet en une trentaine de lignes. Il est mono-thread et ne traite qu'une connexion à la fois, ce qui ne le rend pas prêt pour la production, mais il montre tout le cycle de vie d'une socket : socket(), bind(), listen(), accept(), read()/write(), close(). Chaque framework web, pilote de base de données et broker de messages utilise exactement cette séquence sous le capot.

Epoll : gérer des milliers de connexions

Le serveur mono-thread ci-dessus ne traite qu'une connexion à la fois. Dans la vraie vie, les serveurs doivent gérer des milliers de connexions simultanées. L'approche naïve — un thread par connexion — ne passe pas à l'échelle. À 10 000 connexions, vous payez le coût de 10 000 piles de threads, de changements de contexte et de décisions d'ordonnancement.

La solution Linux s'appelle epoll, un mécanisme de notification d'événements qui permet à un seul thread de surveiller efficacement des milliers de descripteurs de fichiers. Au lieu de demander « cette socket est-elle prête ? » pour chacune des 10 000 sockets, vous dites au noyau « réveille-moi dès que l'une de ces sockets est prête » et ne traitez que celles qui ont des données.

#include <sys/epoll.h>
// Create an epoll instance
int epfd = epoll_create1(0);
// Register the server socket
struct epoll_event ev = {
.events = EPOLLIN,
.data.fd = server_fd
};
epoll_ctl(epfd, EPOLL_CTL_ADD, server_fd, &ev);
// Event loop
struct epoll_event events[1024];
while (1) {
// Block until at least one fd is ready
int nfds = epoll_wait(epfd, events, 1024, -1);
for (int i = 0; i < nfds; i++) {
if (events[i].data.fd == server_fd) {
// New connection — accept and add to epoll
int client = accept(server_fd, NULL, NULL);
ev.events = EPOLLIN;
ev.data.fd = client;
epoll_ctl(epfd, EPOLL_CTL_ADD, client, &ev);
} else {
// Data ready on existing connection
handle_client(events[i].data.fd);
}
}
}

C'est le socle de tout serveur haute performance sous Linux. Nginx utilise epoll. Node.js aussi (via libuv). Le planificateur de goroutines de Go utilise epoll. Redis utilise epoll. Quand on dit qu'un serveur utilise des « E/S événementielles » ou des « E/S non bloquantes », on parle généralement d'epoll (ou de ses équivalents multiplateformes : kqueue sur macOS/BSD, io_uring pour les systèmes Linux les plus récents).

Pourquoi les développeurs de haut niveau devraient s'y intéresser

Vous n'écrirez peut-être jamais de C en production. Ce n'est pas grave. Mais comprendre ces API rapporte des dividendes de façons qui ne sautent pas immédiatement aux yeux :

• Déboguer les problèmes de production — Quand strace montre que votre application Python est bloquée sur accept() ou qu'elle fuit des descripteurs de fichiers, vous saurez exactement ce qui se passe au niveau du noyau.
• Comprendre les performances — Pourquoi Node.js est-il rapide pour les E/S mais lent pour le calcul ? Parce qu'epoll gère efficacement l'attente d'E/S, alors que JavaScript est mono-thread pour le calcul. Le modèle d'appels système explique le modèle d'exécution.
• Connaissance des conteneurs et de l'orchestration — Namespaces, cgroups, filtres seccomp, capabilities : ce sont toutes des fonctionnalités du noyau Linux reposant sur les mêmes concepts. Les conteneurs n'ont rien de magique. Ce sont des clone() avec quelques options supplémentaires.
• Prendre de meilleures décisions d'architecture — Faut-il utiliser des threads ou des E/S asynchrones ? Un processus par requête ou un pool de connexions ? Ce sont fondamentalement des questions sur la manière dont le noyau gère les ressources, et la bonne réponse dépend de la compréhension des compromis au niveau des appels système.

Thompson et Ritchie n'auraient pas pu prévoir les conteneurs, le cloud ou les smartphones. Mais l'interface d'appels système qu'ils ont conçue était suffisamment simple et composable pour tout supporter. C'est la vraie leçon de la programmation système sous Linux : les bonnes abstractions ne résolvent pas seulement les problèmes d'aujourd'hui. Elles créent un socle qui s'adapte à des problèmes que personne n'a encore imaginés.

Inutile de mémoriser chaque appel système. Mais consacrez un après-midi à lire les pages de manuel de open(2), fork(2), socket(2) et epoll(7). Écrivez un serveur jouet. Tracez un processus en cours avec strace. Le modèle mental que vous construirez fera de vous un meilleur ingénieur, quel que soit le langage ou le framework que vous utilisez.