innwatch forks without reason

[Julien ÉLIE]

Hi Lauri,

> There's still at least one race condition, when stopping the service
> right after starting it:
>
>      [ Sep 15 15:22:22 Executing start method ("/opt/news/bin/rc.news"). ]
>      Starting ovdb.
>      ovdb_init: database is quiescent, running normal recovery
>      ovdb_init: starting ovdb monitor
>      Starting innd.
>      Scheduled start of /opt/news/bin/innwatch.
>      [ Sep 15 15:22:25 Method "start" exited with status 0. ]
>      [ Sep 15 15:22:25 Stopping because service disabled. ]
>      [ Sep 15 15:22:25 Executing stop method ("/opt/news/bin/rc.news stop").
>      ]
>      Stopping innd: ctlinnd: no innd.pid file; did server die?
>      ctlinnd: cannot send "shutdown" command (dead server failure): No such process
>
>      Stopping ovdb_monitor:
>      [ Sep 15 15:22:25 Method "stop" exited with status 0. ]

How is it supposed to be handled?  When starting the service, should we 
wait until innd has written its pid file? (within a reasonable timeout 
of 10s?)



>> I would have liked to have code that conciliates the two behaviours
>> (sleep being a builtin or not)...
>
> Right, I guess forking works there. But it might be worth considering to
> call the utility with path to be sure that a builtin isn't used.

We would have to test (at configure time) whether an utility exists, and 
have the two logics (utility and builtin) in our scripts.  I am unsure 
adding this complexity is worthwhile...

-- 
Julien ÉLIE

« Ad iura renunciata, non datur regressus. »