TC Server failure using -agentpath:...

Can you check the agent log?

<dthome>/log/<agentname>.log

Chris, Yes I checked the files in that directory, there are two.  They ls -l as:

-rw-r--r-- 1 dynsup01 dyntrace  894 Jul 11 14:53 dt_LinuxMonitoring_bootstrap_6297.log
-rw-r--r-- 1 dynsup01 dyntrace 2816 Jul 14 04:57 dt_LinuxMonitoring_6297.log

Neither file contains an error.  Notice the dates.  Monday, 7/14 was the first time we ran the agent for the server.  I've been trying to run all week.  The latest time was within the hour and I changed the name from LinuxMonitoring to SDSMonitoring.  I wanted to see if a new file was created here.  I didn't installed DynaTrace.  I assume the original installer named the server agent LinuxMonitoring.

If you have changed the name of the agent from LinuxMonitoring to "AppMonitoring" then a new file will be created.

Do you have an environment variable for <dthome>? If you don't you can simply put the correct path here instead of the environment variable.

Also, the <server_name>:<port> is the dynaTrace collector you are attempting to connect to so that needs to be changed also.

This of course is all assuming that you didn't change the agentpath when submitting onto the forums for security reasons. Since, no new file was created than this agent path wasn't called or wasn't called correctly.

I use the full path to agent/lib/libdtagent.so without the dt_home env variable.  As to the server_nameort, it refers to the dynaTrace collector.  Two other in house applications use the EXACT SAME -agentpath option.  Theirs works; therefore the path, server and port are all correct.  I've verified more than once.

Chris,

Thanks for taking a look.  If I figure this puzzle out, I'll post the cause and the solution.

Sam

Good News Chris,

I was referencing the 32 bit DynaTrace lib on a 64 bit server.  Change the path to lib64 and it works like a champ.  Thanks for your help.

Sam