Date:         Thu, 28 Feb 2002 16:13:02 -0000
Reply-To:     "roland.rashleigh-berry" <roland.rashleigh-berry@NTLWORLD.COM>
Sender:       "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From:         "roland.rashleigh-berry" <roland.rashleigh-berry@NTLWORLD.COM>
Organization: ntlworld News Service
Subject:      Re: Killing UNIX Processes

Another thing that might apply or might interest those following this thread
with a similar but not identical problem is the SAS work files left over
from failed jobs or broken sessions. This can cause a filling up of the
allocated work space for all SAS work files on the system. It may be wise to
delete these too if they exist. But my recommendation is to find out whether
this is indeed a problem and get the Unix administrators to add something to
the SAS invocation to delete this if this is indeed the case. They will be
able to write better scripts than we can and it is their job in any case and
they should feel they are in control of the situation and maintain an
awareness of these and similar issues.

"Karl W. Schaefer" <kwsnews_spam_me_not_@earthlink.net> wrote in message
news:3C7E452F.3050809@earthlink.net...
> I've been watching this thread with genuine interest as this issue has
> been a challenge many times over.  I applaud the suggestions provided
> already, and would like to further the challenge to this list's
> community.  Thus far, unless I am overlooking something, each offering
> makes one significant presumption that at some point in time through the
> day nobody will be on the server using SAS/CONNECT.  One suggestion did
> make a partial account by presuming if there was a date instead of start
> time reported that the job is worth consideration for killing, but there
> is still a presumption involved.
>
> Here are some (not all) of the more significant offerings thus far in
> the current thread:
> 1) Dr. Diego Kuonen offered:
> pid=`/usr/bin/ps -eo pid,comm | /usr/bin/awk '{ if ($2 ==
> "/path_to_sas_exectutable") print $1 }'`
>
> This is nice, but makes the presumption at runtime that ALL sas jobs are
> in need of being terminated.
>
> 2) Patrice Michel suggests that the rogue processes do not have parents,
> this may be true in his case but not in all cases.  I currently have a
> job in Solaris 8 that is a SAS/CONNECT job which I know is rogue because
> there are no active TCP/IP connections to the port or it's name
> identified in /etc/services, and the sastcpd uses -inheritance option,
> so I know specifically which port to look for.
>
> 3) Michael A. Raithel offered a SAS job to run that stems around a ps
> sequence:  filename zombies pipe "ps -ef | grep sas | grep '?' | grep
> '[-]dmr [-]comamid tcp [-]device grlink [-]noterminal'";
>
> This also is nice, but unfortunately flawed still with presumptions.
> The succesive pipes continuously reduce down to just processes
> associated with SAS/CONNECT.  Again falling on presumption at runtime
> that ALL SAS/CONNECT processes are in the rogue status.  I'd also like
> to point out that the sequence of parameters in the final grep very well
> might be different on your own systems.
>
> 4) Roland Rashleigh-Berry expanded on Mr. Raithel's input and shared a
> script he uses to prompt a user to say yea or nay for jobs he suspects
> as rogue.  His suspicion indicator is if the STIME output of ps contains
> a date and not a starting time of day by looking for the colon.  The
> grand thing about Roland's offering is it doesn't just presume and
> slaughter, but rather asks permission to shed electron blood.
> Unfortunately that means that the users who are able to run SAS/CONNECT
> also periodically come to Unix command prompt where the script could be
> invoked from the likes of a .rc file (Unix equivelant to AUTOEXEC.BAT
> for users), and therefore the process is not something that can be added
> to the crontab table by root without making the presumption.
>
>
>
> These are all excellent offerings as long as you want to assume that all
> qualified jobs are actually not in use and thus in need of termination.
>   The diversity provided by SAS for invoking SAS/CONNECT sessions with
> parameters to the sastcpd command, also adds additional challenges.  (My
> personal favorite way of invocation is to involve both noscript and
> inheritance.  The noscript forces use of sascmd but knocks out startup
> by way of client scrips such as the common TCPUNIX.SCR under the SAS
> install's SASLINK folders.  And using inheritance causes the Unix side
> to inherit the opening port and socket for use by the connect session.)
>
> Something to consider that may help reduce the presumption that all
> found jobs are suspect as rogue, would be to check some other system
> resource. I am surprised that such has not been mentioned previously to
> aide in identification of truly rogue processes instead of making some
> sort of potentially false presumption - how uncharactaristic of a group
> of attention-to-detail programmers such as we are, don't you think?
> *smirk*
>
> My additional suggestion would be to incorporate netstat.  Presumption
> could be eliminated if one specifically checks to see if there are any
> established tcp connections to the port used by SAS.  (Using
> -inheritance helps in this as you are down to one port or /etc/services
> name to look for.)  If there are no established connecitons on the port
> or name you're looking for, then and only then is it safe to presume ALL
> of the system's SAS/CONNECT processes are in fact rogue ones.
>
> That may well suffice for most applications and a significant majority
> of times.  But what if it is commonplace to have users connected at all
> hours of the day?  The obvious ultimate goal being some way to identify
> truly rogue SAS/CONNECT tasks and then kill only those, thus allowing
> others to continue their tasks.
>
> On my RedHat 7.0 system, I can issue the command "netstat -pA inet".
> This yields process numbers and commands for inet activity, and I could
> easily grep this for the name I gave in /etc/services for my sas spawner
> to identify the parent processes to potentially live connect sessions.
> And with the process ID information I can selectively kill parent
> processes not found to have active TCP/IP connections established. (The
> use of -noscript -sascmd 'xxx' causes two processes for each actual
> SAS/CONNECT session, one for the script that is the shell process, and
> then the sas process called by the sascmd or sascmd script itself.)
>
> Unfortunately in Solaris 8, the same netstat command does not work.  I
> can limit to inet activity with "netstat -f inet" however I've not yet
> found a way to identify process id's associated with the connection. And
> this is my further challenge to anyone willing to take it on.
>
>
>
> Karl
>
>
>
> Nigel Pain wrote:
>
> >
****************************************************************************
*
> > This email and any files transmitted with it are intended solely
> > for the use of the individual or entity to whom they are addressed.
> >
****************************************************************************
*
> >
> > Not strictly SAS, but SAS is at the root of the problem:
> >
> > We are running 6.12 (soon to upgrade to 8.2) on Solaris and NT
> > Workstation, with users either working through SAS/Connect or directly
> > on the server with X-Server S/W (Exceed). On a regular basis, users
> > close their SAS sessions but somehow leave the UNIX process running (I
> > suspect in many cases this is due to omitting to signoff a remote
> > session, no matter how often we implore them to do so).
> >
> > It's easy enough to go in periodically to check for redundant processes
> > and then kill them, but I'm sure there must be a way to identify these
> > processes in some kind of shell script. Unfortunately my shell script
> > skills are not up to it. Are there any clever, kind, generous ('scuse me
> > while I get my trowel to lay it on thicker!) UNIX gurus out there who
> > could suggest something so I can automate the procedure? At the moment I
> > identify processes with the ps command piped through a series of greps
> > to narrow it down to SAS sessions and then use the kill command.
> >
> > Thanks
> >
> > ***************************************************
> > Nigel Pain
> > Scottish Executive Development Department
> > Business Support Unit
> > Victoria Quay
> > EDINBURGH
> > EH6 6QQ
> > UK
> > Tel +44 131 244 7237
> > Fax +44 7092 014235
> >
> > Mailto:nigel.pain@scotland.gsi.gov.uk
> > Website: http:\\www.scotland.gov.uk
> >
>
>
> --
> Karl W. Schaefer
>
> Note: Please remove the obvious between and INCLUDING the
>        underscores if you wish to reply to this message.
>