schoolbell-server.py should delete the .pid file when it terminates

I would call this a bug. Leaving the pidfile prevents schoolbell from starting
again. One of the three (debian) systems I installed schoolbell on has a
problem with "dying" every night. It might be related to logrotate, but every
morning I must delete the pidfile before the init script will do anything.

On Fri, Mar 25, 2005 at 02:48:35PM +0000, dman13 wrote:
> I would call this a bug. Leaving the pidfile prevents schoolbell from starting
> again. One of the three (debian) systems I installed schoolbell on has a
> problem with "dying" every night. It might be related to logrotate, but every
> morning I must delete the pidfile before the init script will do anything.

I can confirm that the schoolbell server sometimes does not restart but
in my case it is a race condition in the initscript where the previous
server has not exited before start-stop-daemon tries to start it again.

Would you mind testing the attached patch for /etc/init.d/schoolbell to
see if it solves your problem as well?

On Sat, Mar 26, 2005 at 04:14:43PM +0000, Brian Sutherland wrote:
|
| Brian Sutherland <email address hidden> added the comment:
|
| On Fri, Mar 25, 2005 at 02:48:35PM +0000, dman13 wrote:
| > I would call this a bug. Leaving the pidfile prevents schoolbell
| > from starting again. One of the three (debian) systems I
| > installed schoolbell on has a problem with "dying" every night.
| > It might be related to logrotate, but every morning I must delete
| > the pidfile before the init script will do anything.
|
| I can confirm that the schoolbell server sometimes does not restart but
| in my case it is a race condition in the initscript where the previous
| server has not exited before start-stop-daemon tries to start it again.

Ah, that sounds plausible. The problem machine is, I think, a bit
slower than the other aging system that doesn't exhibit this problem.
This makes further sense if the program start-stop-daemon calls
doesn't wait until the z3 process has fully shutdown.

| Would you mind testing the attached patch for /etc/init.d/schoolbell to
| see if it solves your problem as well?

I will try this! Thanks!

-D

--
\begin{humor}
Disclaimer:
If I receive a message from you, you are agreeing that:
   1. I am by definition, "the intended recipient"
   2. All information in the email is mine to do with as I see fit and make
        such financial profit, political mileage, or good joke as it lends
        itself to. In particular, I may quote it on USENET or the WWW.
   3. I may take the contents as representing the views of your company.
   4. This overrides any disclaimer or statement of confidentiality that may
        be included on your message
\end{humor}

www: http://dman13.dyndns.org/~dman/ jabber: <email address hidden>

On Sat, Mar 26, 2005 at 05:31:05PM +0000, dman13 wrote:
> Ah, that sounds plausible. The problem machine is, I think, a bit
> slower than the other aging system that doesn't exhibit this problem.
> This makes further sense if the program start-stop-daemon calls
> doesn't wait until the z3 process has fully shutdown.
>
> | Would you mind testing the attached patch for /etc/init.d/schoolbell to
> | see if it solves your problem as well?

I did a little more testing and sometimes get a different error on
restart, I presume because even after the process is stopped, some
things still need to be cleaned up. An entirely un-scientific small
sleep after shutdown solves that (new patch attached).

If anyone is interested, the error is:

Could not initialize the database:
[Errno 11] Resource temporarily unavailable

Perhaps another SchoolBell instance is using it?

Is this still a bug?

We should check this on the hardy release.