iigcc PID to port mappings

[nick.bolton]

I have had an issue where I wanted to quiesce an individual comms server, but could find nothing within Ingres to map the Unix process ID back to the internal communications server ID required by netutil/iinamu. Ingres makes this available for processes using shared memory via csreport, but not any of the other processes.
Attached is a script that uses lsof to report this information along these lines:

PID: 727648 IINAMU: 4788 TCP: 21064 GCC: II0
PID: 727118 IINAMU: 4784 TCP: 21065 GCC: II1

That will let you use netutil to quiesce an individual comms server, and so close it down neatly.

Note: The pathname for lsof is hard coded in the script, so it may need altering.
This has only been tested on 2.6 for axp.osf, but hopefully it is relatively portable.

[daslu01]

Hi Nick,

I'm not sure which Ingres version are you, but at least on Ingres 2006 you can run iimonitor <gcf_address of the gcc> and run show server. For example:
ingres@uksl-centos45-64> iinamu
Ingres 2006 Release 2 NAME SERVICE MANAGEMENT UTILITY --
-- Copyright (c) 2004 Ingres Corporation
IINAMU> show comsvr
COMSVR * 59190
quit


ingres@uksl-centos45-64> iimonitor 59190
IIMONITOR> show server
Server: 59190
Class: COMSVR
Object: *

Connected Sessions ( includes system and admin sessions )
Current: 3

Active Sessions ( includes user sessions only )
Inbound sessions:
Current: 0
Limit: 64
Outbound sessions:
Current: 0
Limit: 64

Protocols
TCP_IP host:uksl-centos45-64 addr:kk port:22104
Registry Protocols
Not Enabled


Then you have the port of this server (in this case 22104).

I hope it can help you,

Luiz

[grant]

Originally Posted by nick.bolton@barclays.com

I have had an issue where I wanted to quiesce an individual comms server, but could find nothing within Ingres to map the Unix process ID back to the internal communications server ID required by netutil/iinamu. Ingres makes this available for processes using shared memory via csreport, but not any of the other processes.
Attached is a script that uses lsof to report this information along these lines:

PID: 727648 IINAMU: 4788 TCP: 21064 GCC: II0
PID: 727118 IINAMU: 4784 TCP: 21065 GCC: II1

That will let you use netutil to quiesce an individual comms server, and so close it down neatly.

Note: The pathname for lsof is hard coded in the script, so it may need altering.
This has only been tested on 2.6 for axp.osf, but hopefully it is relatively portable.

Nice work - this is something I wish I had those times I was trying to track down GCC problems. Is there any chance you can write up a wiki page so it becomes easier to find in future?

regards

grant

[stephenb]

But I though Nick wanted to map the process ID to the port. I'm assuming he's running a "ps" or similar, finding a gcc process with a specific PID, and now wants to find the listen port for the GCC with that pid (assuming there could be many gcc's running on the system).

If this is the case, one way wold be to run

netstat -p -a | grep <pid>

This would show the socket listen address of the gcc with the given process ID. Of course we're working backwards so we can't use the iimonitor trick. The only way I can see is to run:

grep <tcp_socket_number> $II_SYSTEM/ingres/files/errlog.log

This would display the network open line from the log, you could grep also for E_GC2815 to narrow it down. This line will give you the GCC port ID (the first number after the square braces).

with the right grep, awk, or sed tricks you could create a script that gave you one number from the other.

[pickr01]

Originally Posted by stephenb

...
If this is the case, one way wold be to run

netstat -p -a | grep <pid>

This would show the socket listen address of the gcc with the given process ID. ..

netstat -a -p does not work on most Unixes

But where it works(Linux) it gives you both listen addresses, the one for incoming connections defined by the listen address and the one for outgoing connections seen in iinamu

Kristoff

[nick.bolton]

The support of GCF servers in iimonitor was a new feature for Ingres 2006R2, and it doesn't report the Process ID of the GCC.
Unusual resource usage is easiest to see from the Unix level, so mapping back the Process ID to an individual comms server is sometimes useful.

[daryl.monge]

On machines where netstat will not produce PIDs, you can grab the 'lsof' command and use

lsof|grep gcc|grep LISTEN

or some variation thereof. The port number is in hex by default.