En utilisant God pour surveiller Licorne - Démarrage a quitté avec un code différent de zéro = 1

Question

Je travaille sur un script God pour surveiller mes Licornes. J'ai commencé avec l'exemple de script de GitHub et j'ai été en train de le modifier pour correspondre à la configuration de mon serveur. Une fois que God est en marche, des commandes telles que god stop unicorn et god restart unicorn fonctionnent très bien.

Cependant, god start unicorn entraîne AVERTISSEMENT : la commande de démarrage de licorne s'est arrêtée avec un code non nul = 1. La partie bizarre est que si je copie le script de démarrage directement à partir du fichier de configuration, il démarre comme une toute nouvelle mustang.

Ceci est ma commande de démarrage :

/usr/local/bin/unicorn_rails -c /home/my-linux-user/my-rails-app/config/unicorn.rb -E production -D

J'ai déclaré tous les chemins comme absolus dans le fichier de configuration. Des idées sur ce qui pourrait empêcher ce script de fonctionner ?

Answer 1

Je n'ai pas utilisé unicorn en tant que serveur d'application, mais j'ai utilisé god pour la surveillance auparavant.

Si je me souviens bien, lorsque vous démarrez god et donnez votre fichier de configuration, il démarre automatiquement tout ce que vous lui avez dit de surveiller. Unicorn est probablement déjà en cours d'exécution, c'est pourquoi il affiche l'erreur.

Vérifiez cela en exécutant god status une fois que vous avez démarré god. Si ce n'est pas le cas, vous pouvez vérifier sur la ligne de commande quel est le statut de sortie de la commande :

/usr/local/bin/unicorn_rails -c /home/my-linux-user/my-rails-app/config/unicorn.rb -E production -D; echo $?;

Cet echo affichera le statut de sortie de la dernière commande. Si celui-ci est zéro, la dernière commande n'a signalé aucune erreur. Essayez de démarrer unicorn deux fois de suite, je m'attends à ce qu'il retourne 1 la deuxième fois, car il est déjà en cours d'exécution.

EDIT :

incluant la solution réelle des commentaires, car cela semble être une réponse populaire :

Vous pouvez définir explicitement un utilisateur et un groupe si votre processus doit être exécuté en tant qu'utilisateur spécifique.

God.watch do |w|
  w.uid = 'root'
  w.gid = 'root'

  # reste de la configuration

Answer 2

Mon problème était que je n'ai jamais regroupé en tant que root. Voici ce que j'ai fait :

sudo bash
cd RAILS_ROOT
bundle

Vous recevez un avertissement vous disant de ne jamais faire cela :

Ne lancez pas Bundler en tant que root. Bundler peut demander sudo si nécessaire, et installer votre bundle en tant que root cassera cette application pour tous les utilisateurs non root sur cette machine.

Mais c'était la seule façon que j'ai pu obtenir resque ou unicorn pour fonctionner avec god. C'était sur une instance ec2 si cela aide quelqu'un.

Answer 3

Ajouter l'option de journalisation m'a beaucoup aidé dans le débogage.

God.watch do |w|
  w.log = "#{RAILS_ROOT}/log/god.log"

  # reste de la configuration
end

En fin de compte, mon bug s'est avéré être le start_script dans God qui était exécuté dans l'environnement development. J'ai corrigé cela en ajoutant le RAILS_ENV au script de démarrage.

start_script = "RAILS_ENV=#{ENV['RACK_ENV']} bundle exec sidekiq -P #{pid_file} -C #{config_file} -L #{log_file} -d"