24

I'm using fabric to remotely start a micro aws server, install git and a git repository, adjust apache config and then restart the server.

If at any point, from the fabfile I issue either

sudo('service apache2 restart') or run('sudo service apache2 restart') or a stop and then a start, the command apparently runs, I get the response indicating apache has started, for example

[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:

However, if I try to connect, the connection is refused and if I ssh into the server and run sudo service apache2 status it says that "Apache is NOT running"

Whilst sshed in, if run sudo service apache start, the server is started and I can connect. Has anyone else experienced this? Or does anyone have any tips as to where I could look, in log files etc to work out what has happened. There is nothing in apache2/error.log, syslog or auth.log.

It's not that big a deal, I can work round it. I just don't like such silent failures.

tshepang
  • 12,111
  • 21
  • 91
  • 136
Dan
  • 1,536
  • 1
  • 10
  • 20

6 Answers6

41

Which version of fabric are you running?

Have you tried to change the pty argument (try to change shell too, but it should not influence things)?

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

You can set the pty argument like this:

sudo('service apache2 restart', pty=False)
GaretJax
  • 7,462
  • 1
  • 38
  • 47
  • I'm running version 1.0.1 of fabric on OSX 10.6.7. I'll play around with pty and shell too. I'll experiment with combine_stderr too, maybe I'll get a bit more feedback. – Dan Jun 16 '11 at 23:10
  • 1
    This fixed this exact problem for me. – Bialecki Jul 13 '11 at 19:23
  • this fixed by problem too, but can anyone explain why it works? It seems like SIGHUP is being send to all child processes, even though they should be detached from the shell. – Charles Nov 08 '13 at 21:26
  • This didn't fix the problem for me -- it caused fabric to hang with the session open to the remote server. I had to ssh into the server and kill the process to terminate fabric. And it still didn't allow me to nohup a process into the background. – stantonk Jan 08 '14 at 17:07
14

Try this:

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

This worked for me after running into the same problem. I'm not sure why this happens.

Community
  • 1
  • 1
rupello
  • 8,361
  • 2
  • 37
  • 34
  • And if you work on a EC2 instance and get `err: stdin: is not a tty` after applying this fix, you may find the solution here: http://blog.markfeeney.com/2009/12/ec2-fabric-and-err-stdin-is-not-tty.html – AJJ Mar 02 '12 at 08:44
  • Worked for in a ec2 instance. – Mr Hyde Apr 05 '12 at 17:09
4

When connecting to your remotes on behalf of a user granted enough privileges (such as root), you can manage system services as shown below:

from fabtools import service

service.restart('apache2')

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

P.S. Its requires the installation of fabtools

pip install fabtools

Th. Ma.
  • 9,432
  • 5
  • 31
  • 46
4

This is an instance of this issue and there is an entry in the FAQ that has the pty answer. Unfortunately on CentOS 6 doesn't support pty-less sudo commands and I didn't like the nohup solution since it killed output.

The final entry in the issue mentions using sudo('set -m; service servicename start'). This turns on Job Control and therefore background processes are put in their own process group. As a result they are not terminated when the command ends.

Tim Ludwinski
  • 2,704
  • 30
  • 34
0

using pty=False still didn't solve it for me. The solution that ended up working for me is doing a double-nohup, like so:

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)
...
stantonk
  • 1,922
  • 1
  • 18
  • 24
0

Couple of more ways to fix the problem.

  • You could run the fab target with --no-pty option

    fab --no-pty <task>

  • Inside fabfile, set the global environment variable always_use_pty to False, before your target code executes

    env.always_use_pty = False
Varun Katta
  • 6,446
  • 1
  • 17
  • 5