Le tissu semble démarrer Apache2 mais ne pas

Question

J'utilise du tissu pour démarrer à distance un serveur Micro AWS, installer GIT et un référentiel GIT, ajuster la configuration Apache puis redémarrer le serveur.

Si à un moment donné, à partir du fabfile, je délivre soit

sudo('service apache2 restart') ou run('sudo service apache2 restart') ou un arrêt puis un début, la commande s'exécute apparemment, j'obtiens la réponse indiquant qu'Apache a commencé, par exemple

[ec2-184-73-1-113.compute-1.amazonaws.com] sudo: service apache2 start
[ec2-184-73-1-113.compute-1.amazonaws.com] out:  * Starting web server apache2
[ec2-184-73-1-113.compute-1.amazonaws.com] out:    ...done.
[ec2-184-73-1-113.compute-1.amazonaws.com] out: 

Cependant, si j'essaie de me connecter, la connexion est refusée et si je mets dans le serveur et exécutezsudo service apache2 status Il dit que "Apache is NOT running"

Tandis que SSHED, si vous courezsudo service apache start, le serveur est démarré et je peux me connecter. Quelqu'un d'autre a-t-il vécu cela? Ou est-ce que quelqu'un a des conseils sur l'endroit où je pourrais regarder, dans les fichiers journaux, etc. pour déterminer ce qui s'est passé. Il n'y a rien dans apache2/error.log, syslog ou auth.log.

Ce n'est pas un gros problème, je peux y travailler. Je n'aime pas de tels échecs silencieux.

Answer 1

Quelle version de tissu utilisez-vous?

Avez-vous essayé de changer le pty Argument (essayez de changer shell aussi, mais cela ne devrait pas influencer les choses)?

http://docs.fabfile.org/en/1.0.1/api/core/operations.html#fabric.operations.run

Vous pouvez définir le pty Argument comme ceci:

sudo('service apache2 restart', pty=False)

Answer 2

Essaye ça:

sudo('service apache2 restart',pty=False)

Cela a fonctionné pour moi après avoir rencontré le même problème. Je ne sais pas pourquoi cela se produit.

Answer 3

Ceci est une instance de ce problème Et il y a une entrée dans la FAQ qui a la réponse Pty. Malheureusement sur Centos 6 ne prend pas en charge les commandes sudo sans pty et je n'ai pas aimé le nohup solution depuis qu'il a tué la sortie.

La dernière entrée du numéro mentionne en utilisant sudo('set -m; service servicename start'). Cela s'active sur le contrôle du travail et, par conséquent, les processus de fond sont placés dans leur propre groupe de processus. En conséquence, ils ne sont pas terminés à la fin de la commande.

Answer 4

Lorsque vous vous connectez à vos télécommandes au nom d'un utilisateur accordé suffisamment de privilèges (tels que root), vous pouvez gérer les services système comme indiqué ci-dessous:

from fabtools import service

service.restart('apache2')

https://fabtools.readthedocs.org/en/0.13.0/api/service.html

Ps son nécessite l'installation de fabTools

pip install fabtools

Answer 5

Quelques autres façons de résoudre le problème.

• Vous pouvez exécuter la cible fabuleuse avec l'option - no-pty

  fab --no-pty <task>
  

• À l'intérieur de FabFile, définissez la variable d'environnement globale toujours_USE_PTY sur FALSE, avant que votre code cible ne s'exécute

  env.always_use_pty = False
  

Answer 6

L'utilisation de pty = false ne l'a toujours pas résolu pour moi. La solution qui a fini par fonctionner pour moi est de faire un double-no-nomen, comme ainsi:

run.sh

#! /usr/bin/env bash
nohup java -jar myapp.jar 2>&1 &

fabFile.py

...
sudo("nohup ./run.sh &> nohup.out", user=env.user, warn_only=True)
...