[Users] Question about forking

Tim Madorma tmadorma at gmail.com
Wed May 16 21:57:56 CEST 2007


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