7 Replies Latest reply on Dec 23, 2011 12:49 PM by Bill Robinson

    File Deploy job behaviour

    Jim Campbell

      After upgrading, it appears our File Deploy jobs are using old IPs.  E.g. I have a server named Server1 that is no longer accessible and is either not in DNS at all or has another IP but Bladelogic keeps an IP of for it in the server object properties (since it can't update as the agent on the server is not accessible).  Another server named Server2 has been built that now uses the IP  If I run any other type of job (patch analysis e.g.) against 'Server1' it fails saying that it cannot contact the server.  However, if I run a file deploy job against Server1 it appears to use this residual IP from the server object rather than using DNS.  I can check the logs of 'Server2' and see the file deploy job being run.  We just upgraded from 8.0 to 8.1 and this behaviour is new.  Is this something other people are seeing, and if so is there a way to disable this behaviour?


      (It would be nice to not have old servers in the console but I don't have control over that and just have to work around it).

        • 1. File Deploy job behaviour
          Bill Robinson

          the appserver may have these entries cached.  google for 'java dns ttl' and there will be some articles aboud changing the behaviour.  the file you want is in the appserver install dir - on windows i think jre/lib/security/java.security.  it will require a bounce of the appserver (which will also clear the dns cache)

          • 2. File Deploy job behaviour
            Jim Campbell

            I probably do need to set that again as it appears that while I altered it in the old version the setting was not retained when we upgraded from 8.0 to 8.1.  However I don't think this can be the problem - I restarted the application server last night (which would have cleared the cache) and the server causing the problem has not been in use for at least a few months (or at least the server using the IP the old server has in the server properties has been using it for quite some time).

            • 3. Re: File Deploy job behaviour
              Bill Robinson

              Has a USP or verify been run against that server object recently ?

              • 4. File Deploy job behaviour
                Jim Campbell

                Yes.  I just retested this by running an update properties job on a server that does not resolve in DNS and then running a file deploy job against the server.  The file deploy job ran against the IP that was still in the server properties which is now assigned to a server with a different name.


                12/16/11 13:52:00.639 INFO1    rscd -  AppServer_IP_HERE 23184 BladeLogicRSCD@NEW_SERVER_NAME->Admin_ACCOUNT@NEW_SERVER_NAME:PrivilegeMapped (BLROLE:BLUSER): cp: > 01011 Copy file //random_server/C/Temp/Bladelogic/File.txt to //


                Where is the IP in the server object for OLD_SERVER against which I am running the job.  OLD_SERVER does not resolve to an IP in DNS.

                • 5. File Deploy job behaviour
                  Bill Robinson

                  so IP_ADDRESS isn't updated if the server is not resolvable during the USP ?  there's a bug being fixed in 8.1 SP4 that should stop the FDJ from using IP_ADDRESS. so that will help w/ part of this i think.

                  1 of 1 people found this helpful
                  • 6. File Deploy job behaviour
                    Jim Campbell

                    IP_ADDRESS is not being changed.  I have gone back and changed the JVM caching back to what it was prior to upgrading from 8.0sp6 to 8.1sp3 (10 minutes instead of infinite) and its still not changing the IP_ADDRESS property.


                    Does the bug affect any other jobs or just file deploys?

                    • 7. Re: File Deploy job behaviour
                      Bill Robinson

                      I wonder if IP_ADDRESS is not being updated because we can’t resolve the host ?  that would be my guess.  other that decommissioning or excluding unreachable servers from jobs I’m not sure how to prevent this other than decommissioning or waiting for the defect fix.