Gère SIGTERM correctement. Et spécifie quand ton service/application est ready.
Je me demande combien d'applications savent que la seule façon à peu près fiable de gérer les signaux UNIX, c'est le self-pipe?
Et que même le self-pipe peut casser en cas d'utilisation de multi-thread...
Pour le reste, les variables d'environnement pour la config, moi ça me paraît une très mauvaise idée: tu parles d'avoir plusieurs instances d'un daemon dans un environnement, non? Pour la mise en échelle... des paramètres de ligne de commande me paraissent nettement plus simple moi. Qu'ils soient remplis par un programme qui les lise depuis un fichier de conf ou autre chose, peu importe, mais c'est le seul moyen que je voie qui permette d'éviter les collisions.
Ne pas stocker dans des fichiers parce que c'est local, préférer FTP & co? Idem, pas cohérent. Si je stocke dans un fichier "local", ça peut très bien être un montage NFS ou SSHfs, SMB, ou autre. C'est donc bien plus neutre qu'utiliser une base de données, qui elles auront bien souvent leurs p'tites APIs et autres qui diffèrent avec les autres. Ce qui ne veut bien entendu pas dire que les BDD sont à bannir, loin de la, elles ont leur usage.
Dans l'ensemble, de ce que j'ai compris de ce que tu dis, ces 12 "règles" semblent être bien trop vagues pour être utilisables comme règles.
Après des gens qui voient ça comme une religion a ne surtout pas blasphémer, c'est parce que l'humain est un stupide singe overclocké
Selon Tux dans FreedroidRPG, la solution dans ce cas la, c'est de faire boire une bouteille de refroidissant industriel cul-sec à la personne en surchauffe :)
PS: j'avais un peu plus détaillé, mais le brouteur à lamentablement crash, donc j'ai refait en condensé.
J'avais notamment un passage pour tancer tous ces foutus daemons qui croient que le double-fork, le fichier de PID et syslog, c'est l'état de l'art... et qui donc forcent à utiliser l'option --debug quand elles la proposent, pour pouvoir tourner dans un runit, daemon-tools, ou autre du même acabit.
Probablement que les admin du millénaire dernier considéraient que c'est une excellente idée de faire 400 km pour aller rebooter un système, plutôt qu'il ne le fasse de lui-même et essaie d'uploader un rapport sur le problème ou de laisser prendre la main à distance. C'est plus sûr... (et pendant ce temps, un usager est bloqué, possiblement physiquement, possiblement en danger corporel, mais au moins le réseau est en sécurité?)
[^] # Re: Explication
Posté par freem . En réponse au journal Douze facteurs dans ta tronche. Évalué à 3.
Je me demande combien d'applications savent que la seule façon à peu près fiable de gérer les signaux UNIX, c'est le self-pipe?
Et que même le self-pipe peut casser en cas d'utilisation de multi-thread...
Pour le reste, les variables d'environnement pour la config, moi ça me paraît une très mauvaise idée: tu parles d'avoir plusieurs instances d'un daemon dans un environnement, non? Pour la mise en échelle... des paramètres de ligne de commande me paraissent nettement plus simple moi. Qu'ils soient remplis par un programme qui les lise depuis un fichier de conf ou autre chose, peu importe, mais c'est le seul moyen que je voie qui permette d'éviter les collisions.
Ne pas stocker dans des fichiers parce que c'est local, préférer FTP & co? Idem, pas cohérent. Si je stocke dans un fichier "local", ça peut très bien être un montage NFS ou SSHfs, SMB, ou autre. C'est donc bien plus neutre qu'utiliser une base de données, qui elles auront bien souvent leurs p'tites APIs et autres qui diffèrent avec les autres. Ce qui ne veut bien entendu pas dire que les BDD sont à bannir, loin de la, elles ont leur usage.
Dans l'ensemble, de ce que j'ai compris de ce que tu dis, ces 12 "règles" semblent être bien trop vagues pour être utilisables comme règles.
Selon Tux dans FreedroidRPG, la solution dans ce cas la, c'est de faire boire une bouteille de refroidissant industriel cul-sec à la personne en surchauffe :)
PS: j'avais un peu plus détaillé, mais le brouteur à lamentablement crash, donc j'ai refait en condensé.
J'avais notamment un passage pour tancer tous ces foutus daemons qui croient que le double-fork, le fichier de PID et syslog, c'est l'état de l'art... et qui donc forcent à utiliser l'option
--debugquand elles la proposent, pour pouvoir tourner dans un runit, daemon-tools, ou autre du même acabit.Probablement que les admin du millénaire dernier considéraient que c'est une excellente idée de faire 400 km pour aller rebooter un système, plutôt qu'il ne le fasse de lui-même et essaie d'uploader un rapport sur le problème ou de laisser prendre la main à distance. C'est plus sûr... (et pendant ce temps, un usager est bloqué, possiblement physiquement, possiblement en danger corporel, mais au moins le réseau est en sécurité?)