I had to write my own CentOS init.d script for celery because it only ships with one for Debian. You can see the script I wrote when I answered my own stack overflow question 3989656.

But there's a problem with this script. if I invoke it:

sudo service celeryd start

then I need to hit enter to get a shell prompt after it completes. This is a problem because I want to invoke it via ssh from another machine by doing:

ssh sudo service celeryd start

and ssh never returns. (I use fabric to start and stop remote services, and this hangs it because it invokes the ssh command above).

What would cause this behavior, and how do I fix it in my script?

Note that if I do "sh -x /etc/init.d/celeryd" as recommended by Thomas Themel in the comments, the output is:

runuser -s /bin/bash - apache -c 'ulimit -S -c 0 >/dev/null 2>&1 ; /usr/local/django/portalapps/manage.py celeryd --pidfile /var/run/celery.pid -f /var/log/celeryd.log -l INFO'

I don't understand how the daemon function in /etc/init.d/functions (which is what produces this series of bash commands) actually daemonizes the process.


You might actually have a shell prompt and not realize it. If you have a program that writes to the terminal while in the background, your prompt gets covered up, but it's still ready for input.


#! /bin/sh
echo -e "This is a test\n\n"

interactive shell:

$sh test.sh &
$This is a test


In this example, the prompt is there. You see the "$" right before "This is a test" that is the prompt. At the bottom you can see the cursor waiting for input. If you type a command here and press enter, it will work as usual. Try running ls after starting your daemon but before pressing <enter>.

  • I second that, happen to me sometime.
    – phunehehe
    Nov 21 '10 at 13:33
  • 1
    I don't think it's that since it doesn't explain the caller's "ssh never returns" description. Nov 21 '10 at 18:53

You might want to figure out what exactly eats that return, by first running the /etc/init.d script directly with (sudo as required) sh -x /etc/init.d/celeryd start. If it is in the shell script, you should see it this way. If daemon itself is waiting for a newline before returning, your answer will be celeryd specific and might benefit from running it through strace or simply with a < /dev/null appended so that it doesn't have access to standard input through your terminal.

Another "grope in the dark" thing to try: run ssh with the -nt option to disable terminal allocation and standard input.

  • I've modified the original question to show the output when running with "-x". I think the celeryd program ("manage.py celeryd") runs in the foreground, and doesn't accept any input while it's running. I assumed that the "daemon" function would do the appropriate stuff to run it as a daemon, but it's not clear to me how it does this. Nov 26 '10 at 22:23

Had the exact same problem - your question and investigations actually helped me find the answer.

Start celery with celery_detach - and, poof! Things work!

ie. manage.py celery_detach --params --settings=foo

It returns immediately, with a proper line break, and the things that fabric is looking for.


Does the daemon command need a & at the end. I don't think it does. This may be the source of your problem.

  • I added it as a workaround because I encountered this problem, but it didn't fix it. Nov 22 '10 at 0:15
  • @lorin: Another thing I noticed is that CELERYD is not getting set, but I assume it is in /etc/default/celeryd. Nov 22 '10 at 1:58
  • Yup, this is set in /etc/default/celeryd, like so: CELERYD="/usr/local/django/portalapps/manage.py celeryd --pidfile $CELERYD_PIDFILE" Nov 22 '10 at 16:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.