# /etc/init.d/buildmaster start * Starting buildmaster in /opt/buildbot/ ... [ !! ] The init script exits with an error, however the service is running: buildbot 6856 3.6 0.3 123384 24772 ? S 13:53 0:01 /usr/bin/python2.6 /usr/bin/twistd --no_save --logfile=/opt/buildbot//twistd.log --pidfile=/opt/buildbot//buildmaster.pid --python=/opt/buildbot//buildbot.tac And since the script exited with an error, I can't restart or stop the service via an init script because the system doesn't think it's running: mbn ~ # /etc/init.d/buildmaster restart * Starting buildmaster in /opt/buildbot/ ... Another twistd server is running, PID 6856 This could either be a previously started instance of your application or a different application entirely. To start a new one, either run it in some other directory, or use the --pidfile and --logfile parameters to avoid clashes. [ !! ] mbn ~ # /etc/init.d/buildmaster stop * WARNING: buildmaster has not yet been started. I originally thought this was due to several deprecation warnings that were being output on the console relating to twisted, but after making those warnings go away, I get the same behavior. The url is a link to the debug output of the init script starting the service. I have no idea where in the file things go bad. Reproducible: Always Steps to Reproduce: 1. Try to start buildbot 2. 3.
I have the same problem with dev-util/buildbot-0.7.11_p3 and I figured out what's going on. The init script is failing because the start-stop-daemon command is returning 1. Strangely this happens even though /usr/bin/twistd and /sbin/start-stop-daemon both return 0. The 1 comes from the start-stop-daemon wrapper function in /lib/rcscripts/sh/rc-daemon.sh. This wrapper seems to have a problem locating the twistd pid after it forks. I didn't look into this problem because I found I could work around it by adding RC_WAIT_ON_START=0 to the top of /etc/conf.d/buildslave. With that variable set to 0, the start-stop-daemon wrapper just uses the twistd exit status and doesn't look for the pid on its own.
*** This bug has been marked as a duplicate of bug 286191 ***
