Custom probe fail

[Anon Anon]

Hi,

 

We have a custom made probe (ErrorReport) that does the functionality of alerting the errpt entries in an AIX box. This probe was running with out any issues in the past and when we recently migrated nimsoft to another server we started facing an issue which persists for any new deployment, however holding good with the existing set up. The probe turns inactive and the log says

 

Controller: Probe 'ErrorReport' FAILED to start (command = /monitor/nimbus/perl/bin/perl) does not exist or is unreachable

 

I tried to deploy the perl executable to a server with issue however it still is the same. Any idea to recover from this?

 

Thanks,

Ananda Guberan K

[Anon Anon]

Hi,

 

Did you verify on the server that the perl was deployed to this path? Haven't installed many agents on AIX boxes, but /monitor seems to be a custom location. Maybe there's an issue with the paths and you need to modify the probe definition in the package?

 

-jon

[Anon Anon]

Hi Jon,

 

Yes, perl is installed on this path but I am just trying to understand how come a probe which worked earlier on new deployment on the old set up but failes in the new set up? Is there anything that needs attention in the nimsoft server?

 

 

Thanks,

Ananda

[Anon Anon]

Well, probe generally needsto be added in the probe administration under security in IM. That shouldn't, however, produce this error, and if the package has been generated correctly, it will be added there automatically on deployment.

 

Also the Perl api was updated recently as the old one didn't work properly with new hubs, but that shouldn't cause this error either.

 

-jon

[Anon Anon]

Hi Jon,

 

I just checked the probe administration and found the probe not listed. I added there and tried but again no good result. If there are any issues with the package it shouldn't have worked as we are trying to deploy the same probe package. All that I did was just copied the package from the old server and pasted here.

 

One question. Is the custome probes dependent on the server. I mean it should have been created with the old server which had distsrv however is now replaced with a new server with a different IP. Does this have any impact on this? Just trying to explore various possibilites.

 

 

Thanks,

Ananda Guberan K

[Anon Anon]

Hi,

 

It's not dependent on the server. If you copied it from the old servers archive and imported it to the new and and deployed from there, it should be alright.

 

Unfortunately I can't think of anything else, except that the paths are wrong, SDK is not actually installed on the target server, and maybe the perl5lib  environment variable missing from the controller.

 

-jon

[Matthias Gruber]

Hmm.... how about start it manually....on the commandline, perhaps the perl has a problem, and the nimsofterror is just a "in case of error,write this" message.

 

[Anon Anon]

Running the script manually is a very good suggestion to troubleshoot this issue. Make sure you run the script by executing the full path from the error message just to make sure you are doing it the same way as the controller:

 

cd <probe-directory>
/monitor/nimbus/perl/bin/perl <script-name>

I was also wondering if the file is actually in the right spot maybe the permissions are wrong. Seems unlikely though. And if you test by running the probe manually, it would confirm the permissions are okay.

[Anon Anon]

Also make sure to set the environment variable first:

 

PERL5LIB=/monitor/nimsoft/perllib; export PERL5LIB

if that's how you do it on AIX

 

 -jon

[Anon Anon]

Hi,

 

Creating an environment varible and executing the script in the path did not yield a positive result. The burning question that pops in mind every now and then is why is this probe not functioning on a new deployment after migrating and holding good with the servers that has the probe installed already.

 

 

Thanks,

Ananda Guberan K

[Anon Anon]

So you are saying that running the probe manually works just fine?

[Anon Anon]

No, I meant that running the probe manually did not yield any positive result.

[Anon Anon]

Can you tell us what happened when you ran the probe manually?

 

"Positive result" is a bit ambiguous in this case.

[Anon Anon]

Hi,

 

I am sorry about that. Upon running the probe manually on the server through command prompt we did not had the probe running and remained in red color. Basically, the probe failed again even after starting the service through command prompt and also by creating an environment variable. Not sure what causes this issue to only a new installation.

 

 

Thanks,

Ananda Guberan K

[Anon Anon]

Thanks, those additional details help. Time for even more...

 

Did you get any error messages or other output on the command line?

 

When you run the command, does it exit immediately or run for a little while first?

 

Do you see any messages in the probe log?

 

Could you copy and paste your command line session? That might not help much, but it might help make sure I am not making bad assumptions about how you are testing.

[Anon Anon]

The command line did not yield any output rather it took some time to execute and returned back to the present working directory which we can assume that the script ran. But I did not check the probe logs. So let me do this again and check and the logfiles to see if there are logs generated and will update it here. Thanks for the help.

 

 

-Ananda Guberan K

 

[Anon Anon]

Depending on how much the probe logs, you may want to delete the log file before you run the probe command. That can make it a big easier to see exactly what happened during the run. It is probably not necessary, but since you will already be in that directory, it would be especially simple to delete the log.

[Anon Anon]

Sorry, come to think of it, if the probe seems to run and does not output anything on the command line, you might learn just as much from the log by trying to activate the probe in Infrastructure Manager. Running from the command line probably does not add any value unless that is the only way anything gets logged. You can check that before going to too much of a hassle.

[Matthias Gruber]

Hi!

 

If have also a link of /opt/nimbus -> /opt/nimsoft (in your case /monitor instead of /opt)

 

Sure that if you do a ls -la /monitor/nimbus/perl/bin/perl it came back with no error?

 

cheers

Matthias

[Anon Anon]

Doesn't the SDK documentation say something that it expects it to be /opt/nimbus? And if you have something else, you need to 

set the PERL5LIB variable on your robot.

[Anon Anon]

Hi Andres,

 

We have the PERL5LIB variable defined on the robot as far as the robot which I tested.

 

 

-Ananda