[Users] Question about forking

Anatoly Pidruchny apidruchny at newxt.com
Wed May 16 19:27:12 CEST 2007


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
>> >> >
>> >> > _______________________________________________
>> >> > Users mailing list
>> >> > Users at openser.org
>> >> > http://openser.org/cgi-bin/mailman/listinfo/users
>> >> >
>> >>
>> >>
>> >
>>
>>
>





More information about the Users mailing list