[Users] Question about forking

Bogdan-Andrei Iancu bogdan at voice-system.ro
Thu May 17 11:24:29 CEST 2007


Hi Anatoly,

indeed, there are some grand-children processes created by some modules 
(like cpl-c, mi_fifo, mi_xmlrpc, etc). As far as I know, the modules 
implements the killing of the processes spawned by themselves - they 
keep the pid and kill them as module_destroy.

I was lurking around your patch, but the thing that prevented me to 
upload it on SVN was the naming of the options :D - yes, it sounds 
stupid, but we need to take care and maintain backward compatibility 
(with the fork option) and in the same time to have some suggestive and 
correct names for the options....

regards,
bogdan

Anatoly Pidruchny wrote:
> Tim,
>
> I found a difference in signal handling in non-daemonized vs 
> daemonized mode. When the main openser process daemonizes itself, it 
> also creates a new process group and session, puts itself into the new 
> process group and becomes its leader. Then later it can send signals 
> to all the processes in the process group. It means the signal will be 
> delivered to all the children, children of children and so on. In 
> non-daemonized mode it only sends signals to its direct children.
>
> I will try to modify code to create a new process group also when -D 
> option is used (but only when -F is not used). I will let you know 
> when a modified patch is ready.
>
> Thanks,
>
> Anatoly.
>> Hi Anatoly,
>>
>> That is what I did in the first example that I sent to you today.
>> Running manually with the -D option has the same results as when
>> executing openser with runsv.
>>
>> thanks,
>>
>> Tim
>>
>> On 5/16/07, Anatoly Pidruchny <apidruchny at newxt.com> wrote:
>>> Tim,
>>>
>>> I can not explain why it behaves differently. But can you also try the
>>> same test with -D option, but without using runsv?
>>>
>>> Anatoly.
>>> > Hi Anatoly,
>>> >
>>> > Thanks for your work-around - I'll try it. However, I did try the 
>>> test
>>> > you described without the -D option and here are the results:
>>> >
>>> > root at homer:/# ps -ef | grep openser
>>> > sipproxy 29793 29786   0 12:52:24 ?           0:00 openser
>>> > sipproxy 29788 29786   0 12:52:24 ?           0:00 openser
>>> > sipproxy 29791 29786   0 12:52:24 ?           0:00 openser
>>> > sipproxy 29789 29786   0 12:52:24 ?           0:00 openser
>>> > root 29797 29266   0 12:52:28 pts/1       0:00 grep openser
>>> > sipproxy 29795 29786   0 12:52:24 ?           0:00 openser
>>> > sipproxy 29786     1   0 12:52:24 ?           0:00 openser
>>> > sipproxy 29794 29786   0 12:52:24 ?           0:00 openser
>>> > sipproxy 29792 29786   0 12:52:24 ?           0:00 openser
>>> > sipproxy 29790 29787   0 12:52:24 ?           0:00 openser
>>> > sipproxy 29787 29786   0 12:52:24 ?           0:00 openser
>>> >
>>> > root at homer:/# kill 29786
>>> > root at homer:/# ps -ef | grep openser
>>> >    root 29799 29266   0 12:52:50 pts/1       0:00 grep openser
>>> >
>>> > As you can see, the child (29787) kills the grandchild (29790) when
>>> > the parent (29786) is killed. I'm not sure why it behaves 
>>> differently.
>>> >
>>> > Tim
>>> >
>>> > On 5/16/07, Anatoly Pidruchny <apidruchny at newxt.com> wrote:
>>> >> Hi Tim,
>>> >>
>>> >> As far as I know, the problem with the left over openser process 
>>> that
>>> >> you described is not caused by the patch. If you run openser 
>>> manually
>>> >> without -D option, then kill the main process, you will get 
>>> exactly the
>>> >> same result. The main openser process will kill all its children, 
>>> but
>>> >> will not kill its grandchildren. The reason is that the main openser
>>> >> process does not know anything about its grandchildren. 
>>> Theoretically,
>>> >> the process that forked a child (for example, your process with PID
>>> >> 29744) is supposed to kill its children (for example, your 
>>> process with
>>> >> PID 29747) when it is terminated. But this does not happen. I 
>>> think it
>>> >> is a known issue (bug?) with openser. May be if you open a 
>>> feature (or
>>> >> bug?) request then this issue will be resolved.
>>> >>
>>> >> By the way, we do not have this problem. I think the reason is 
>>> that you
>>> >> use some module that we do not use. I grepped the openser sources 
>>> and
>>> >> found a number of places in modules where a child process is 
>>> forked. In
>>> >> our case, I think we never hit code that creates any of the 
>>> "child of a
>>> >> child" processes.
>>> >>
>>> >> As a workaround, did you try to kill all the left over openser 
>>> processes
>>> >> from the ./finish file?
>>> >>
>>> >> Regards,
>>> >>
>>> >> Anatoly.
>>> >> > Hey Anatoly,
>>> >> >
>>> >> > I've been running with your patch and it works, but there is 
>>> one issue
>>> >> > that I want to bring up. After openser forks, it creates 
>>> processes as
>>> >> > follows:
>>> >> >
>>> >> > sipproxy 29745 29743   0 11:32:38 pts/2       0:00 openser -D
>>> >> > sipproxy 29751 29743   0 11:32:38 pts/2       0:00 openser -D
>>> >> > sipproxy 29748 29743   0 11:32:38 pts/2       0:00 openser -D
>>> >> > sipproxy 29750 29743   0 11:32:38 pts/2       0:00 openser -D
>>> >> > sipproxy 29743 29432   0 11:32:37 pts/2       0:00 openser -D
>>> >> > sipproxy 29752 29743   0 11:32:38 pts/2       0:00 openser -D
>>> >> > sipproxy 29744 29743   0 11:32:38 pts/2       0:00 openser -D
>>> >> > sipproxy 29746 29743   0 11:32:38 pts/2       0:00 openser -D
>>> >> > sipproxy 29749 29743   0 11:32:38 pts/2       0:00 openser -D
>>> >> > sipproxy 29747 29744   0 11:32:38 pts/2       0:00 openser -D
>>> >> >
>>> >> > You can note that the parent PID is 29743 and has several 
>>> children,
>>> >> > but for some reason, process 29744 also spawns the child process
>>> >> > 29747. When I use runsv to start the process, it notes the process
>>> >> > that it creates is 29743. Then when I terminate with runsv, it 
>>> kills
>>> >> > 29743 - which kills all of it's children, but leaves PID 29747
>>> >> > running. Since it's parent was killed, PID 29747 is adopted by the
>>> >> > init process (PID 1). Here is an example of this done by hand 
>>> (with a
>>> >> > kill of 29743):
>>> >> >
>>> >> > root at homer:/# kill 29743
>>> >> > root at homer:/# ps -ef | grep openser
>>> >> >    root 29756 29266   0 11:35:19 pts/1       0:00 grep openser
>>> >> > sipproxy 29747     1   0 11:32:38 pts/2       0:00 openser -D
>>> >> >
>>> >> > Please let me know if you can assist here.
>>> >> >
>>> >> > thanks much,
>>> >> > Tim
>>> >> >
>>> >> > On 5/7/07, Anatoly Pidruchny <apidruchny at newxt.com> wrote:
>>> >> >> Hi, Tim,
>>> >> >>
>>> >> >> there is a patch (that I submitted) that allows to run the main
>>> >> openser
>>> >> >> process in foreground and fork child processes as usual. No 
>>> developer
>>> >> >> has reviewed the patch yet. I hope this patch will be accepted
>>> >> soon. The
>>> >> >> patch is simple and we use it for a long time now. You can also
>>> >> take the
>>> >> >> patch and use it.
>>> >> >>
>>> >> >> The patch is:
>>> >> >>
>>> >> 
>>> http://sourceforge.net/tracker/index.php?func=detail&aid=1689998&group_id=139143&atid=743022 
>>>
>>> >>
>>> >> >>
>>> >> >>
>>> >> >> Anatoly
>>> >> >> > Hi,
>>> >> >> >
>>> >> >> > I want to start openser with runsv which requires that the 
>>> starting
>>> >> >> > process run in the foreground. My problem is that I also 
>>> want to
>>> >> >> > listen on a couple of different ports. When I set forking = 
>>> yes, it
>>> >> >> > will listen on multiple ports, but runsv won't work. When I set
>>> >> >> > forking=no, then openser will only listen on the first 
>>> specified
>>> >> port.
>>> >> >> >
>>> >> >> > Is there any way around this? Can I have the starting process
>>> >> run in
>>> >> >> > the foreground and fork other processes that listen to the 
>>> ports in
>>> >> >> > the background?
>>> >> >> >
>>> >> >> > Here is the error message:
>>> >> >> >
>>> >> >> > WARNING: no fork mode  and more than one listen address
>>> >> found(will use
>>> >> >> > only the the first one)
>>> >> >> >
>>> >> >> > Here are the associated configuration lines:
>>> >> >> >
>>> >> >> > fork=no
>>> >> >> >
>>> >> >> > children=32
>>> >> >> >
>>> >> >> > # Local IP address/port pairs to listen to
>>> >> >> > listen=65.185.233.55:5061
>>> >> >> > listen=65.185.233.55:5062
>>> >> >> >
>>> >> >> > # Alias IP address/port pairs
>>> >> >> > alias=65.185.233.104:5061
>>> >> >> > alias=65.185.233.104:5062
>>> >> >> >
>>> >> >> > thanks,
>>> >> >> > Tim
>>> >> >> >





More information about the Users mailing list