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
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&gro...
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
Anatoly,
Awesome! I'll try your patch.
thanks, Tim
On 5/7/07, Anatoly Pidruchny apidruchny@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&gro...
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@homer:/# kill 29743 root@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@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&gro...
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@homer:/# kill 29743 root@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@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&gro...
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@homer:/# kill 29786 root@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@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@homer:/# kill 29743 root@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@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&gro...
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@homer:/# kill 29786 root@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@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@homer:/# kill 29743 root@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@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&gro...
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@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@homer:/# kill 29786 root@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@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@homer:/# kill 29743 root@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@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&gro...
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@openser.org http://openser.org/cgi-bin/mailman/listinfo/users
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@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@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@homer:/# kill 29786 root@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@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@homer:/# kill 29743 root@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@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&gro...
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@openser.org > http://openser.org/cgi-bin/mailman/listinfo/users >
Great. thanks a lot. I'll try it then.
On 5/16/07, Anatoly Pidruchny apidruchny@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@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@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@homer:/# kill 29786 root@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@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@homer:/# kill 29743 root@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@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&gro...
> > > 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@openser.org > > http://openser.org/cgi-bin/mailman/listinfo/users > > > >
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@gmail.com wrote:
Great. thanks a lot. I'll try it then.
On 5/16/07, Anatoly Pidruchny apidruchny@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@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@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@homer:/# kill 29786 root@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@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@homer:/# kill 29743 > root@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@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&gro...
>> >> >> 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@openser.org >> > http://openser.org/cgi-bin/mailman/listinfo/users >> > >> >> >
Tim,
the new patch is http://sourceforge.net/tracker/index.php?func=detail&aid=1720847&gro...
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@gmail.com wrote:
Great. thanks a lot. I'll try it then.
On 5/16/07, Anatoly Pidruchny apidruchny@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@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@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@homer:/# kill 29786 root@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@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@homer:/# kill 29743 > > root@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@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&gro...
> > >> > >> > >> 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@openser.org > >> > http://openser.org/cgi-bin/mailman/listinfo/users > >> > > >> > >> > > > >
Hi Anatoly,
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.
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....
regards, bogdan
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@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@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@homer:/# kill 29786 root@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@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@homer:/# kill 29743 root@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@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&gro...
> > > 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 > >
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@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@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@homer:/# kill 29786 root@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@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@homer:/# kill 29743 > root@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@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&gro...
>> >> >> 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 >> >
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@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@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@homer:/# kill 29786 root@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@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@homer:/# kill 29743 > > root@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@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&gro...
> > >> > >> > >> 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 > >> >