[Info-vax] TCPIP$RSH_RUN.LOG file

[John Santos]

In article <bb9ab5a0-1afb-4f9f-8957-
039cde62608d at f20g2000vbl.googlegroups.com>, bakermo at swbell.net says...> 
> Hello all,
> 
> I'm not too up on Digital TCP/IP and I have a question.
> 
> First I'm running
> 
>   DIGITAL TCP/IP Services for OpenVMS Alpha Version V5.0A
>   on a AlphaServer 4100 5/533 4MB running OpenVMS V7.2-1
> 
> This is a two node cluster with shadowed DSSI disks.
> 
> Recently changes to the business has increased the number of RSH
> connects I get during a day. Nothing is wrong and I can't change
> anything. It is what it is.
> 
> The TCPIP$RSH_RUN.LOG file is getting about 10000+ versions a day.
> Needless to say in 3 days I have to purge and rename.
> 
> The problem is that I have monitor the system constantly for a time
> when there are no connections so the file is not locked.
> 
> Is there a way I can stop the RSH process from creating the logfile?
> 
> I'd really like to either turn it off or dump to the bit bucket.
> 
> BTW - everything comes in under the same username and uses that SYS
> $LOGIN directory.
> 
> Any help would be appreciated.
> 
> John Baker
> Operations I&S Engineer, Collections
> 
> Thomson Reuters

I wonder if you could run something periodically (e.g. once
a day) that renames the directory that tcpip$rsh_run.log lives
in, and creates a new, empty one?  It should be possible to
do this even if there are open log files in the directory.

This directory appears to be sys$sysdevice:[tcpip$rsh], at
least on the TCP/IP V5.6.  I don't have any logs in any of
mine, but I think we don't use RSH much if at all.  There is
a login.com in it, though, which you probably want to preserve.

So you could do something like:

$ create/dir sys$sysdevice:[tcpip$rsh_new]/owner=system
$ copy sys$sysdevice:[tcpip$rsh]login.com sys$sysdevice:[tcpip$rsh_new]
$ rename sys$sysdevice:[0,0]tcpip$rsh.dir tcpip$rsh_old.dir
$ rename sys$sysdevice:[0,0]tcpip$rsh_new.dir tcpip$rsh.dir

There is a short race condition where no rsh directory exists
between the two renames.  Not sure what would happen if a new
connection occured during that interval.

You'll need bypass or system privilege to rename the directories.




You could make the directory used by the RSH server be a
search list, so it could fall back to the second translation
if the first didn't exist.  (It appears to be defined by the
default directory in the UAF definition for TCPIP$RSH, so
maybe you could set that to a search list...)

Then clean up the 2nd directory after you've finished cleaning
up the 1st one.

Or a different approach would be to redefine the default directory
in the UAF each day.  If a connection request arrived while the
UAF record was locked during the change-over, I think LOGINOUT
(or what ever is reading the UAF record) would handle this
okay by waiting for the lock to be released, which should be
just a few milliseconds.

Then clean up the old directories:

$ today = f$extract(0,11,f$time())
$ create/dir sys$sysdevice:[tcpip$rsh_'today']
$ copy sys$sysdevice:[tcpip$rsh_'yesterday']login.com -
	sys$sysdevice:[tcpip$rsh_'today']
$ mcr authorize modify tcpip$rsh -
	/default="sys$sysdevice:[tcpip$rsh_'today']"
$ ! do cleanup

Error handling, computing the appropriate value for the
symbol "yesterday", etc. left as an exercise for the reader.


-- 
John Santos
Evans Griffiths & Hart, Inc.