fabric appears to start apache2 but doesn't
Asked Answered
G

6

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.

Gynandrous answered 16/6, 2011 at 22:49 Comment(1)
Not that this helps at all but i have seen the EXACT same behaviour with memcachedUnchain
V
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)
Vocalise answered 16/6, 2011 at 22:55 Comment(4)
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.Gynandrous
This fixed this exact problem for me.Certainly
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.Botti
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.Declamatory
I
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.

Interbreed answered 17/6, 2011 at 12:41 Comment(2)
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: blog.markfeeney.com/2009/12/…Turgent
Worked for in a ec2 instance.Katinakatine
S
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

Softball answered 3/4, 2013 at 18:53 Comment(2)
Just to clarify, requires an additional but useful depencency: 'fabtools' -> pip install fabtoolsTeary
Thanks @chishaku, I've added it to avoid more people feeling confused.Softball
L
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.

Laminous answered 9/1, 2014 at 20:36 Comment(0)
L
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
    
Landside answered 20/7, 2011 at 22:12 Comment(0)
D
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)
...
Declamatory answered 8/1, 2014 at 18:57 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.