How to capture the value of ./sas.servers status in a variable to use in a shell script

[_hnsj]

Hello,

I want to automate the SAS start up process using linux shell script. For that purpose before running "./sas.servers start", I want to check if services are already UP or not. Can you please help in figuring out how to check the value of "./sas.servers status" in a script. Is there any other way to check if SAS services are UP in a script?

Thanks

[jakarman]

What do you mean by checking the servers are up.?
a- There is some pid present in the running process that has been started by SAS .
b- The process is running /functional operating/  when called it gives a correct reply
The difference by those is that the pid as seen by a/ can be hung or got corrupted. For a pitty this is the SAS approach of checking "running".

The servers status script is calling the composed scripts of every service that read the started pid from some file that has been saved when starting

For the latter one you need operational keys to verify some basic functions  are working.

Some process cannot be easily seen as some running process as eg the RMI server part of the java web midtier.

An url check could solve that issue. 

Other servers are not services at all as nothing really is running. Then batch server for example is just some shell script at the config directories

[ronan]

I assume you are running SAS on Unix/Linux. The launcher "sas.servers" already takes care of this : try, for instance, to launch the start up command 'sas.servers start' with SAS services already launched (several times in a row if you like) and it won't return any error.  Furthermore, if some of the SAS services are in the "stopped" state, then running 'sas.servers start' quietly leaves the active services running and starts up the ones still to be launched. Quite simple. :smileycool:

[jakarman]

ronan the sas.servers scritp are made for interactive usage. The question is aiming to solve this by in house monitoring tools that are not aligned with SAS proposals. Normally there is a dedicated department (the bridge) that is delivering that kind over services of availability and continuity. At that department a dedicated sas platform admin for a unique solution is not wanted.    Quite simple.

Those script with the sas.servers do not offer a check on operationally availability. Just go and analyze those and you will have to admit that.
It is not a good situation that services can be non-operational expecting customers to complain on that. The goal is recognizing that and repair before they complain. (see ITIL)  

[ronan]

Jaap Karman wrote:

ronan the sas.servers scritp are made for interactive usage.  

Where on earth have you figured that the scripts were made or even intended only for interactive usage ? :smileyconfused:  The documentation tells otherwise and the admins experience confirms that it can sucessfully be run in batch mode also :

https://support.sas.com/documentation/cdl/en/bisag/67481/HTML/default/n1fxn02xr08732n1p0kph4z4145t.h...

Furthermore, if you look at the script's top header lines (Unix/Linux), you will find how to install the scripts into "init.d" in order to launch automatically SAS servers during the boot sequence : hardly surprising, it's pure shell scripting 100% compatible with non interactive sessions.

[_hnsj]

Ronan - Thanks for the response. Yes, we are running SAS on Linux.  So what you are suggesting is that there is no need to check if SAS services are already running before starting them. If they are already running "./sas.servers start" would not take any action and would not interrupt already running services. 

[ronan]

Exactly. The script checks by itself before launching the SAS servers. I stongly recommend you to try it by yourself. I have tested this behaviour on 9.2/9.3 Linux platforms.

Incidentally, I had to modify in depth the script myself which gave me a somewhat good knowledge of its code. I needed to change the frequence of the SAS server Log files (by default, daily to monthly). As far as I can tell, it's reliable though difficult to modify specifically for my purpose.

[jakarman]

That is going into the hell by inventing out, trying to get these processes aligned into security policies as of regulations and the in-house IT policies.

Those machines should be able to be operated by common support staff. That is not Ronan/Jaap or any other platform admin personally.

The big problem is that SAS is violating those guidelines and doing different things. The SAS documentation can tell a lot but when its wrong it is wrong.

You didn't follow my advice and do the research on the way the status is solved in those scripts.

I did had problems with a reliable weekly restart of the services using the adviced SAS approach. So I did debug those scripts and analyzed  them. There was no help from SAS TS as not understanding or willing to understand the issues. What I have found is: 

- The metadataserver is started (detached background). The object spawner is started after some planned time (sleep function) not really checking the availability of the metadataserver. That was problem 1/ It could happen the objectspawner did start but could not retrieve the needed metadata. Only by seeing missing content (comparing) that problem could be recognized. It can be checked fully trustworthy by using a proc metaoperate doing a real login.

Seeing the start en status check being coded, that is the pid-number check. If you are convinced the pinging of a server is the proof the server runs, than there is long way to go for some learning.      
- The same issue was recently seen with the connectspawner as also changed to retrieve information from metadata. It failed and customers complained.

- With Eminer there is a Rmi service needed hardly to recognize. Customers complained they could not login. Than found the service was corrupted started by validating the test-url as documented. Not it is not in the servers.sas. script.

While reviewing those scripts  Than seeing another coding problem. You need some background on C-language.  The coding issue: the $*  is giving the string unchanged to another script (the whole string as is) would you code $1 $2 $3 than the string is first evaluated and than composed to an array of strings (arg argcount C functions) the effect is that the original string gets broken.  The difference looks not that big but when you quoted arguments and spaces you get into trouble. Do you have a batch-script (batchserver) with logging configured than try to use sas code with spaces in the name. It will dump with all kind of messages where the first troublesome one is the wrong default directory setting (sas note  can be given).

Some more issues?
- sasauth did not check the normal Unix root conventions (locked users after x-attempts) There is change on that.
- having tested that locking of the account (working now) finding sas did add unmentioned actions on top of that. Locking out 5 minutes at the same moment you can do a login with putty. There is no need to put something on top of that . The Unix policies are set and accepted by business policies.
- The restart of the services (complete system) was planned because every wrong login added 5 additional seconds for all users (somewhere internal). It could happen the metadataserver did not react for some some 1or 2 hours and  than processing again.

Where on earth did you learn that SAS institute delivers failure free software and you can trust them for everything on that.

Please get critical and do the research and the validation of what is there and than react accordingly. 
I mentioned the experiences by solving issues, that is going beyond what is documented and expected.

[ShelleySessoms]

Hello @hnsj,

Thanks for using the community. If there are unresolved issues, please add more detail into the original thread about what you've tried already.

In these communities it's regarded as a good practice to share as many details as you can, including what solutions you've already tried with their results.  The folks who answer lots of questions here simply want the best chance at providing an answer that will fit your situation.

Also, it might be correct that SAS could provide more guidance on this particular questions. We are checking with our internal experts to see what additional information that we can find to share. We'll post back with our findings.

And -- a side note -- English is not the first language for everyone here, so sometimes responses can come across sounding a bit curt to native English speakers.  We appreciate that responders are trying their best to help our global audience.

Best Regards,

Shelley Sessoms

SAS Online Community Manager

[jakarman]

@hnsj  get confident with the dependicies between servers. At that point the SAS docs are good.
There are also the notes to take care off
Metadata and compute servers: SAS(R) 9.4 Intelligence Platform: System Administration Guide, Third Edition

some of those can be restarted from the SMC (objectspawner)
Midtier: SAS(R) 9.4 Intelligence Platform: Middle-Tier Administration Guide, Second Edition

VA: SAS(R) LASR(TM) Analytic Server 2.2: Reference Guide

Just having a "sas.servers start" will try to start all of them in the correct order on the current machine. It can not solve stuck/blocked services. You have the be sure that is not the case. A sas.servers stop (all) and verifying those are stopped is a more secure approach.  

[_hnsj]

Thanks Jaap.