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.

[rajus01]

Hi Nick,

Just wondering about the problem discussed here…

Originally Posted by nick.bolton@barclays.com

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.

The plan is to display the PID in the “show server” o/p of the iimonitor command when connecting to GCF servers such as GCC, GCD, and GCN. See the example iimonitor o/p below for GCC server…

Is this something that you are looking for?

Regards,
Usha


Ingres NAME SERVICE MANAGEMENT UTILITY --
-- Copyright (c) 2009 Ingres Corporation
IINAMU> show servers
STAR * 32867
DASVR * 32868
COMSVR * 32865
INGRES * 32864 (sole server)
IUSVR * 32863
IINMSVR * 32869
IINAMU> quit
% iimonitor 32865
IIMONITOR> show server
Server: 32865
Class: COMSVR
Object: *
Pid: 890

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:hostname addr:MB port:23056
Registry Protocols
Not Enabled
IIMONITOR> quit

Checkout the community wiki page http://community.ingres.com/wiki/Ing...t_mapping_info as well...

[nick.bolton]

That looks ideal.
It would be easy enough to pull that info out in a script and do something useful with it.

Would the PID also be reported for the other components (e.g. dbms servers)?
I don't have any specific need for that; but consistency is always good.

[rajus01]

Hi Nick, Thanks for the feedback....

Originally Posted by nick.bolton@barclays.com

Would the PID also be reported for the other components (e.g. dbms servers)?
I don't have any specific need for that; but consistency is always good.

Yes, The PID info will be reported for all of the GCF servers such as GCC (Comm Server), GCN (Name Server), and GCD (Data Access Server) except GCB (Protocol Bridge Server) which doesn't have the iimonitor capability yet.

As far as I know (BTW, I am not DBMS server expert), the DBMS server seems to report the PID info in the "show system sessions" command o/p as shown below ( see the label OS_tid: ). Displaying the PID info as a part of session info in the case of GCF servers doesn't make much sense because the PID doesn't change between sessions...

So, the answer is a no. i.e the dbms, dmfrcp, and star servers doesn't display PID info in the "show server" command o/p. It seems that the PID info is provided in the "show system sessions" o/p ( look for <admin job> session )....

Regards,
Usha


% iinamu
Ingres NAME SERVICE MANAGEMENT UTILITY --
-- Copyright (c) 2009 Ingres Corporation
IINAMU> show servers
STAR * 32911
DASVR * 32910
COMSVR * 32909
INGRES * 32908 (sole server)
IUSVR * 32907
IINMSVR * 32906
IINAMU> quit

% iimonitor 32908
IIMONITOR> show system sessions
Session 00000001:1075558080 ( <admin job> ) cs_state: CS_EVENT_WAIT (BIOR) cs_mask: CS_INTERRUPT_MASK OS_tid: 19713

< SNIPPED: other sessions info>
.....
....
IIMONITOR> quit

% ps -ef | grep 19713
ingres 19713 1 0 14:29 pts/7 00:00:00 /home/ingres/bin/iidbms dbms (default) MB
ingres 21283 11151 0 15:06 pts/7 00:00:00 grep 19713