• [^] # Re: Et pour en remettre une couche

    Posté par . En réponse au journal Systemd: tuons les mythes. Évalué à 4.

    le fait de modifier le fichier fait qu'il risque de passer à coté d'une modification, car c'est plus proche d'un script. Pareil, il mets la correction de ce souci comme avantage de systemd.

    Je n'ai pas bien compris ça. Tu peux en dire plus, s'il te plaît ?

    Les distros gèrent ça de différentes façon. Debian fait une boucle avec un kill -0 ( donc n'envoie pas de signal fatal ) et attends que le process meurt, donc que le kill échoue. Ce qui est moche pour le cas rare ou le PID est recyclé assez vite ( ie, il y a une race condition ), car le script attendrait à l'infini ou presque.

    Je trouve ça bizarre pourquoi ne pas faire :

    wait $PID_BIND &
PID_WAITING=$!
rdnc # + liste éventuelle d'arguments
wait $PID_WAITING

    L'attente n'est pas active, ne dépend pas de durée arbitraire estimées dans le meilleur ou le pire cas et pas de race condition. Bien sûr c'est moins propre que les cgroup notamment à cause des éventuels fils, mais ça me semble mieux que les solutions dont tu parle.

    D'autres gens vont te répondre que systemd mutualise tout ça et que le code écrit une fois utilisé pour 50 softs est plus sur que le code écrit 50 fois par 50 personnes. Ces autres gens vont aussi te dire que systemd va gérer /var/run sur un tmpfs ( http://www.freedesktop.org/software/systemd/man/systemd-tmpfiles.html ), ce qui est "reboot intempestif friendly".

    Oui c'est proposé par Lennard, mais rien de très spécifique à systemd là dedans.

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)