Tim Zielke
2014-07-07 14:56:02 UTC
Hello,
I have a Solaris 10 non-global zone A that is running queue manager B and seems to have an extra listening socket on port 1234 that the queue manager listens on. This is causing applications and other queue managers to not be able to start up channels to this queue manager B. I am thinking that the connection request is going to this rogue socket (the first one in the list below). I can't even do a "telnet serverA 1234" on server A, as that just hangs, as well.
Here is what I currently see with netstat on server A.
serverA$ netstat -an | grep 1234 | grep LISTEN
100.100.100.100.1234 *.* 0 0 49152 0 LISTEN
*.1234 *.* 0 0 49152 0 LISTEN
*.1234 *.* 0 0 49152 0 LISTEN
The bottom two rows are from the runmqlsr process on qmgr B. When I stop the listener for 1234, those bottom two rows go away. However, that top row that has the 100.100.100.100.1234 (100.100.100.100 is the obfuscated ip address) still remains. I have used pfiles to verify that no mqm process is tied to that 100.100.100.100.1234 listening socket.
Does anyone know any ways to get rid of that 100.100.100.100.1234 socket, without rebooting the server? I am suspicious that there is no currently active process that has that 100.100.100.100.1234 listening socket open, and that it has been left dangling out there for some reason.
Thanks,
Tim
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
I have a Solaris 10 non-global zone A that is running queue manager B and seems to have an extra listening socket on port 1234 that the queue manager listens on. This is causing applications and other queue managers to not be able to start up channels to this queue manager B. I am thinking that the connection request is going to this rogue socket (the first one in the list below). I can't even do a "telnet serverA 1234" on server A, as that just hangs, as well.
Here is what I currently see with netstat on server A.
serverA$ netstat -an | grep 1234 | grep LISTEN
100.100.100.100.1234 *.* 0 0 49152 0 LISTEN
*.1234 *.* 0 0 49152 0 LISTEN
*.1234 *.* 0 0 49152 0 LISTEN
The bottom two rows are from the runmqlsr process on qmgr B. When I stop the listener for 1234, those bottom two rows go away. However, that top row that has the 100.100.100.100.1234 (100.100.100.100 is the obfuscated ip address) still remains. I have used pfiles to verify that no mqm process is tied to that 100.100.100.100.1234 listening socket.
Does anyone know any ways to get rid of that 100.100.100.100.1234 socket, without rebooting the server? I am suspicious that there is no currently active process that has that 100.100.100.100.1234 listening socket open, and that it has been left dangling out there for some reason.
Thanks,
Tim
To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html