[Users] Question about forking
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Fri May 18 16:52:26 CEST 2007
Hi Anatoly,
it looks like there are some "rebel" modules...but indeed, the right
approach is to be sure all sub-processes are terminated along with the
main one.
I got the new version of the patch and I will process it asap.
thanks and regards,
bogdan
Anatoly Pidruchny wrote:
> Hi Bogdan,
>>
>> 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.
> Well, apparently, at least not all modules do this. I just looked at
> the first module with a fork call that my find/grep command gave me.
> It happened to be xmpp module. It does not save the pid of the child
> process after the fork and it does not kill the child process in the
> module destroy function. But the reason why normally there are no
> left-over openser processes when openser is terminated is because the
> main openser process sends a SIGTERM signal to the whole process
> group, so, the signal is delivered to all the descendant openser
> processes, not only to the children of the main openser process.
>>
>> 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....
> Please modify the patch and use whatever name you think would be
> appropriate for this option. My reasoning for using the name -D is
> that currently -D option is for developers only. Nobody else is using
> this option and so nobody else will be affected if the meaning of the
> -D option changes. But I am OK if you use any other name for the new
> option and leave -D as it is.
>
> 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 Users
mailing list