Développeur C Linux système : fork, signaux, sockets et débogage

La frontière entre un programme et le noyau fournit la plupart des questions d'entretien d'un développeur C Linux système. Le poste consiste à écrire ou maintenir des démons, des passerelles réseau, des agents de collecte, des outils de diagnostic ou la couche logicielle d'un équipement sous Linux. Le code utilise l'API POSIX et les appels propres à Linux : fork et exec, threads pthread, signaux, pipes, mémoire partagée, sockets, epoll. Les offres mélangent souvent ce profil avec le C++ ou le Linux embarqué, donc relisez la description avant de préparer l'entretien.

C et Linux figurent sur beaucoup de CV pour des projets d'école ou du code applicatif qui ne sort jamais de la libc. L'expérience système se repère à des détails : tester errno après chaque appel, relancer une lecture interrompue par un signal, fermer les descripteurs hérités par un fils, lire une trace strace pour comprendre un blocage. Une personne qui a tenu un démon en production cite des incidents précis, comme une fuite de descripteurs ou des zombies qui s'accumulent.

Préférez un exercice de lecture de code à un algorithme de tri. Un serveur TCP de cinquante lignes avec deux ou trois erreurs volontaires suffit pour voir les réflexes. Le PDF ajoute un cas de 20 minutes sur un démon qui refuse des connexions.

L'API et les outils d'un développeur C sous Linux

Appels système POSIX et glibc

open, read, write, close, mmap : le programme passe par la glibc pour demander un service au noyau. Chaque appel peut échouer et renseigne alors errno. Un développeur système vérifie chaque retour et sait qu'un read peut rendre moins d'octets que demandé.

Processus : fork, exec, wait

Créer un processus fils, lui faire lancer un autre programme, récupérer son code de sortie. Un fils terminé que personne n'attend reste en zombie dans la table des processus. Les démons et les superviseurs maison reposent sur ces trois appels.

Threads pthread et synchronisation

Plusieurs fils d'exécution partagent la même mémoire. Mutex, variables de condition et opérations atomiques de C11 (stdatomic.h) protègent les données communes. Les interblocages et les accès concurrents apparaissent souvent seulement en charge, d'où l'intérêt d'en parler en entretien.

Signaux

Le noyau interrompt le programme pour le prévenir d'un événement : SIGTERM à l'arrêt, SIGCHLD à la fin d'un fils, SIGPIPE sur une socket fermée par le pair. Un gestionnaire de signal ne peut appeler qu'une courte liste de fonctions. Les profils expérimentés traitent souvent le signal dans la boucle principale avec signalfd.

IPC : pipes, sockets Unix, mémoire partagée

Les moyens de faire dialoguer deux processus sur la même machine. Un pipe pour un flux simple entre parent et fils, une socket Unix pour un échange client-serveur, un segment de mémoire partagée (shm_open, mmap) quand le débit compte, avec une synchronisation explicite.

Sockets TCP/UDP et epoll

Les sockets portent le réseau. Pour suivre des milliers de connexions avec peu de threads, Linux fournit epoll, qui signale les descripteurs prêts à lire ou à écrire. io_uring, présent depuis le noyau 5.1, sert aux entrées-sorties asynchrones à haut débit. Une bonne base TCP/IP revient dans la plupart des offres.

Débogage : gdb, Valgrind, sanitizers

gdb pour arrêter le programme, s'attacher à un processus ou lire un core dump. Valgrind et AddressSanitizer pour les fuites et les accès mémoire invalides, ThreadSanitizer pour les accès concurrents. Demandez quel outil la personne a utilisé sur son dernier plantage.

Observation : strace, perf, /proc

strace affiche les appels système d'un processus en cours, utile pour un blocage ou un fichier introuvable. perf mesure où passe le temps CPU. /proc/<pid> donne les descripteurs ouverts, la mémoire et l'état de chaque thread, sans rien installer.

Compilation : gcc, clang, Make, CMake

gcc ou clang avec les avertissements activés et les options de durcissement. Make ou CMake pour construire, souvent en compilation croisée quand la cible est une carte ARM. Le scripting bash ou Python sert aux bancs de test.

Le poste se publie sous plusieurs intitulés : développeur C Linux, développeur logiciel C bas niveau, développeur C/C++ Linux. La part de système varie. Certains postes restent en espace utilisateur avec des démons, des services réseau et des outils. D'autres touchent aux pilotes et au noyau, d'autres encore à une cible embarquée construite avec Yocto. Les offres demandent souvent du C++ en plus, du bash ou du Python pour les outils de test, et une bonne connaissance de TCP/IP. Il n'existe pas de certification de référence pour ce métier, le niveau se vérifie sur du code lu ou écrit pendant l'entretien et sur les incidents déjà traités.

Ce qu'il faut vérifier chez un développeur C Linux système

• Appels système et gestion des erreurs
• Processus et signaux
• Threads et synchronisation
• IPC et mémoire partagée
• Sockets et epoll
• Débogage et profilage (gdb, strace, perf)

Cinq questions sur les processus, les signaux et les sockets

Chaque question vient avec ce qu'une bonne réponse contient et le signal qui doit vous alerter. Pas besoin d'être technique pour les poser : écoutez si le candidat raconte du vécu.

1. Question 1 · confirmé

   Votre code fait read(fd, buf, 4096) sur une socket TCP puis traite le tampon. Qu'est-ce qui peut mal tourner ?

   Une bonne réponseread peut rendre moins de 4096 octets, 0 quand le pair a fermé, ou -1 avec errno. EINTR signifie qu'un signal a interrompu l'appel et qu'il faut relancer, EAGAIN qu'une socket non bloquante n'a rien à lire. TCP est un flux : un message peut arriver en plusieurs morceaux, ou deux messages dans le même read. Il faut boucler et découper selon un protocole (longueur en tête ou délimiteur). Le tampon n'est pas terminé par un zéro.

   Signal d'alerteUne réponse qui suppose qu'un read rend toujours un message entier, ignore la valeur de retour ou passe buf directement à strlen ou printf.

2. Question 2 · junior à confirmé

   Votre démon lance un processus fils par tâche. Au bout de quelques jours, ps montre des centaines de processus en état Z. Que se passe-t-il, et comment corrigez-vous ?

   Une bonne réponseCe sont des zombies : des fils terminés dont le parent n'a pas récupéré le statut avec wait ou waitpid. La correction est un traitement de SIGCHLD qui appelle waitpid(-1, &status, WNOHANG) en boucle jusqu'à ce qu'il n'y ait plus de fils terminé, dans le gestionnaire ou dans la boucle principale via signalfd. Si le statut n'intéresse personne, SIGCHLD peut être mis à SIG_IGN. Un kill -9 n'a aucun effet sur un zombie.

   Signal d'alerte« Je les tue avec kill -9 », un seul waitpid par signal reçu, ou un redémarrage du démon chaque semaine comme solution.

3. Question 3 · confirmé

   Qu'est-ce que vous vous autorisez à faire dans un gestionnaire de SIGTERM ?

   Une bonne réponseTrès peu de choses. Seules les fonctions async-signal-safe sont permises (la liste est dans signal-safety(7) : write, _exit et quelques autres). Pas de printf, pas de malloc, pas de prise de mutex. Le gestionnaire pose un drapeau de type volatile sig_atomic_t, ou écrit un octet dans un pipe surveillé par la boucle (self-pipe), et la boucle principale fait l'arrêt propre. Il installe le gestionnaire avec sigaction plutôt que signal, et sauvegarde puis restaure errno.

   Signal d'alerteUn gestionnaire qui appelle printf, libère la mémoire et ferme les fichiers lui-même, ou une personne qui n'a jamais entendu parler de fonctions async-signal-safe.

4. Question 4 · junior à confirmé

   Deux threads incrémentent le même compteur un million de fois chacun. Le total n'atteint jamais deux millions. Expliquez et corrigez.

   Une bonne réponsecompteur++ se compose d'une lecture, d'une addition et d'une écriture. Deux threads lisent la même valeur et l'une des deux écritures se perd. En C11, un accès concurrent non protégé est une course de données, donc un comportement indéfini. La correction est un mutex autour de l'incrément, ou un compteur atomique avec atomic_fetch_add (stdatomic.h). Un profil plus avancé mentionne le coût de la contention et propose un compteur par thread additionné à la fin.

   Signal d'alerte« Je le déclare volatile », un sleep pour espacer les threads, ou « en ajoutant des printf, ça marche ».

5. Question 5 · senior

   Un serveur TCP doit tenir 10 000 connexions simultanées avec peu de threads. Comment le construisez-vous ?

   Une bonne réponseDes sockets non bloquantes et une boucle d'événements avec epoll, un tampon de lecture et d'écriture par connexion pour gérer les lectures et écritures partielles. Pour utiliser plusieurs cœurs, un thread par cœur avec sa propre boucle, en répartissant les connexions par SO_REUSEPORT ou depuis un thread qui accepte. En mode edge-triggered, chaque notification impose de lire jusqu'à EAGAIN. La limite de descripteurs (ulimit -n, LimitNOFILE sous systemd) doit être relevée. io_uring est une alternative pour les entrées-sorties asynchrones.

   Signal d'alerteUn thread par connexion sans parler de mémoire ni de pile, ou select, limité à FD_SETSIZE (1024 descripteurs).

Recruter un développeur C Linux système : vos questions

Pour structurer vos autres entretiens, consultez aussi nos pages sur les questions d'entretien de recrutement, la méthode de l'entretien structuré et la grille d'évaluation d'entretien.