[Users] Question about forking
Anatoly Pidruchny
apidruchny at newxt.com
Thu May 17 19:08:51 CEST 2007
Tim,
the new patch is
http://sourceforge.net/tracker/index.php?func=detail&aid=1720847&group_id=139143&atid=743022
Thanks for reporting a problem and testing the re-worked patch.
Anatoly.
> Hey Anatoly,
>
> Your patch seems to work great. I'll let you know if I run into any
> issues. I would go ahead and commit the new patch.
>
> Thanks for the help.
>
> Tim
>
> On 5/16/07, Tim Madorma <tmadorma at gmail.com> wrote:
>> Great. thanks a lot. I'll try it then.
>>
>> On 5/16/07, Anatoly Pidruchny <apidruchny at newxt.com> 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
>> > >> >> >> >
>> > >> >> >> > _______________________________________________
>> > >> >> >> > Users mailing list
>> > >> >> >> > Users at openser.org
>> > >> >> >> > http://openser.org/cgi-bin/mailman/listinfo/users
>> > >> >> >> >
>> > >> >> >>
>> > >> >> >>
>> > >> >> >
>> > >> >>
>> > >> >>
>> > >> >
>> > >>
>> > >>
>> > >
>> >
>> >
>>
>
More information about the Users
mailing list