[Devel] Re: [Users] Question about forking
Anatoly Pidruchny
apidruchny at newxt.com
Thu May 24 20:02:41 CEST 2007
Hi Bogdan,
> 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....
I have another idea about the option names. Can we use getopt_long
function in main.c instead of getopt? This way we can keep all the old
option names as they are now and use long names for the new options
(like --no-daemon or --no-fork). I think it is also a good idea to add
long synonyms for the old options. Please let me know if you like the
idea. I can provide a new patch to support long option names, then I can
re-work the no-daemon patch again to use long option names.
I am asking if we can use getopt_long function, because I am not sure if
this function (and the getopt.h header) is available on all the
platforms supported by OpenSER. Please advise.
Regards,
Anatoly.
> 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 Devel
mailing list