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 <[EMAIL PROTECTED]> wrote:
Great. thanks a lot. I'll try it then. On 5/16/07, Anatoly Pidruchny <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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: > >> > > >> > [EMAIL PROTECTED]:/# 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 > >> > > >> > [EMAIL PROTECTED]:/# kill 29786 > >> > [EMAIL PROTECTED]:/# 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 <[EMAIL PROTECTED]> 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): > >> >> > > >> >> > [EMAIL PROTECTED]:/# kill 29743 > >> >> > [EMAIL PROTECTED]:/# 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 <[EMAIL PROTECTED]> 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 > >> >> >> > [email protected] > >> >> >> > http://openser.org/cgi-bin/mailman/listinfo/users > >> >> >> > > >> >> >> > >> >> >> > >> >> > > >> >> > >> >> > >> > > >> > >> > > > >
_______________________________________________ Users mailing list [email protected] http://openser.org/cgi-bin/mailman/listinfo/users
