Tarik Hireche

Arrêt après SIGTERM

2,5 à 3,1 ms

Sept exécutions, le worker supervisé par sentinel en PID 1 d'un espace de noms de processus, chronométré par wait() pour éviter toute erreur de sondage. Le même worker seul était encore vivant à l'échéance de dix secondes et a fallu le tuer par SIGKILL.

Enfant qui ignore SIGTERM

5,003 s

Même montage, worker en mode têtu, trois exécutions à moins d'une milliseconde l'une de l'autre. C'est l'escalade vers SIGKILL qui part à l'heure.

Délai entre redémarrages

1, 2, 4, 8, 16 s

Chronométré depuis le journal du superviseur avec un enfant qui meurt aussitôt. Cinq redémarrages en quarante secondes, et le délai plafonne à seize.

Suite de tests

13 sur 13

ctest sur une compilation Release, 33 s. La CI lance build, test, shellcheck, docker et compose comme jobs distincts.

Empreinte du superviseur

3,9 Mo RSS

Lu dans /proc pendant la supervision, sur deux fils. Le binaire fait 36 Ko, ou 31 Ko une fois dépouillé.

Le noyau ne délivre un signal à PID 1 que si PID 1 a installé un gestionnaire pour ce signal. Le conteneur reste donc bloqué tout le délai de grâce avant de mourir par SIGKILL. sentinel prend la place de PID 1 et laisse votre programme tourner comme un enfant ordinaire. Il sort avec le code de l'enfant, ou avec 128 plus le numéro du signal si l'enfant a été tué. Un conteneur qui sort en 137, c'est 128 plus 9. C'est l'OOM killer.

Les gestionnaires sont installés sans SA_RESTART. Ça compte : avec le drapeau, le noyau relance waitpid après un signal et la boucle de récupération n'a jamais la main. Sans lui, waitpid renvoie EINTR et la boucle garde le contrôle. Le gestionnaire appelle kill() et rien d'autre. Très peu de fonctions sont sûres en contexte de signal. L'escalade vit sous la même contrainte. Le gestionnaire de SIGTERM arme alarm(5), et un gestionnaire de SIGALRM se charge de tuer.

Il y avait une fenêtre entre le fork et la ligne qui installait les gestionnaires. Un SIGTERM qui arrivait dedans tuait sentinel et laissait l'enfant tourner en orphelin. C'est exactement la panne que sentinel existe pour empêcher. Je l'ai notée comme TODO et j'ai vécu avec un moment. La correction, c'est sigprocmask autour du fork. Il bloque SIGINT et SIGTERM avant, et les débloque une fois les gestionnaires en place. L'enfant restaure le masque d'origine avant l'exec. Sinon tout ce que sentinel lance démarre sourd à ces signaux.

Le serveur de métriques a besoin de son propre fil, parce que le fil principal reste bloqué dans waitpid et ne peut pas attendre aussi dans accept. Ce fil bloque tous les signaux pour lui-même. SIGTERM doit continuer d'arriver sur le fil principal, là où vit le gestionnaire, sinon waitpid n'obtient jamais son EINTR. Les compteurs sont atomiques puisque les deux fils y touchent.

Une seule commande compose monte sentinel, un Prometheus qui le scrute toutes les 5 s, et un Grafana avec le tableau de bord déjà provisionné. La pile fait tourner un enfant qui plante exprès, pour que les courbes montrent quelque chose de réel. Deux règles d'alerte l'accompagnent, une pour la boucle de plantage et une pour un enfant absent depuis deux minutes. La CI monte le tout à chaque poussée et échoue si Prometheus ne voit pas la cible, si le compteur de redémarrages n'a pas bougé, si les deux règles ne sont pas chargées ou si Grafana ne sert pas le tableau de bord.

Je n'avais jamais vu la barrière échouer, donc je ne savais pas si elle marchait. J'ai cassé un test pour faire passer le score de 92 % à 91 %. Le job a viré au rouge. Le signal de baisse a atteint l'étape suivante et déclenché une action maison qui Rickroll le responsable. Ce chemin tourne maintenant de bout en bout.

La suite avait besoin de tests qui tournent sans charger un vrai graphe routier. J'en ai écrit trois avec Mockito, dans leur propre paquet. Ils simulent PointList, DistanceCalcEarth et EdgeIteratorState. Un test peut alors fixer des coordonnées et des attributs d'arête exacts et vérifier le code qui les consomme.

Le projet est parti d'un travail de cours en trois tiers. Je l'ai construit en trois services, chacun dans son conteneur. En entrevue, j'aimerais qu'on m'interroge sur le déploiement. Il n'y a pas de README d'étapes manuelles et pas d'ordre de démarrage à retenir. N'importe qui ayant Docker obtient la même pile, dans le même état, avec une seule commande.

J'ai trouvé celui-là parce que j'ai changé de machine. Une version de l'allocateur étiqueté calculait l'alignement à partir de self.next, un décalage dans le tampon. L'adresse réelle du tampon en mémoire n'entrait jamais dans le calcul. Ça passait tous les tests sur x86-64 Linux. Sur macOS et ARM, ça tombait sur panic: incorrect alignment. Un [N]u8 alloué sur la pile ne commence pas forcément sur une frontière de 8 octets. Aligner un décalage ne vous aligne que par rapport au début du tampon, donc une adresse de base impaire décale toutes celles qui en découlent. Aligner l'adresse absolue a réglé le problème.

Les trois se construisent l'un sur l'autre. Le premier est un tampon d'octets et un index qui avance. Il n'a aucune libération par bloc, parce qu'un allocateur à pile relâche tout ou rien. Le deuxième place un en-tête devant chaque bloc, ce qui rend free() possible comme comptabilité. Un bloc libéré est marqué, puis il reste là. Le troisième parcourt ces en-têtes pour trouver un bloc assez grand avant d'allouer à la fin. Il prend le premier bloc qui convient. Ça coûte O(blocs) et gaspille la fin d'un bloc trop grand. Ça ne demande ni liste libre ni passe de fusion.

Quand le modèle rate largement un exemple, le gradient de la MSE est multiplié par la dérivée de la sortie. Cette dérivée est proche de zéro précisément quand l'erreur est la plus grande. Le réseau apprend donc le plus lentement sur les exemples dont il aurait le plus à apprendre. L'entropie croisée annule ce terme. C'est pour ça qu'elle est le choix par défaut en classification.