HP-UX monitoring scripts not using perl

When adding a component to a monitoring template, does the script have to be a perl script?

Can I use a normal shell script and for the command line just use ${script}?

I'm testing the monitoring of a HP-UX box with a simple "uptime" script and am not able to get a good result back.

My script is as follows.....

-------------------------------------------------
#!/bin/sh

utime=`uptime`
days=`uptime | awk '{print $3}'`

echo "Message: $utime"
echo "Statistic: $days"
exit 0
-------------------------------------------------

The script runs fine on the box outputting both the message and the statistic.

I have ${script} in the "command line" of the component section.

I am getting logged in and the script is attempting to run.

The status on the APM Component Details is as follows...
Linux script execution error. Script output did not contain required field "Statistic:". Actual script output begins ""

This is what the history is showing on the server....

sh
PS1='__SOLAR_WINDS_APM__'
cd /tmp
cd ~
pwd
cat>/tmp/APM_Script__61a96c88-ab94-42ce-9b01-9e660da8f96e.pl
chmod +x /tmp/APM_Script__61a96c88-ab94-42ce-9b01-9e660da8f96e.pl
/tmp/APM_Script__61a96c88-ab94-42ce-9b01-9e660da8f96e.pl & PID=$! ; (sleep 300; kill -KILL "${PID}") & 2>/dev/null; KILLER=$! ; wait "${PID}" 2>/dev/null; R=$? ; kill -HUP "${KILLER}" 2>/dev/null; rm -f /tmp/APM_Script__61a96c88-ab94-42

Being that it names the temp script xxx.pl, leads me to believe that SolarWinds wants to use perl for the scripts? I am able to run the temp xxx.pl script using the shell and the output looks good.

Any thoughts?

Mukey

Find more posts tagged with

hp-ux_scripts

Accepted answers

All comments

mukey

Update to my above post.....

I changed the script to a perl script, and I get the same results as above.

Here is the new perl script (yes, I know it doesn't really do much)

--------------------------------------------------
#!/usr/contrib/bin/perl
$utime = `uptime`;
$days = "23";
print "Message: $utime\n";
print "Statistic: $days\n";
exit 0;
--------------------------------------------------

Also, I noticed that it doesn't seem to be disconnecting the script user correctly. Below is the output from "who" and "last".....root is the only account actually logged in currently.

238 /home/user> w
1:48pm up 72 days, 3:41, 3 users, load average: 0.00, 0.01, 0.01
User     tty           login@ idle   JCPU   PCPU what
root     pts/1        12:49pm                      w
user      pts/2         1:39pm    22                -
user      pts/3         1:44pm     4                -

239 /home/user> last | head -25
user     pts/2        Tue Oct 7 13:49   still logged in
user      pts/3        Tue Oct 7 13:44   still logged in
user      pts/2        Tue Oct 7 13:39   still logged in
user      pts/2        Tue Oct 7 13:37   still logged in
user      pts/2        Tue Oct 7 13:22 - 13:27 (00:05)
root     pts/1        Tue Oct 7 12:49   still logged in
user      pts/1        Mon Oct 6 16:23   still logged in
user      pts/2        Mon Oct 6 16:18   still logged in
user      pts/2        Mon Oct 6 16:13 - 16:13 (00:00)
user      pts/3        Mon Oct 6 16:08   still logged in
user      pts/2        Mon Oct 6 16:03   still logged in
user      pts/2        Mon Oct 6 15:58   still logged in
user      pts/2        Mon Oct 6 15:53 - 15:53 (00:00)
user      pts/3        Mon Oct 6 15:52   still logged in
user      pts/2        Mon Oct 6 15:47   still logged in
user      pts/2        Mon Oct 6 15:42   still logged in

josh.clark

Is the Script Working Directory blank? Try setting it to . (a period). If the user doesn't have the current directory in their path (which is common for root) then when we try to execute the script it won't be found (that's what the 127 error code is from). I've opened a bug for this, but setting the Script Working Directory should work aorund that.

You can use scripts other than perl. We happen to give the script we create a .pl extension but we don't really care what the file is. We copy the text over, make the file executable, and then issue the command line you specified. That can be just ${SCRIPT} if the script will have a #!/path/to/whatever at the top.

mukey

The script working directory is currently set to /tmp. There are many temp .pl files that have been created by solarwinds in that directory and they are owned by the correct user. The temp scripts in /tmp can be executed by the user and the script completes as expected. From the history, the script is being called using an absolute path of /tmp/${temp-script}, so I'm not sure having the working directory in the user path would make much difference.

I will try and change the working directory to a . and see if that helps.

Even though the script has been removed from the node, it still shows the solarwinds script user as being logged in to the server?

mukey

I have changed the working directory to . and I get pretty much the same results. The user still seems to "hang" on the box.

The history shows the following commands being ran...

146     sh
147     PS1='__SOLAR_WINDS_APM__'
148     cd .
149     cd ~
150     pwd
151     cat>/home/user/./APM_Script__2ecc2817-85bb-45ee-8e5e-17e4111143f3.pl
152     chmod +x /home/user/./APM_Script__2ecc2817-85bb-45ee-8e5e-17e4111143f3.pl
153     /home/user/./APM_Script__2ecc2817-85bb-45ee-8e5e-17e4111143f3.pl & PID=$! ; (sleep 300; kill -KILL "${PID}") & 2>/dev/null; KILLER=$! ; wait "${PID}" 2>/dev/null; R=$? ; kill -HUP "${KILLER}" 2>/dev/null; rm -f /home/user/./APM_Script__2e

The Component Details in Solarwinds give the following error.
Linux script execution error. Script output did not contain required field "Statistic:". Actual script output begins "/home/user/./APM_Script__2ecc2817-85bb-45ee-8e5e-17e4111143f3.pl & PID=$! ; (sleep 300; kill -KILL "$..."

josh.clark

At this point I would suggest opening a support ticket. We'll need to turn on some more detailed logging and then get a copy of your diagnostics.