UNIX Agent Troubleshooting – Real World Case Study

Blog Post created by Anthony.Yip Employee on Mar 26, 2019

This article relates to a real-world case – the customer’s name has been omitted.

The issues raised were all relate to the UNIX Snow Agent. The customer needed Oracle scanning, so the SIOS.jar process was running with the standard snowagent.jar scan. Before we begin, we must remember that:


  • We strongly recommend Java Runtime Environment (JRE) version 1.8 is used. 1.6 is the oldest version supported, but performance is best on 1.8 or above.
  • NFS (Network File System) mounts are rather common place on UNIX boxes – essentially, these are remote directories, much like network drives on Windows.


Mounting Issues and Troublesome Runtimes

The customer came to us reporting that the UNIX agent was taking too long to complete the scan and the Oracle scan. Why was this?

Two main reasons – the UNIX boxes in question were using JRE 1.6 and there was also a large amount of NFS mounts that the agent was trying to scan every time. This could have resulted in many, many more GBs of data being scanned, across the network, unintentionally.

The issue with the NFS mounts was easily resolved by looking at the snowagent.config file and adding exclusions for those mounts:



Next came the issue of the Java runtime – the system JRE was version 1.6, which is supported, but it is recommended to use 1.8 – which is precisely what we did.

The problem is, it was not desirable to upgrade the system JRE on all the UNIX boxes. The solution, therefore, was to specify our own JRE that the agent can use.

First, the version 1.8 JRE was placed in the agent directory - /opt/snow.



Next, the snowagent.config file is modified:



The value highlighted here can be modified to point to a specific Java Runtime.

Problem solved – almost. The crontab also needs to be changed. The crontab is how UNIX\Linux devices schedule processes. Crontab, by default, looks like this:



The crontab line as shown above was changed:




This troubleshooting and resolution method provided a fix for this customer’s particular “pain points” without the need for any down time for major changes to their platform.