The init script trys to kill seti when exiting, and if the proccess is not there anymore, because seti exits, crashes, or was given a kill command, the init script exits without marking the service stopped. Preventing the start a workaround requires: cd /opt/setiathome/ rm lock.sah pid.sah ./setiathome /etc/init.d/setiathome restart then the init script will recover and restart seti, including a second thread. So I think the problem is not related to the remaining lock and pid files, just having a process named "setiathome" availible to kill. If the killall command fails the stop command fails too, the stop command should still succeed since seti is not running. Reproducible: Always Steps to Reproduce: 1. /etc/init.d/setiathome start 2. killall setiathome 3. /etc/init.d/setiathome stop 4. /etc/init.d/setiathome start Actual Results: $/etc/init.d/setiathome stop * Stopping SETI@home... setiathome: no process killed [ !! ] $/etc/init.d/setiathome start * WARNING: "setiathome" has already been started. Expected Results: $/etc/init.d/setiathome stop * Stopping SETI@home... setiathome: no process killed [ ok ] $/etc/init.d/setiathome start * Starting SETI@home... [ ok ] app-sci/setiathome-3.08-r1
try /etc/init.d/xxx zap start
thanks martin, that is much easier than starting by hand, and I also discovered that other init scripts have this "problem" too. I came across this because setiathome tends to exit every day or two for me. Why not start seti in a loop? as seen at: http://setiathome.berkeley.edu/unix.html John
setiathome also exits if a network operation fails, so it is quite common for it to exit without a stop request.
ok, theres a new wrapper script that runs setiathome in a loop and when it dies, restarts it as for the stop behavior, that's 'normal' ... which is to say, the stop() function should really only work when a daemon hasnt exited abnormally ... otherwise, how would you know it did freak out ? :)
