J'ai commencé à fouiller un peu, mais j'ai l'impression que systemd utilise beaucoup les cgroup .
Une option intéressante, et ajoutée par les dev de systemd au noyau, est l'option PR_SET_CHILD_SUBREAPER pour prctl():
avec cette option, un processus père peut récupérer ses "petits enfants" à la place du pid 1 quand ses childs se terminent.
Je ne peux pas utiliser cette option, car je fonctionne en mode client/serveur avec une socket UNIX.
Le client vérifie les options de la commande et démarrera les commandes à limiter si besoin, et on peut limiter des process déjà démarrés.
Il envoie la requête au daemon, attend la réponse et se termine.
Le daemon se charge de configurer le système, il ne reçoit que les pid à limiter.
Les commandes d'admin habituelles (ss, netstat, lsof, ps, ..) utilisent toutes /proc, il n'y a peut être pas d'autres solutions.
[^] # Re: Prendre l'inspiration dans les sources de systemd ?
Posté par tigrou3tac . En réponse au message traquer un process par son pid. Évalué à 1.
J'ai commencé à fouiller un peu, mais j'ai l'impression que systemd utilise beaucoup les cgroup .
Une option intéressante, et ajoutée par les dev de systemd au noyau, est l'option PR_SET_CHILD_SUBREAPER pour prctl():
avec cette option, un processus père peut récupérer ses "petits enfants" à la place du pid 1 quand ses childs se terminent.
Je ne peux pas utiliser cette option, car je fonctionne en mode client/serveur avec une socket UNIX.
Le client vérifie les options de la commande et démarrera les commandes à limiter si besoin, et on peut limiter des process déjà démarrés.
Il envoie la requête au daemon, attend la réponse et se termine.
Le daemon se charge de configurer le système, il ne reçoit que les pid à limiter.
Les commandes d'admin habituelles (ss, netstat, lsof, ps, ..) utilisent toutes /proc, il n'y a peut être pas d'autres solutions.