[Sipp-users] SIPP in background can consume 100% CPU (in keyb_thread)

[Stefan E. <se@FreeBSD.org>]

Hi,

during tests to understand the features of a B2BUA I found, that SIPP
can consume all available CPU by running in a tight loop, if startet
as a background process from within a shell script (and without "-bg").

In my tests, SIPP is started in the background, then control messages
are sent via NETCAT (from within the same script), but the screen is
still updated by SIPP (as if it was running in the foreground) in order
to see how the test proceeds (for example, to see the rate-limiting in
the B2BUA taking effect).

The tight loop is due to keyb_thread() calling getch() repeatedly,
which at least on my system (FreeBSD-7) immediately returns (and is
then called again).

In the case of an interactive invocation of SIPP, it stops when sent
to the background. But if started from a shell script, it does not stop
but executes in the background.

As a very simple example try this:

-----------------------------------------------------------
#!/bin/sh
sipp -bg -sn uas
sipp -sn uac 127.0.0.1 &
-----------------------------------------------------------

At least on my system, the UAC process consumes all CPU as explained
above. It does not help to connect STDIN of the background process to
/dev/null or to close the file descriptor, but SIPP behaves normally
if started by the following script (a *very* much simplified version
of the script I actually use):

-----------------------------------------------------------
#!/bin/sh
sipp -bg -sn uas
sipp -sn uac 127.0.0.1 < /dev/tty &
while sleep 3
do
	echo "*" | nc -o -u 127.0.0.1 8888
done
-----------------------------------------------------------

My questions are:

1) Is this known behaviour of SIPP?

2) Has the different interactive/batch behaviour been implemented on
   purpose?

3) I know, that I can re-arrange my script to execute the while loop
   with netcat in the background and have SIPP be the last command
   that is executed. The only reason not to do this was that I wanted
   to have SIPP running when I enter the control loop; I could wait
   for a second before sending the first command via netcat, instead.
   But I think that the first script should still be able to execute
   without 100% CPU load ...

I can execute the tests using the second example script (or by having
the netcat loop run in the background). This is not an urgent problem
for me, therefor. But it took me some time to understand the high load
and what caused it, and it should at least be documented that SIPP can
run in the background with screen updates being drawn, but that there
are drawbacks ...

Regards, STefan