Relancer automatiquement un service est généralement une mauvaise idée (à quoi bon relancer MySQL si la partition data est montée sur un lien iSCSI qui vient de tomber). Un des points de contrôle de Nagios nous remonte une alerte, on détermine le problème, on le fixe au besoin, et on relance le service. On ne rajoute pas du bazar avec des procédures de relance automatique qui risqueraient d'empirer la situation.
Pour l'isoler,
Dans quel sens ?
- chroot ou openvz sont là pour ça.
- au niveau session, tous les services dignes de ce nom double fork() pour être leader de leur groupe de session.
Pour la gestion des ressources, les serveurs (Apache/MySQL/Postgres etc …) le font très bien tout seul.
systemd est il né pour combler les lacunes de services mal écrits ?
[^] # Re: Tant que ça reste coté Desktop...
Posté par dcp . En réponse à la dépêche Le point sur udev et systemd. Évalué à 2.
Relancer automatiquement un service est généralement une mauvaise idée (à quoi bon relancer MySQL si la partition data est montée sur un lien iSCSI qui vient de tomber). Un des points de contrôle de Nagios nous remonte une alerte, on détermine le problème, on le fixe au besoin, et on relance le service. On ne rajoute pas du bazar avec des procédures de relance automatique qui risqueraient d'empirer la situation.
Dans quel sens ?
- chroot ou openvz sont là pour ça.
- au niveau session, tous les services dignes de ce nom double fork() pour être leader de leur groupe de session.
Pour la gestion des ressources, les serveurs (Apache/MySQL/Postgres etc …) le font très bien tout seul.
systemd est il né pour combler les lacunes de services mal écrits ?
Mes 2 centimes :)