HP3000-L Archives

March 1996, Week 4

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Eero Laurila <[log in to unmask]>
Reply To:
Eero Laurila <[log in to unmask]>
Date:
Thu, 21 Mar 1996 08:15:50 GMT
Content-Type:
text/plain
Parts/Attachments:
text/plain (70 lines)
Hi folks,
 
  Just back from IPROF and some discussions around the subject on how to
  get rid of some processes that are hanging onto some network stuff...
  Discussions continued onto NSCONTROL KILLSESS, abortjob, aborting specific
  pins and so on... and the unix kill command.
 
  Putting all of the discussion on killing a random process with some new MPE
  command aside (since that's not an area that I could impact),  I was left
  thinking the network side of it...  and what about a possibility to kill
  all of the network connections of a process.  That would translate into a
  socket I/O completion with an error status and if the application was
  waiting on a socket, it'll certainly get moving.  If it has proper error
  handling in place, it should report some error(s) and terminate.
 
  Note also that when I say "all of the network connections", what that means
  is TCP connections.  Of the protocols (on 3k) running over IP (TCP,UDP,PXP),
  only TCP is connection oriented, i.e. no other protocols have connections.
 
  So, I wondered back to office and wrote some more code and now I have a
  new feature added to the :SHOWCONN's program file (sc.pub.sys), which
  enables it to kill any connection of any process...  I tested it on a
  variety of connections (VT sessions, DSCOPY's, FTP's etc) and it works
  like a champ!
 
  I also tried some incorrect actions like trying to abort all the
  connections to DSDAD, FTP monitor, progen and so on.  All those are
  harmless since none of those guys have any connections.  Either they
  just have listening sockets or no sockets at all.  So, it seems to work
  just as expected.  Also, it uses the exact same mechanism than NSCONTROL
  KILLSESS uses with the exception that it'll act on any process that has
  a connection, not just incoming VTSERVERs as NSCONTROL KILLSESS is
  limited to.
 
  Questions I have are:
 
  1. Do you think this would be useful?
 
  2. If so,  what kind of syntax this little freeware piece should have?
 
  2.1. Should it be a separate command file driving the sc.pub.sys?  Say:
 
          :ABORTCON pin=xx
 
  2.2. An additional option to the showconn script.
 
          :SHOWCONN pin=xx;abortconn=true
       or
          :SHOWCONN pin=xx;kill=true
 
  2.3. Something else ??
 
 
  I tried all above here and am not sure which one I like.  Probably the
  new, separate command file.  Given the power of such a command, I thought
  it might be well appropriate to restrict it to work with the pin= parameter
  only.  I don't like the idea of allowing any of the other SHOWCONN syntaxes
  (such as :SHOWCONN;SYSTEM;KILL -or- :SHOWCONN JOB=#Snnn;abortconn) to work.
 
  The advantage of the new command file is that the command name would be
  more descriptive and it would be very easy to limit the command to act
  on the pin number only and make that a required parameter.  Downside is
  of course yet another command to remember...
 
 
  Anyway,  food for thought...  any and all opinions are welcome.
 
Cheers,
:-) Eero Laurila - HP CSY Networking lab, NS services.

ATOM RSS1 RSS2