Je suis dans une situation où Chef pourrait démarrer un service (postgres) mais il pourrait par la suite être arrêté hors bande. Je souhaite qu'une exécution ultérieure de Chef entraîne l'exécution du service. J'ai essayé ceci:
service "postgresql" do
action :start
end
Mais cela n'a aucun effet, disant (up to date)
probablement parce que le chef sait qu'il a été démarré et n'est pas en mesure de dire qu'il s'est arrêté. (Peut-être en raison du service ... status
comportement de ce service?) Si j'écris ceci:
# anti-pattern warning!
execute "force-start-postgresql" do
command "service postgresql start || /etc/init.d/postgresql start"
action :run
end
J'obtiens le comportement souhaité. Aussi, action :restart
il fonctionne. Cependant, ceux-ci semblent être anti-modèles en raison de la portabilité (et potentiellement l'arrêter avant de le redémarrer dans ce dernier cas).
Alors, comment puis-je dire à Chef de démarrer le service de force, même s'il pense qu'il est déjà en cours d'exécution?
Ceci utilise Chef 11.6, hébergé par OpsCode, et la recette postgresql par défaut. (Notez que c'est similaire mais je ne pense pas tout à fait comme Comment forcer des actions sur des ressources "à jour" dans Chef?. )
--- EDIT (clarification après la publication de jtimberland) ---
Le -l debug
ici montre:
DEBUG: service[postgresql] supports status, running
DEBUG: service[postgresql] is running
Même lorsqu'il ne fonctionne PAS. Cela ressemble donc à un bug, et ça m'intéresse. Cependant, je suis principalement intéressé à savoir s'il existe un moyen de dire à Chef "toujours appeler la commande de démarrage du service, en sautant la vérification d'état". Voilà la question ici.
(Je ne suis pas un expert, mais je pense que la façon la plus portable de s'assurer qu'un service fonctionne est de démarrer le service et c'est presque toujours idempotent. OTOH vérifier si un service est en cours d'exécution est moins cohérent et je ne vois pas pourquoi nous devrions nous en soucier !)
:start
indépendamment de la:status
. J'espère également qu'il fait unps -ef | grep [p]ostgresql
ou similaire, sinon il correspondra généralement à sa propre commande grep et pense donc toujours que le service est en cours d'exécution. (Ou c'est peut-être le problème sous-jacent?)