Estoy en una situación en la que Chef podría comenzar un servicio (postgres) pero posteriormente podría detenerse fuera de banda. Quiero que se ejecute un Chef posterior para que el servicio se ejecute. He intentado esto:
service "postgresql" do
action :start
end
Pero no tiene ningún efecto, (up to date)
presumiblemente porque Chef sabe que se ha iniciado y no puede decir que se ha detenido. (¿Posiblemente debido a cómo se service ... status
comporta este servicio?) Si escribo esto:
# anti-pattern warning!
execute "force-start-postgresql" do
command "service postgresql start || /etc/init.d/postgresql start"
action :run
end
Me sale el comportamiento deseado. También action :restart
hace que funcione. Sin embargo, estos parecen ser anti-patrones debido a la portabilidad (y potencialmente detenerlo antes de comenzar de nuevo en el último caso).
Entonces, ¿cómo puedo decirle a Chef que inicie el servicio por la fuerza, incluso si cree que ya se está ejecutando?
Esto está usando Chef 11.6, alojado por OpsCode, y la receta postgresql predeterminada. (Tenga en cuenta que esto es similar, pero creo que no es lo mismo que ¿Cómo forzar acciones en recursos "actualizados" en Chef?. )
--- EDITAR (aclaración después de la publicación de jtimberland) ---
El -l debug
aquí muestra:
DEBUG: service[postgresql] supports status, running
DEBUG: service[postgresql] is running
Incluso cuando NO está funcionando. Eso suena como un error, y estoy interesado en eso. Sin embargo, estoy principalmente interesado en saber si hay una manera de decirle al Chef "siempre invoque el comando de inicio del servicio, omitiendo la verificación de estado". Esa es la pregunta aquí.
(No soy un experto, pero creo que la forma más portátil de garantizar que un servicio se esté ejecutando es iniciar el servicio y eso casi siempre es idempotente. OTOH comprobar si un servicio se está ejecutando es menos coherente y no veo por qué debería importarnos !)
:start
independientemente de la:status
. También espero que haga unaps -ef | grep [p]ostgresql
o similar, de lo contrario, generalmente coincidirá con su propio comando grep y, por lo tanto, siempre pensará que el servicio se está ejecutando. (¿O tal vez ese es el problema subyacente?)