8 Replies Latest reply on Apr 10, 2012 1:29 PM by Jim Wilson

    RSCD Agent Timeouts

    richard mcleod

      I have an environment which is behind a firewall, from time to time I find that a good amount of servers are stating the connection timed out when running an NSH job against them or reporting to an orphaned smart group i set up for non-responsive agents. I have the necessary ports open to the agents from the appservers, is there a timeout value I can set for the agent? (i am aware of the job and job part timeout) but I am curious if there is a seperate timeout for the agent comms between the appserver and rscd. These same servers will sometimes show up in a smart group for agent's not responding, thinking it could be a timeout issue... any ideas? this is non-os specific.

        • 1. Re: RSCD Agent Timeouts
          Bill Robinson

          What is the connection timeout set to on the firewall?


          About how long does it take until these sessions get disconnected ?


          Depending on the firewall setup you may not be able to do anything on the blade config side.

          • 2. RSCD Agent Timeouts
            richard mcleod

            I don't have access to the firewall config. Usually live browse works on these servers, is it just a matter of running an update server properties job with a long part timeout to capture the data correctly?

            • 3. Re: RSCD Agent Timeouts
              Bill Robinson

              If you run the nsh job and you get a timeout, that could mean that the job has run longer than the firewall is allowing the connection to be idle.  Assuming that the nsh job needs that long to run, lowering the job_part_timeout value could result in the job failing because the job_part_timeout cuts the job off too early.


              If the USP is taking a long time to run per target than increasing the timeout may not help either because the firewall could also cut it off before it’s finished.  The USP should only take a couple min to run per server – are you seeing it take significantly longer?


              So how long do the nsh jobs typically run for before you get a timeout issue ?

              • 4. RSCD Agent Timeouts
                richard mcleod

                I'm not seeing the jobs run unusually long at all, the last job ran against ~50 servers and completed in 40 seconds. I will query the firewall team about timeouts but since live browse is working (slowly) i figured it was something that could be modified in BL.

                • 5. Re: RSCD Agent Timeouts
                  Bill Robinson

                  Do you have job logs showing the timeout ?

                  • 6. RSCD Agent Timeouts
                    richard mcleod

                    I can't locate a current log with this issue. I will have to provide next time it comes up, was just wondering if there was a setting for agent timeouts. Will continue to monitor, thanks for the clarification

                    • 7. Re: RSCD Agent Timeouts
                      Bill Robinson

                      Look in the admin pdf – I think there’s a couple settings in the secure file you can use but I think you might still have issues w/ the firewall…

                      1 of 1 people found this helpful
                      • 8. RSCD Agent Timeouts
                        Jim Wilson

                        lobsters wrote:


                        was just wondering if there was a setting for agent timeouts.

                        There is, but I have no idea if it is relefvant  to this issue - just throwing it out here:


                        This is the infoirmation for the setting (in the secure file)




                        Sets the maximum number of seconds that a client waits when first contacting a remote server before giving up. The default value is 30 seconds.


                        Without this option, the TCP protocol might continue to contact an offline or unavailable server for several minutes before finally giving up and reporting that a server is unavailable.


                        This timeout mechanism is implemented within the BMC Server Automation code and does not in any way alter any system wide TCP parameters. If the operating system has an effective TCP timeout less than the value defined here, the OS value takes precedence.

                        1 of 1 people found this helpful