innwatch forks without reason
julien at trigofacile.com
Mon Sep 15 17:26:45 UTC 2014
> 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
>> 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...
« Ad iura renunciata, non datur regressus. »
More information about the inn-workers