Référence pour le traitement correct du fichier PID sous Unix
Où puis-je trouver une référence respectée qui détaille le traitement approprié des fichiers PID sous Unix?
Sur les systèmes d'exploitation Unix, il est courant de «verrouiller» un programme (souvent un démon) à l'aide d'un fichier de verrouillage spécial: le fichier PID.
C’est un fichier situé dans un emplacement prévisible, souvent appelé «/var/run/foo.pid». Le programme est censé vérifier à quel moment il démarre si le fichier PID existe et, s'il existe, quitter avec une erreur. Il s’agit donc d’une sorte de mécanisme consultatif de verrouillage collaboratif.
Le fichier contient une seule ligne de texte, qui correspond à l'ID de processus numérique (d'où le nom «fichier PID») du processus qui détient actuellement le verrou. Cela permet d’automatiser facilement l’envoi d’un signal au processus qui détient le verrou.
Ce que je ne trouve pas, c'est une bonne référence sur le comportement attendu ou les «meilleures pratiques» en matière de traitement des fichiers PID. Il existe différentes nuances: comment verrouiller réellement le fichier (ne vous préoccupez pas? Utilisez le noyau? Et les incompatibilités de plate-forme?), Gérez les verrous périmés (supprimez-les en silence? Quand vérifier?), À quel moment exactement acquérir et libérer le verrou , et ainsi de suite.
Où puis-je trouver un respecté, référence faisant autorité (idéalement au niveau de W. Richard Stevens) pour ce petit sujet?
Autant que je sache, les fichiers PID sont une convention plutôt que quelque chose pour lequel vous pouvez trouver une source respectée, faisant généralement autorité. Le plus proche que je puisse trouver est cette section de la norme de hiérarchie des systèmes de fichiers.
Cette bibliothèque Perl pourrait être utile, car il semble que l'auteur ait au moins réfléchi à certains problèmes qui pourraient survenir.
Je pense que les fichiers sous/var/run sont souvent gérés par les mainteneurs de la distribution plutôt que par les auteurs des démons, car il incombe aux mainteneurs de la distribution de s'assurer que tous les scripts init jouent bien Nice. J'ai consulté la documentation destinée aux développeurs de Debian et de Fedora et je n'ai trouvé aucune directive détaillée, mais vous pourrez peut-être obtenir plus d'informations sur les listes de diffusion de leurs développeurs.
Tout d’abord, sur tous les UNIX modernes, /var/run ne persiste pas lors des redémarrages.
La méthode générale de traitement du fichier PID consiste à le créer lors de l’initialisation et à le supprimer de toute sortie, qu’elle soit normale ou un gestionnaire de signaux.
Il existe deux manières canoniques de créer/vérifier atomiquement le fichier. Le principal consiste à l'ouvrir avec l'indicateur O_EXCL: si le fichier existe déjà, l'appel échoue. L'ancien moyen (obligatoire sur les systèmes sans O_EXCL) est de le créer avec un nom aléatoire et de le lier. Le lien échouera si la cible existe.
Reportez-vous à la section l'interface de programmation Linux de Kerrisk, section 55.6 "Exécution d'une seule instance d'un programme" , basée sur l'implémentation du fichier pid dans la programmation réseau Unix de Stevens, v2.
Notez également que l'emplacement du fichier pidfile est généralement géré par la distribution (via un script init). Par conséquent, un démon bien écrit utilisera un argument de ligne de commande pour spécifier le fichier pidfile et ne permettra pas que celui-ci soit ignoré accidentellement par un fichier de configuration. Il devrait également gérer avec élégance un fichier pid périmé tout seul (vous ne devez pas utiliser O_EXCL). Le verrouillage de fichier fcntl () doit être utilisé - vous pouvez supposer que le fichier pid d'un démon est situé sur un système de fichiers local (non-NFS).
En fonction de la distribution, c'est en fait le script init qui gère le pidfile. Il vérifie l'existence au début, supprime lors de l'arrêt, etc. Je n'aime pas le faire de cette façon. J'écris mes propres scripts d'initialisation et n'utilise généralement pas les fonctions stanard init.
Un programme bien écrit (démon) aura une sorte de fichier de configuration disant où ce pidfile (le cas échéant) doit être écrit. Il veillera également à établir des gestionnaires de signaux de manière à ce que le fichier PID soit nettoyé à la sortie normale ou anormale, chaque fois qu'un signal peut être traité. Le fichier PID donne ensuite au script d’initialisation le PID correct afin de l’arrêter.
Par conséquent, si le fichier pid existe déjà au démarrage, c’est un très bon indicateur pour le programme qu’il s’était précédemment écrasé et qu’il devrait faire un effort de récupération (le cas échéant). Vous tirez en quelque sorte cette logique dans le pied si le script init vérifie lui-même l'existence du PID ou le dissocie.
En ce qui concerne l'espace de noms, il devrait suivre le nom du programme. Si vous commencez 'foo-daemon', ce sera foo-daemon.pid
Vous devriez également explorer/var/lock/subsys, mais il est principalement utilisé sur les versions de Red Hat.
Le package systemd de Red Hat 7 fournit une page de manuel daemon(7) avec la ligne d’en-tête "Rédaction et conditionnement des démons système".
Cette page de manuel traite à la fois de la démonisation "ancien style" (SysV) et "nouveau style" (systemd). Dans le nouveau style, systemd gère lui-même les fichiers PID (s'il est configuré de la sorte). Cependant, dans le style ancien, la page de manuel dit ceci:
- Dans le processus de démon, écrivez le PID du démon (tel que renvoyé par getpid ()) dans un fichier PID, par exemple /run/foobar.pid (pour un démon hypothétique "foobar") afin d’éviter que le démon ne puisse être démarré plus d’une fois ..__ Cela doit être implémenté de manière non raciale pour que le fichier PID soit mis à jour uniquement lorsqu'il est vérifié en même temps que le PID précédemment stocké dans le fichier PID n'existe plus ou appartient à un processus étranger.
Vous pouvez également lire cette page de manuel en ligne .