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
