Whether you are a new SAS administrator or switching to a Linux environment, you have a complicated mission. This job becomes even more formidable when you are working with a system like SAS Visual Analytics that requires multiple users loading data daily. Eventually, a user will have data issues or create a disruption that causes the system to malfunction. When that happens, what do you do next?
In this post, we will go through the basics of how to troubleshoot the system when issues arise.
When you need to troubleshoot the system, it is useful to know some commands that help you determine the application and system status. This post provides some helpful guidelines.
Is SAS Visual Analytics Running?
There are several scripts in the Lev1 directory that are used to control SAS Visual Analytics and its supporting processes. The sas.servers script is the main one. It has four parameters that allow you to control what happens: start, stop, restart, and status. As you might guess, the start parameter begins all processes, and likewise, the stop parameter ends all processes.
When you run sas.servers with the status parameter, it shows the server status. In the following example notice that the servers are UP, which means they are actively running. Note when running a script, you must append a “./” before the name to run it. This indicates the script is in the current working directory.
The SAS Servers need to be started in order, which this script handles. Notice that the SAS Metadata Server is begun before the Object Spawner and Web Server. The Metadata Server must be running so that permissions can be checked and other server connections can be made. SAS Visual Analytics is running when the SAS Web App Server SASSERVERn shows as “UP.” When we were looking at the logs, the logs were associated with SASServer12_1. Refer to the system administration documentation for a complete description of sas.servers script.
Note: If you are starting the sas.server processes you must be logged in as the SAS Installer (sas) account.
What Linux Processes are Running?
Linux refers to running applications as processes or jobs. When a process is started, it is assigned a process ID, which is called a PID. You can see running processes and stop the process if necessary.
View Running Processes
In the following example, you can see the output of the PS GF command. The output has the following columns: PID, TTY, STAT, TIME, and COMMAND. With this command, you know everything running under your group and how long it has been running. Most of these applications should look familiar – for instance, notice the Command column shows the Object Spawner and Metadata Server. This figure shows the result of the sas.servers script.
Stopping Long-Running Scripts
If the output is long, you may want to narrow the list down further so you can see a specific process. This example is another practical use of the grep command. For instance, suppose the Autoload script was having issues and needed to be stopped.
Let’s use some of our commands to find the process and stop it. In the following example, the ps and grep commands are combined to search for the Autoload.sas program. Notice that when the results return, there are two PIDs. One for the autoload process, and one for the grep process.
Once the PID is identified, the process is stopped. To confirm the process was stopped, repeat the initial command. Notice that the PID value changed for the grep command. This is a separate instance of the grep command, so Linux assigns a new PID.
Caution!
- When using kill, you must be accurate. You can inadvertently kill a needed process by transposing a number. You might prefer the cut-and-paste method over your typing skills.
- Avoid using the kill command to stop the SAS services. Use the sas.servers script instead.
Determine System Health
The following commands help you understand the status of the environment.
Review Disk Space
Use the df command to review the disk space. Sometimes errors occur because the server lacks room to process commands. In the following example, the df command shows the space on the devices. Watch the Use% column. If the primary server was above 90%, you might want to investigate the issue.
Find Process Hogs
When an application has an issue, it might consume all available CPU or memory. Use the top command to review the running processes along with other system statistics. Type q to return to the command line.
Finding a Log
Any platform administrator knows that logs equal life. The logs reveal the mysteries of the system and can “save your bacon” as Patrick Cuba so elegantly stated. The find command is useful for locating the logs. For instance, maybe a user notes the SAS Visual Analytics Designer is having issues, but you cannot recall the logs specific location. You can use this handy command like so:
[sas@server1 Lev1] $ find . -iname "*design*.log"
Here’s the basic syntax from the above command:
find <where> <options> <search string>
In the above example, I searched the current Lev1 directory and subdirectories (indicated by .) for any logs (shown by -iname) that had “DESIGN” in the name (indicated by “*design*log”). Adding the -iname stated the search was case insensitive. Notice that when I run the command, there are two results – that’s okay its the first one I’m seeking!
Debugging Like a Real SAS Administrator
Several commenters noted that you might need more information and the command might return more results than you want. Or you might get meaningless permission errors. Notice that the grep command was added to give the find a little more oomph.
find . -name "*SAS*.log" -exec grep -i "ERROR:" {} ; 2>devnull -print
The above command builds on our search. The -exec command says when you find these logs, search the content for “ERROR:” and output to the display.
What You Should Do Next
If you are a new platform administrator, here are some things you should do:
- Read the SAS Visual Analytics administration manual so you are familiar with the tool and what customizations you can make.
- You learn some basics of the SAS Visual Analytics front-end environment. When a user contacts you with an issue, you should at least understand the differences among the web applications.
- Learn to use the SAS Management Console and SAS Environment Manager. You should also read the SAS documentation for these products.
- Seek classes or assistance from others as you learn.
…..