How to know when workspace server process has ended?

[Perttu]

Hi all,

I'm running SAS 9.4 M2 platform on AIX. I need to copy all
workspace server logs to network share for users to have an easier
access to them than on server filesystem.

I want to copy the log file immediatly after process ends on the
server. However, I haven't found any way to know WHEN a process
ends. I was hoping there was a SAS-hook or something that is run every
time SAS -process exits but I haven't found anything like that at all.

Now I've put a filesystem monitor to watch SASWORK -directory and
everytime a directory is removed (SAS-process cleaning up) script
tries to find a matching log file and if found, then copy it to
network share.

Is this a viable aproach? I'm a little uncomfortable with it and would
prefer a more "SAS like" solution.

Any ideas would be wellcome.

--

Perttu

[Kurt_Bremser]

From the POV of the operating system, the right place to do this would be the WorkspaceServer.sh script. Add a line at the end that copies the log file to where you want it, that spot will be reached once the SAS process has ended.

The only problem with this approach is that this file is not supposed to be changed by the user, as it may be replaced/overwritten during SAS updates.

[Perttu]

I think this wouldn't work because of all the execing.The calling process is replaced with the exec'ed process.

WorkspaceServer.sh execs $SASHOME/sas which in turn execs the sas -binary. When sas-binary exits there is no $SASHOME/sas or WorkspaceServer.sh -processes left to return to. So the end of the WorkspaceServer.sh script wouldn't get run.

[Kurt_Bremser]

You're right. One would need to remove the "exec" from the last line of the WorkspaceServer.sh.

[Kurt_Bremser]

One other solution that came to my mind: why not create a symbolic link from the webserver's htdocs directory to the log file location and enable the directory index there? Or run a script periodically that creates a index.html file from the currently present logs.

[jakarman]

Perthu are you really asking to copy logfiles being generated by a SAS process under a Unix OS system being copied to a networked loaction as users are only knowing how to interact with Windows? Than find some nice tool that gives an approach like windows (any nice sftp program like winscp) and definine a logical link in their home location.  Defining an associated program to the unix suffixes will give them their usual windows behavior.

[JuanS_OCS]

Hi Perttu,

Your solution can be acceptable, so far, from my point of view.

If it is just a matter or having an constantly version of the log files on a different location: have you already considered to have just a sync process attached to a monitor process to monitor changes on the workspace server logs, so you can trigger the sync process as soon as a change arrives?

I think rsync could be your sync tool here.

[Perttu]

Hi Jan,

That is how things are at the moment. Users are using WinSCP to access log files.

That is not ideal solution however. The server log directory is technical location. I (as a platform admin) compress logs after a few days there and remove them altogether after 3 months. Users need production documentation. Some code is only run once a year. They need to save those logs for longer time and alognside their other documentation. I can't just leave them to fetch the logs for themselves since some code is run from non-SAS -interfaces and applications. Users don't know what / where those logs are. The logs themselves know where they should go 🙂 I just need a way to help them get there reliably.

[jakarman · Accepted solution]

Those requirements sounds as reasonable common compliancy questions - requirements.

The most easy approach:

- The appserver is dedicated to that isolated customer. All configuration in config-files in the app-server (WS batch connect whatever you use) can be made there.
- Do not use the default config/lev_ of the klik klik yes installation process where appserver strorage is placed. That one is indeed a technical location without any code/data/og segregation being a complete mix up of everything.
What you need is the location ( some locatins) where they are stroing their data code and there coudl be room for logs documentation and more. There should be adequat backup/restore procedures at the Unix. There is no need for windows usage at all.
To achieve that you need to help them show them convince them.
- Have those WS logfiles stored at their location an make them repsonsible for the sizing / removing. You are the technical one did not mention the need for those files. Your users want them. 
- The current directory is a challenge wiht the WS. It has been implementd wrong by SAS. http://support.sas.com/kb/50/345.html

A more advance one:

- Having the WS defined in the ARM (log4j) config files you probable noticed the date-time and rollover settings. (Ronan's links)
  The SAS log file name is not fully known at the scripting stages it is filled after arm did some things. The logfile at startup doesn't need to be the same as at the moment of ending.
- Wanting those logfiles be copied to the users location and having a technical one for logfiles as you are doing now there is some duplicating.
- I expect the saslogname being available in a SAS session in some macro or by using a pathname function.

- I expect the name of the wanted SAS log location as known by your users is availabel in the SAS session (when nog define that).

- The initstmt and termstmt config options of SAS is giving you an option to define a Logical link at a user location pointing to the techical one. With Winscp you can see it is a link. Than it just needed to be copied by your users.    
http://support.sas.com/documentation/cdl/en/lesysoptsref/68023/HTML/default/viewer.htm#n16z79lqkz4a8...
http://support.sas.com/documentation/cdl/en/lesysoptsref/68023/HTML/default/viewer.htm#n0rjd82dx13qi...
- To define that logical link the SAS sassion need to be able to run xcmd (it is a config setting). Should be no problem as your users are using winscp. They have access that way to the machine. 

 An other working approach:
- why not use a batchserver approach. That is a similar one as the WS in the appserver meant to run in batch
  Calling that one directly  (Xcmd) you could redirect all locations as needed.      

[Perttu]

> locatins) where they are stroing their data code and there coudl be
> room for logs documentation and more. There should be adequat
> backup/restore procedures at the Unix. There is no need for windows
> usage at all.

We do have separate data and code area not related at all to SAS
-installation and it's paths. In principle logs could go there but
users don't usually access that area directly. Only through libnames.

> To achieve that you need to help them show them convince them.

> - Have those WS logfiles stored at their location an make them
> repsonsible for the sizing / removing. You are the technical one did
> not mention the need for those files. Your users want them.

Heh, on the shared Windows DFS file system users ARE responsible for
sizing and removing. And the files are out of my systems 🙂

> - The initstmt and termstmt config options of SAS is giving you an
> option to define a Logical link at a user location pointing to the
> techical one. With Winscp you can see it is a link. Than it just
> needed to be copied by your users.

> http://support.sas.com/documentation/cdl/en/lesysoptsref/68023/HTML/default/viewer.htm#n0rjd82dx13qi...

termstmt seems very interesting possibility 🙂

It appears to be doing exactly what I want. I just need a mechanism to
launch log copy script when workspace server ends. In TERMSTMT I have
both the process id and log file name readily available. It seems much
more robust than my current system where I monitor SASWORK -directory
for ending processes and the log file name and location are just hard
coded to script from workspace servers' logconfig.xml.

Thank You,

[ronan]

Hi Perttu,

As far as I've come to understand your approach :

1. you enable workspace session logging (initially disabled)

2. since the location of the log file is out of reach of the users, you wait until the session is over then transfer/copy the file into a Windows shared location

3. the end user opens up the log file on Windows with the shared location

If you modify the logging parameters in order to redirect the Wk logfile location to your shared folder, using log4sas then the two-step approach 1-2  could be reduced into one. 

https://support.sas.com/documentation/cdl/en/logug/67485/HTML/default/titlepage.htm

I am not familiar with AIX, nor with workspace logging (used sparsely for tracing bugs, in my case) so this might not be 100% "workable". I suppose, for instance, that zipping the sometimes huge log files (100s of Mb if not more) could be more appropriate than keep them in-place uncompressed but all that depends on your specific requirements.

Another approach would be to enable the Analysis and Performance Managment tools now provided withe SAS Environmeent Manager (SEM) and known as SEM Service Architecture Framework . It isn't aimed at collecting complete log sessions but rather recording some performance and usage metrics based on ARM (less detailed but more coherent picture) :

https://support.sas.com/rnd/emi/SASEnvMgr/EVSAF/SAS_Environment_Manager_Service_Architecture_Quickst...

https://support.sas.com/documentation/cdl/en/evug/67886/HTML/default/viewer.htm#n0y0zbl7hnj8yhn1thh0...