Why do I need to hit enter to get my shell prompt after my init.d script completes?

Question

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 192.168.2.3 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.

Solution 1

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.

Solution 2

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.

test.sh:

#! /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>.

Solution 3

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.

Comments

[phunehehe]

I second that, happen to me sometime.

[Thomas Themel]

I don't think it's that since it doesn't explain the caller's "ssh never returns" description.

[Lorin Hochstein]

I added it as a workaround because I encountered this problem, but it didn't fix it.

[Brian Rasmussen]

@lorin: Another thing I noticed is that CELERYD is not getting set, but I assume it is in /etc/default/celeryd.

[Lorin Hochstein]

Yup, this is set in /etc/default/celeryd, like so: CELERYD="/usr/local/django/portalapps/manage.py celeryd --pidfile $CELERYD_PIDFILE"

[Lorin Hochstein]

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.