Stale pid when ever restarting eduCommons: message for development team

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Stale pid when ever restarting eduCommons: message for development team

Tapas
Hi,
 I am posting this message if any one from development team of eduCommons is reading this message may please check.I had a problem using eduCommons-3.2.1-1.x86_64.rpm on CentOS 5.5.
If I have to reboot the server for maintenance and I forgot to shutdown educommons daemon then after a reboot when you type
/etc/init.d/eduCommons start
or even if without reboot I have to restart some time

 I get a message like this


Shutting down eduCommons Production Server:
daemon manager not running
daemon process stopped
Starting eduCommons Production Server:
. daemon process started, pid=2474
Client1 already running: 2153

then I have to manually go and delete a file
/opt/eduCommons-3.2.1/var/instance1.lock
then it does start.

Please see if any thing can be done about this.
Reply | Threaded
Open this post in threaded view
|

Re: Stale pid when ever restarting eduCommons: message for development team

blambert
You may want to make sure that your shutdown init scripts are in order and working correctly.

Also it may be a great idea for us to look into enhancing the startup script somehow to be able to detect this condition, and recover gracefully.

In the mean time the best solution is as you discovered. Simply delete the stale PIDs/lock files and relaunch.

The current PID/lock file strategy is part of the Plone infrastructure, and it may be that either us or someone in the Plone community needs to look at this a little more.

Reply | Threaded
Open this post in threaded view
|

Re: Stale pid when ever restarting eduCommons: message for development team

Tapas
This post was updated on .
blambert wrote
You may want to make sure that your shutdown init scripts are in order and working correctly.
How can I check this.

blambert wrote
Also it may be a great idea for us to look into enhancing the startup script somehow to be able to detect this condition, and recover gracefully.
I have added these two if statements to the educommons init script .

if [ -f $PROD_DIR/var/instance1.lock ] ; then
         rm $PROD_DIR/var/instance1.lock
        fi
        if [ -f $PROD_DIR/var/instance1.pid ] ; then
         rm $PROD_DIR/var/instance1.pid
        fi

It is working also.
So is that a good way of doing.