Re: Bogus PID for client on another host

If you look on tolkien you should find a running Informix instance and process 3458 should be one of the oninit processes, probably CPU VP #1 judging by the frequency of its appearance. Any connection from that machine that does not use an explicit CONNECT TO statement and has the local tolkien engine in its INFORMIXSERVER environment variable is connecting to the server on clancy through the local engine on tolkien and so the actual PID that has made the connection is not the client process on tolkien but the CPU VP that has been assigned that session's sqlexec thread to execute. You can change things so that you get actual client pids by either changing the remote apps INFORMIXSERVER var, before startup or with a putenv() before the DATABASE statement, or by adding an explicit CONNECT TO statement before the DATABASE statement that opens the connection directly to the server on clancy. Either method will bypass the local engine instance on tolkien and connect directly to clancy which BTW is faster and unburdens the tolkien server from acting as a pass through for all that communication. If your apps need data from both servers consider separate connections to the local server on tolkien and the remote one on clancy and switch back and forth. You will not be able to join that way but everything will run faster even if you have to do your own nested loops. Art S. Kagel Jacob Salomon wrote: > > Hi Family. > > I wanted to write a shell script to kill every process connected to the > Informix environment. I planned to do a kill -2 on every PID in the > output of onstat -g ses. (kill -1 won't work on nohup and cron jobs > while kill -9 would not allow them to clean up. But that's another > story.) > > While testing this with commands directly from the shell, I found > something interesting - a bad sign. Here is a gleaning from the output: > > session #RSAM total used > id user tty pid hostname threads memory memory > 5938 root - 0 - 0 8192 4824 > 5937 autosys - 6334 clancy 1 49152 31320 > 5936 root - 0 - 0 8192 4824 > 5933 root - 0 - 0 8192 4824 > 5932 onamc - 3458 tolkien 1 98304 90736 > 5931 root - 0 - 0 8192 4824 > 5930 onbcg - 3458 tolkien 1 106496 94424 > 5928 autosys - 6251 clancy 1 466944 366360 > 5920 product - -1 a1ddf037 1 65536 50192 > 5906 dbcxw CWILLIAM -4063121 cwilliam 1 40960 29296 > 5905 dbcxw CWILLIAM -4063121 cwilliam 1 155648 85696 > 5902 onvxw - 3458 tolkien 1 122880 90688 > 5886 autosys - 5975 clancy 1 2670592 1227728 > 5880 autosys - 5933 clancy 1 303104 148224 > 5878 tsr032 - 3458 tolkien 1 114688 107520 > 5876 onlkd - 3458 tolkien 1 122880 94440 > 5873 onmxb - 3458 tolkien 1 106496 97272 > 5865 ontnr - 3458 tolkien 1 122880 113296 > > Note that PID 3458 is repeated several times, although the lines it > appears on are clearly different sessions and users. The pattern is > that that host "tolkien" is another machine. (clancy is the DSA system > that I am working on.) The PIDs on the lines with host clancy are > unique and mostly OK, though they may be gone by the time I run the > PS. But that repeated PID 3458 for the clients on another host is a > mystery. It does not represent a process in my system at all. > > Note also the negative numbers in the PID field on some other lines. > These are client-server clients like PowerBuilder or something elso > running on PC's. There are many in the actual output. > > Bottom line: > How do I kill the remote client? Or rather, how do I sever the > connection so that the remote client knows it has been cut (with an > error message from its side of the connection)? > > What does that bogus PID represent anyway? > > Thanks. > -- > +---- Jacob Salomon DBA JSalomon@bn.com ------------------+ > |(In perpetual pursuit of undomesticated semi-aquatic avians)| > | The expedient performance of a task with excessive concern | > | regarding its duration-to-completion engenders a virtual | > | certainty of diminished benefit therefrom. | > | -- Benjamin Franklin (but he said it in 3 words) | > +------------------------------------------------------------+ > > Sent via Deja.com http://www.deja.com/ > Share what you know. Learn what you don't.