Send inn-workers mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/inn-workers
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of inn-workers digest..."
Today's Topics:
1. Re: innwatch forks without reason (Julien ?LIE)
2. Re: innwatch forks without reason (Lauri Tirkkonen)
3. Re: innwatch forks without reason (Julien ?LIE)
4. Re: innwatch forks without reason (Lauri Tirkkonen)
----------------------------------------------------------------------
Message: 1
Date: Mon, 15 Sep 2014 14:09:14 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Cc: Lauri Tirkkonen <[email protected]>
Subject: Re: innwatch forks without reason
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8; format=flowed
Hi Lauri,
> Applying this patch on top of a 2.5.4 installation causes innwatch to
> continually fork children; I am seeing 437 processes called 'innwatch'
> in just over 5 minutes of running inn
So it seems that innwatch does not wait for the forked-off shell to
terminate.
while { sleep ${NEXTSLEEP} & CHILDPID=$! ; }
do
wait
CHILDPID=
NEXTSLEEP=${INNWATCHSLEEPTIME}
[...]
does not do the right thing for you (maybe it should be "wait
${CHILDPID}"?).
We had before "sleep ${NEXTSLEEP} & wait" that did the trick except when
INN
is stopped. That's why I added CHILDPID to kill the child process when
innwatch
is killed (see the trap condition for SIGTERM=15). This trick does not
seem
to work on illumos.
> These seem to be the forked-off sleeps (remembering that sleep is a
> shell
> builtin on illumos /bin/sh; these are shells)
I would have liked to have code that conciliates the two behaviours
(sleep being a builtin or not)...
--
Julien ?LIE
------------------------------
Message: 2
Date: Mon, 15 Sep 2014 15:31:20 +0300
From: Lauri Tirkkonen <[email protected]>
To: Julien ?LIE <[email protected]>
Cc: [email protected]
Subject: Re: innwatch forks without reason
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
On Mon, Sep 15 2014 14:09:14 +0200, Julien ?LIE wrote:
> So it seems that innwatch does not wait for the forked-off shell to
> terminate.
>
>
> while { sleep ${NEXTSLEEP} & CHILDPID=$! ; }
> do
> wait
> CHILDPID=
> NEXTSLEEP=${INNWATCHSLEEPTIME}
> [...]
Actually I'm wrong, sorry. I messed up applying this part of the patch
because it didn't apply cleanly and I did it by hand :(
It actually does work now, when I've actually added the 'wait'... :)
# svcs -vp inn
STATE NSTATE STIME CTID FMRI
online - 15:23:43 918376 svc:/network/nntp/inn:default
15:23:40 598 ovdb_monitor
15:23:40 599 ovdb_monitor
15:23:40 600 ovdb_monitor
15:23:40 601 ovdb_monitor
15:23:43 604 innd
15:23:43 605 innwatch
15:23:44 622 innfeed
15:23:44 623 overchan
15:24:45 1102 innwatch
Of course the easiest way to handle all this on illumos would be to tell SMF to
just kill all the processes in the contract on stop (instead of executing
rc.news, ie. let the service system manage processes instead of relying on pid
files and shell magic), but I'm not completely confident that will do the right
thing.
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. ]
> 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.
--
Lauri Tirkkonen
Niksula systems specialist
------------------------------
Message: 3
Date: Mon, 15 Sep 2014 19:26:45 +0200
From: Julien ?LIE <[email protected]>
To: [email protected]
Cc: Lauri Tirkkonen <[email protected]>
Subject: Re: innwatch forks without reason
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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. ?
------------------------------
Message: 4
Date: Tue, 16 Sep 2014 11:52:36 +0300
From: Lauri Tirkkonen <[email protected]>
To: Julien ?LIE <[email protected]>
Cc: [email protected]
Subject: Re: innwatch forks without reason
Message-ID: <[email protected]>
Content-Type: text/plain; charset=iso-8859-1
On Mon, Sep 15 2014 19:26:45 +0200, Julien ?LIE wrote:
> 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?)
If rc.news forks off innd, it would know innd's pid and could write the
pid file itself. But I don't know if that's really worth doing, the
race window is pretty small.
--
Lauri Tirkkonen
Niksula systems specialist
------------------------------
_______________________________________________
inn-workers mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/inn-workers
End of inn-workers Digest, Vol 64, Issue 11
*******************************************
