Loading ...
Sorry, an error occurred while loading the content.

Re: [Control-X] Re: AFT Filewatch not working on Linux

Expand Messages
  • Nagarajan Madhavan pillai. sankarammal
    Joe,   Also please check if the Control-M User id used by aft accout has the appropriate privileages ..   Have you checked the account validation part and
    Message 1 of 13 , Aug 1, 2013
    View Source
    • 0 Attachment
      Joe,
       
      Also please check if the Control-M User id used by aft accout has the appropriate privileages ..
       
      Have you checked the account validation part and also user access rights and the path.. Can you state whats' the error you are facing...
       
       


       
      From: John C. Clancy <corkmeister1@...>
      To: "Control-X@yahoogroups.com" <Control-X@yahoogroups.com>
      Sent: Wednesday, July 31, 2013 4:08 PM
      Subject: Re: [Control-X] Re: AFT Filewatch not working on Linux
       
      Joe,
       
      If you are using SFTP did you generate a new encryption key for the new operating system or did you migrate the key from the old operating system ?? 

      John
      From: adam.lovick <ral@...>
      To: Control-X@yahoogroups.com
      Sent: Wednesday, July 31, 2013 5:02 PM
      Subject: [Control-X] Re: AFT Filewatch not working on Linux
       
      Joe, I haven't come across the AFT Filewatch specifically not working but I did bump into Red Hat's 64-bit libstdc++.so.6 (as I remember) as an issue. The AFT module wanted the 32-bit libstdc++.so.5 and that was incompatible. We implemented it onto AIX in the end and didn't have time to pursue it fully. Yours wouldn't be anything like that, I suppose? Adam --- In mailto:Control-X%40yahoogroups.com, Joe Palozzolo <joepalo2@...> wrote: > > One of our clients migrated from Sun Solaris to Linux over the weekend. We cloned the AFT accounts which were used for the AFT transfers prior to the move and successfully validated the AFT accounts against the new server prior to the migration. > > The files which should be looked for are present on the new server and in a steady state. When the Control-M AFT jobs run on the new server the files are not found if AFT filewatch is used. We have checked the job definitions, checked the permissions on the new server and cannot find an answer. > > We opened a ticket with BMC on this issue. > > Has anyone ever seen an issue with Control-M AFT Filewatch not working on Linux. > > Agent version is Control-M 7.0.400 > > Joe Palozzolo > Hewlett Packard > Control-M Tools Team >
    • Ashok Vaidya
      Save the account.XML as account.XML.org Add a test account with same credentials test FTP fw using new test account Compare both account XML files to locate
      Message 2 of 13 , Aug 1, 2013
      View Source
      • 0 Attachment

        Save the account.XML as account.XML.org
        Add a test account with same credentials
        test FTP fw using new test account
        Compare both account XML files to locate your problem..

        Compare the XML of both job details to locate problem areas.

        On Aug 1, 2013 4:24 AM, "Nagarajan Madhavan pillai. sankarammal" <msnagarajan01@...> wrote:
         

        Joe,
         
        Also please check if the Control-M User id used by aft accout has the appropriate privileages ..
         
        Have you checked the account validation part and also user access rights and the path.. Can you state whats' the error you are facing...
         
         


         
        From: John C. Clancy <corkmeister1@...>
        To: "Control-X@yahoogroups.com" <Control-X@yahoogroups.com>
        Sent: Wednesday, July 31, 2013 4:08 PM
        Subject: Re: [Control-X] Re: AFT Filewatch not working on Linux
         
        Joe,
         
        If you are using SFTP did you generate a new encryption key for the new operating system or did you migrate the key from the old operating system ?? 

        John
        From: adam.lovick <ral@...>
        To: Control-X@yahoogroups.com
        Sent: Wednesday, July 31, 2013 5:02 PM
        Subject: [Control-X] Re: AFT Filewatch not working on Linux
         
        Joe,I haven't come across the AFT Filewatch specifically not working but I did bump into Red Hat's 64-bit libstdc++.so.6 (as I remember) as an issue. The AFT module wanted the 32-bit libstdc++.so.5 and that was incompatible. We implemented it onto AIX in the end and didn't have time to pursue it fully. Yours wouldn't be anything like that, I suppose?Adam--- In mailto:Control-X%40yahoogroups.com, Joe Palozzolo <joepalo2@...> wrote:>> One of our clients migrated from Sun Solaris to Linux over the weekend. We cloned the AFT accounts which were used for the AFT transfers prior to the move and successfully validated the AFT accounts against the new server prior to the migration.> > The files which should be looked for are present on the new server and in a steady state. When the Control-M AFT jobs run on the new server the files are not found if AFT filewatch is used. We have checked the job definitions, checked the permissions on the new server and cannot find an answer. > > We opened a ticket with BMC on this issue. > > Has anyone ever seen an issue with Control-M AFT Filewatch not working on Linux. > > Agent version is Control-M 7.0.400> > Joe Palozzolo> Hewlett Packard> Control-M Tools Team>
      • Joe P. or PI Joe
        Thanks to all who have replied. We had already checked for changes in the slashes in the directory path used in the failing jobs. These were set correctly. We
        Message 3 of 13 , Aug 1, 2013
        View Source
        • 0 Attachment
          Thanks to all who have replied.

          We had already checked for changes in the slashes in the directory path used in the failing jobs. These were set correctly.

          We checked the permissions for the files and directory. The permissions needed to be reset for the file and were changed for the directory. This did not fix the issue.

          Prior to the migration, I created a new account and authorized the new server in AFT. I reauthorized the server after the migration and the issues started. According to BMC this should not have been needed.

          We decided to recycle the Control-M agent on the host server where the AFT jobs actually run. This morning we had no issues with AFT file transfer.

          My team is still working with BMC for closure of the issue.

          Thanks

          Joe Palozzolo
          Hewlett Packard
          --- In Control-X@yahoogroups.com, Ashok Vaidya <avaidya10@...> wrote:
          >
          > Save the account.XML as account.XML.org
          > Add a test account with same credentials
          > test FTP fw using new test account
          > Compare both account XML files to locate your problem..
          >
          > Compare the XML of both job details to locate problem areas.
          > On Aug 1, 2013 4:24 AM, "Nagarajan Madhavan pillai. sankarammal" <
          > msnagarajan01@...> wrote:
          >
          > > **
          > >
          > >
          > > Joe,
          > >
          > > Also please check if the Control-M User id used by aft accout has the
          > > appropriate privileages ..
          > >
          > > Have you checked the account validation part and also user access rights
          > > and the path.. Can you state whats' the error you are facing...
          > >
          > >
          > >
          > >
          > >
          > > *From:* John C. Clancy <corkmeister1@...>
          > > *To:* "Control-X@yahoogroups.com" <Control-X@yahoogroups.com>
          > > *Sent:* Wednesday, July 31, 2013 4:08 PM
          > > *Subject:* Re: [Control-X] Re: AFT Filewatch not working on Linux
          > > **
          > >
          > > Joe,
          > >
          > > If you are using SFTP did you generate a new encryption key for the
          > > new operating system or did you migrate the key from the old operating
          > > system ??
          > >
          > > John
          > > *From:* adam.lovick <ral@...>
          > > *To:* Control-X@yahoogroups.com
          > > *Sent:* Wednesday, July 31, 2013 5:02 PM
          > > *Subject:* [Control-X] Re: AFT Filewatch not working on Linux
          > >
          > > Joe,****I haven't come across the AFT Filewatch specifically not working
          > > but I did bump into Red Hat's 64-bit libstdc++.so.6 (as I remember) as an
          > > issue. The AFT module wanted the 32-bit libstdc++.so.5 and that was
          > > incompatible. We implemented it onto AIX in the end and didn't have time to
          > > pursue it fully. Yours wouldn't be anything like that, I suppose?****Adam*
          > > ***--- In mailto:Control-X%40yahoogroups.com <Control-X%40yahoogroups.com>,
          > > Joe Palozzolo <joepalo2@> wrote:**>**> One of our clients migrated
          > > from Sun Solaris to Linux over the weekend. We cloned the AFT accounts
          > > which were used for the AFT transfers prior to the move and successfully
          > > validated the AFT accounts against the new server prior to the migration.*
          > > *> **> The files which should be looked for are present on the new server
          > > and in a steady state. When the Control-M AFT jobs run on the new server
          > > the files are not found if AFT filewatch is used. We have checked the job
          > > definitions, checked the permissions on the new server and cannot find an
          > > answer. **> **> We opened a ticket with BMC on this issue. **> **> Has
          > > anyone ever seen an issue with Control-M AFT Filewatch not working on
          > > Linux. **> **> Agent version is Control-M 7.0.400**> **> Joe Palozzolo**>
          > > Hewlett Packard**> Control-M Tools Team**>****
          > > ****
          > > ****
          > >
          > >
          >
        • prewrap
          Hey Jrdoe, Interesting you should post this. This week I have been troubleshooting an issue with AFT filewatch on Linux. I have never done a filewatch on a
          Message 4 of 13 , Aug 2, 2013
          View Source
          • 0 Attachment
            Hey Jrdoe,

            Interesting you should post this. This week I have been troubleshooting an issue with AFT filewatch on Linux. I have never done a filewatch on a remote server connecting with sftp before. All my filewatches have been on the local server that the AFT instance is installed on.

            I assumed it would work fine. I tried and the sysout says it looking for the file, says it finds it checks for the file being stagnant and then fails saying it can't find the file. I can use AFT to push, pull, rename, and delete with out using filewatch. I did the same as you and messed with permissions.

            I put the agent in debug mode and actually see it disconnect from the server, but the filewatch job continues on like it doesn't know.

            For my issue, I can replicate it using psftp from a windows server or sftp from a Unix. If I do a series of ls commands or cd commands, the connection will drop eventually. I can see the same error occurring in both the AFT debug log and the psftp disconnect. I believe my issue has something to do with the sftp server set up. I forwarded my logs to my Unix admin to check out.

            I didn't know if you were seeing a similar scenario as I described. If so can you post any updates here. If my admin finds anything, I will do the same.
            Paul Reynolds
            L.L. Bean


            --- In Control-X@yahoogroups.com, "Joe P. or PI Joe" <joepalo2@...> wrote:
            >
            > Thanks to all who have replied.
            >
            > We had already checked for changes in the slashes in the directory path used in the failing jobs. These were set correctly.
            >
            > We checked the permissions for the files and directory. The permissions needed to be reset for the file and were changed for the directory. This did not fix the issue.
            >
            > Prior to the migration, I created a new account and authorized the new server in AFT. I reauthorized the server after the migration and the issues started. According to BMC this should not have been needed.
            >
            > We decided to recycle the Control-M agent on the host server where the AFT jobs actually run. This morning we had no issues with AFT file transfer.
            >
            > My team is still working with BMC for closure of the issue.
            >
            > Thanks
            >
            > Joe Palozzolo
            > Hewlett Packard
            > --- In Control-X@yahoogroups.com, Ashok Vaidya <avaidya10@> wrote:
            > >
            > > Save the account.XML as account.XML.org
            > > Add a test account with same credentials
            > > test FTP fw using new test account
            > > Compare both account XML files to locate your problem..
            > >
            > > Compare the XML of both job details to locate problem areas.
            > > On Aug 1, 2013 4:24 AM, "Nagarajan Madhavan pillai. sankarammal" <
            > > msnagarajan01@> wrote:
            > >
            > > > **
            > > >
            > > >
            > > > Joe,
            > > >
            > > > Also please check if the Control-M User id used by aft accout has the
            > > > appropriate privileages ..
            > > >
            > > > Have you checked the account validation part and also user access rights
            > > > and the path.. Can you state whats' the error you are facing...
            > > >
            > > >
            > > >
            > > >
            > > >
            > > > *From:* John C. Clancy <corkmeister1@>
            > > > *To:* "Control-X@yahoogroups.com" <Control-X@yahoogroups.com>
            > > > *Sent:* Wednesday, July 31, 2013 4:08 PM
            > > > *Subject:* Re: [Control-X] Re: AFT Filewatch not working on Linux
            > > > **
            > > >
            > > > Joe,
            > > >
            > > > If you are using SFTP did you generate a new encryption key for the
            > > > new operating system or did you migrate the key from the old operating
            > > > system ??
            > > >
            > > > John
            > > > *From:* adam.lovick <ral@>
            > > > *To:* Control-X@yahoogroups.com
            > > > *Sent:* Wednesday, July 31, 2013 5:02 PM
            > > > *Subject:* [Control-X] Re: AFT Filewatch not working on Linux
            > > >
            > > > Joe,****I haven't come across the AFT Filewatch specifically not working
            > > > but I did bump into Red Hat's 64-bit libstdc++.so.6 (as I remember) as an
            > > > issue. The AFT module wanted the 32-bit libstdc++.so.5 and that was
            > > > incompatible. We implemented it onto AIX in the end and didn't have time to
            > > > pursue it fully. Yours wouldn't be anything like that, I suppose?****Adam*
            > > > ***--- In mailto:Control-X%40yahoogroups.com <Control-X%40yahoogroups.com>,
            > > > Joe Palozzolo <joepalo2@> wrote:**>**> One of our clients migrated
            > > > from Sun Solaris to Linux over the weekend. We cloned the AFT accounts
            > > > which were used for the AFT transfers prior to the move and successfully
            > > > validated the AFT accounts against the new server prior to the migration.*
            > > > *> **> The files which should be looked for are present on the new server
            > > > and in a steady state. When the Control-M AFT jobs run on the new server
            > > > the files are not found if AFT filewatch is used. We have checked the job
            > > > definitions, checked the permissions on the new server and cannot find an
            > > > answer. **> **> We opened a ticket with BMC on this issue. **> **> Has
            > > > anyone ever seen an issue with Control-M AFT Filewatch not working on
            > > > Linux. **> **> Agent version is Control-M 7.0.400**> **> Joe Palozzolo**>
            > > > Hewlett Packard**> Control-M Tools Team**>****
            > > > ****
            > > > ****
            > > >
            > > >
            > >
            >
          • Joe P. or PI Joe
            We had the same issue over the weekend and again this afternoon. It was BMC s recommendation to apply point patch 7.0.00.104 which was done on Sunday and
            Message 5 of 13 , Aug 5, 2013
            View Source
            • 0 Attachment
              We had the same issue over the weekend and again this afternoon. It was BMC's recommendation to apply point patch 7.0.00.104 which was done on Sunday and tested. BMC noted the SSH and Network disconnect errors in the logs we sent.

              We moved the VM Ware image from the current server to a different server to see if the problems continue on the new server location.

              Our network team will be monioring traffic from the AFT host to the AFT target server during the transmissions on Tuesday AM.

              --- In Control-X@yahoogroups.com, "prewrap" <prewrap@...> wrote:
              >
              > Hey Jrdoe,
              >
              > Interesting you should post this. This week I have been troubleshooting an issue with AFT filewatch on Linux. I have never done a filewatch on a remote server connecting with sftp before. All my filewatches have been on the local server that the AFT instance is installed on.
              >
              > I assumed it would work fine. I tried and the sysout says it looking for the file, says it finds it checks for the file being stagnant and then fails saying it can't find the file. I can use AFT to push, pull, rename, and delete with out using filewatch. I did the same as you and messed with permissions.
              >
              > I put the agent in debug mode and actually see it disconnect from the server, but the filewatch job continues on like it doesn't know.
              >
              > For my issue, I can replicate it using psftp from a windows server or sftp from a Unix. If I do a series of ls commands or cd commands, the connection will drop eventually. I can see the same error occurring in both the AFT debug log and the psftp disconnect. I believe my issue has something to do with the sftp server set up. I forwarded my logs to my Unix admin to check out.
              >
              > I didn't know if you were seeing a similar scenario as I described. If so can you post any updates here. If my admin finds anything, I will do the same.
              > Paul Reynolds
              > L.L. Bean
              >
              >
              > --- In Control-X@yahoogroups.com, "Joe P. or PI Joe" <joepalo2@> wrote:
              > >
              > > Thanks to all who have replied.
              > >
              > > We had already checked for changes in the slashes in the directory path used in the failing jobs. These were set correctly.
              > >
              > > We checked the permissions for the files and directory. The permissions needed to be reset for the file and were changed for the directory. This did not fix the issue.
              > >
              > > Prior to the migration, I created a new account and authorized the new server in AFT. I reauthorized the server after the migration and the issues started. According to BMC this should not have been needed.
              > >
              > > We decided to recycle the Control-M agent on the host server where the AFT jobs actually run. This morning we had no issues with AFT file transfer.
              > >
              > > My team is still working with BMC for closure of the issue.
              > >
              > > Thanks
              > >
              > > Joe Palozzolo
              > > Hewlett Packard
              > > --- In Control-X@yahoogroups.com, Ashok Vaidya <avaidya10@> wrote:
              > > >
              > > > Save the account.XML as account.XML.org
              > > > Add a test account with same credentials
              > > > test FTP fw using new test account
              > > > Compare both account XML files to locate your problem..
              > > >
              > > > Compare the XML of both job details to locate problem areas.
              > > > On Aug 1, 2013 4:24 AM, "Nagarajan Madhavan pillai. sankarammal" <
              > > > msnagarajan01@> wrote:
              > > >
              > > > > **
              > > > >
              > > > >
              > > > > Joe,
              > > > >
              > > > > Also please check if the Control-M User id used by aft accout has the
              > > > > appropriate privileages ..
              > > > >
              > > > > Have you checked the account validation part and also user access rights
              > > > > and the path.. Can you state whats' the error you are facing...
              > > > >
              > > > >
              > > > >
              > > > >
              > > > >
              > > > > *From:* John C. Clancy <corkmeister1@>
              > > > > *To:* "Control-X@yahoogroups.com" <Control-X@yahoogroups.com>
              > > > > *Sent:* Wednesday, July 31, 2013 4:08 PM
              > > > > *Subject:* Re: [Control-X] Re: AFT Filewatch not working on Linux
              > > > > **
              > > > >
              > > > > Joe,
              > > > >
              > > > > If you are using SFTP did you generate a new encryption key for the
              > > > > new operating system or did you migrate the key from the old operating
              > > > > system ??
              > > > >
              > > > > John
              > > > > *From:* adam.lovick <ral@>
              > > > > *To:* Control-X@yahoogroups.com
              > > > > *Sent:* Wednesday, July 31, 2013 5:02 PM
              > > > > *Subject:* [Control-X] Re: AFT Filewatch not working on Linux
              > > > >
              > > > > Joe,****I haven't come across the AFT Filewatch specifically not working
              > > > > but I did bump into Red Hat's 64-bit libstdc++.so.6 (as I remember) as an
              > > > > issue. The AFT module wanted the 32-bit libstdc++.so.5 and that was
              > > > > incompatible. We implemented it onto AIX in the end and didn't have time to
              > > > > pursue it fully. Yours wouldn't be anything like that, I suppose?****Adam*
              > > > > ***--- In mailto:Control-X%40yahoogroups.com <Control-X%40yahoogroups.com>,
              > > > > Joe Palozzolo <joepalo2@> wrote:**>**> One of our clients migrated
              > > > > from Sun Solaris to Linux over the weekend. We cloned the AFT accounts
              > > > > which were used for the AFT transfers prior to the move and successfully
              > > > > validated the AFT accounts against the new server prior to the migration.*
              > > > > *> **> The files which should be looked for are present on the new server
              > > > > and in a steady state. When the Control-M AFT jobs run on the new server
              > > > > the files are not found if AFT filewatch is used. We have checked the job
              > > > > definitions, checked the permissions on the new server and cannot find an
              > > > > answer. **> **> We opened a ticket with BMC on this issue. **> **> Has
              > > > > anyone ever seen an issue with Control-M AFT Filewatch not working on
              > > > > Linux. **> **> Agent version is Control-M 7.0.400**> **> Joe Palozzolo**>
              > > > > Hewlett Packard**> Control-M Tools Team**>****
              > > > > ****
              > > > > ****
              > > > >
              > > > >
              > > >
              > >
              >
            • prewrap
              Any update on this? I still haven t had any luck getting it to work. Thinking Either firewall, VMware network. Can you suggest anything? ... We had the same
              Message 6 of 13 , Nov 17, 2013
              View Source
              • 0 Attachment

                Any update on this?  I still haven't had any luck getting it to work. Thinking Either firewall, VMware network. Can you suggest anything?



                ---In control-x@yahoogroups.com, <joepalo2@...> wrote:

                We had the same issue over the weekend and again this afternoon. It was BMC's recommendation to apply point patch 7.0.00.104 which was done on Sunday and tested. BMC noted the SSH and Network disconnect errors in the logs we sent.

                We moved the VM Ware image from the current server to a different server to see if the problems continue on the new server location.

                Our network team will be monioring traffic from the AFT host to the AFT target server during the transmissions on Tuesday AM.

                --- In Control-X@yahoogroups.com, "prewrap" <prewrap@...> wrote:
                >
                > Hey Jrdoe,
                >
                > Interesting you should post this. This week I have been troubleshooting an issue with AFT filewatch on Linux. I have never done a filewatch on a remote server connecting with sftp before. All my filewatches have been on the local server that the AFT instance is installed on.
                >
                > I assumed it would work fine. I tried and the sysout says it looking for the file, says it finds it checks for the file being stagnant and then fails saying it can't find the file. I can use AFT to push, pull, rename, and delete with out using filewatch. I did the same as you and messed with permissions.
                >
                > I put the agent in debug mode and actually see it disconnect from the server, but the filewatch job continues on like it doesn't know.
                >
                > For my issue, I can replicate it using psftp from a windows server or sftp from a Unix. If I do a series of ls commands or cd commands, the connection will drop eventually. I can see the same error occurring in both the AFT debug log and the psftp disconnect. I believe my issue has something to do with the sftp server set up. I forwarded my logs to my Unix admin to check out.
                >
                > I didn't know if you were seeing a similar scenario as I described. If so can you post any updates here. If my admin finds anything, I will do the same.
                > Paul Reynolds
                > L.L. Bean
                >
                >
                > --- In Control-X@yahoogroups.com, "Joe P. or PI Joe" <joepalo2@> wrote:
                > >
                > > Thanks to all who have replied.
                > >
                > > We had already checked for changes in the slashes in the directory path used in the failing jobs. These were set correctly.
                > >
                > > We checked the permissions for the files and directory. The permissions needed to be reset for the file and were changed for the directory. This did not fix the issue.
                > >
                > > Prior to the migration, I created a new account and authorized the new server in AFT. I reauthorized the server after the migration and the issues started. According to BMC this should not have been needed.
                > >
                > > We decided to recycle the Control-M agent on the host server where the AFT jobs actually run. This morning we had no issues with AFT file transfer.
                > >
                > > My team is still working with BMC for closure of the issue.
                > >
                > > Thanks
                > >
                > > Joe Palozzolo
                > > Hewlett Packard
                > > --- In Control-X@yahoogroups.com, Ashok Vaidya <avaidya10@> wrote:
                > > >
                > > > Save the account.XML as account.XML.org
                > > > Add a test account with same credentials
                > > > test FTP fw using new test account
                > > > Compare both account XML files to locate your problem..
                > > >
                > > > Compare the XML of both job details to locate problem areas.
                > > > On Aug 1, 2013 4:24 AM, "Nagarajan Madhavan pillai. sankarammal" <
                > > > msnagarajan01@> wrote:
                > > >
                > > > > **
                > > > >
                > > > >
                > > > > Joe,
                > > > >
                > > > > Also please check if the Control-M User id used by aft accout has the
                > > > > appropriate privileages ..
                > > > >
                > > > > Have you checked the account validation part and also user access rights
                > > > > and the path.. Can you state whats' the error you are facing...
                > > > >
                > > > >
                > > > >
                > > > >
                > > > >
                > > > > *From:* John C. Clancy <corkmeister1@>
                > > > > *To:* "Control-X@yahoogroups.com" <Control-X@yahoogroups.com>
                > > > > *Sent:* Wednesday, July 31, 2013 4:08 PM
                > > > > *Subject:* Re: [Control-X] Re: AFT Filewatch not working on Linux
                > > > > **
                > > > >
                > > > > Joe,
                > > > >
                > > > > If you are using SFTP did you generate a new encryption key for the
                > > > > new operating system or did you migrate the key from the old operating
                > > > > system ??
                > > > >
                > > > > John
                > > > > *From:* adam.lovick <ral@>
                > > > > *To:* Control-X@yahoogroups.com
                > > > > *Sent:* Wednesday, July 31, 2013 5:02 PM
                > > > > *Subject:* [Control-X] Re: AFT Filewatch not working on Linux
                > > > >
                > > > > Joe,****I haven't come across the AFT Filewatch specifically not working
                > > > > but I did bump into Red Hat's 64-bit libstdc++.so.6 (as I remember) as an
                > > > > issue. The AFT module wanted the 32-bit libstdc++.so.5 and that was
                > > > > incompatible. We implemented it onto AIX in the end and didn't have time to
                > > > > pursue it fully. Yours wouldn't be anything like that, I suppose?****Adam*
                > > > > ***--- In mailto:Control-X%40yahoogroups.com <Control-X%40yahoogroups.com>,
                > > > > Joe Palozzolo <joepalo2@> wrote:**>**> One of our clients migrated
                > > > > from Sun Solaris to Linux over the weekend. We cloned the AFT accounts
                > > > > which were used for the AFT transfers prior to the move and successfully
                > > > > validated the AFT accounts against the new server prior to the migration.*
                > > > > *> **> The files which should be looked for are present on the new server
                > > > > and in a steady state. When the Control-M AFT jobs run on the new server
                > > > > the files are not found if AFT filewatch is used. We have checked the job
                > > > > definitions, checked the permissions on the new server and cannot find an
                > > > > answer. **> **> We opened a ticket with BMC on this issue. **> **> Has
                > > > > anyone ever seen an issue with Control-M AFT Filewatch not working on
                > > > > Linux. **> **> Agent version is Control-M 7.0.400**> **> Joe Palozzolo**>
                > > > > Hewlett Packard**> Control-M Tools Team**>****
                > > > > ****
                > > > > ****
                > > > >
                > > > >
                > > >
                > >
                >
              • Daniel Companeetz
                Hi Paul, can you post some logs? do you see any sftp drops that we can see? filewatcher jobs are different than AFT based filewatchers. The jobs use the ctmfw
                Message 7 of 13 , Nov 17, 2013
                View Source
                • 0 Attachment
                  Hi Paul,

                  can you post some logs? do you see any sftp drops that we can see?

                  filewatcher jobs are different than AFT based filewatchers.

                  The jobs use the ctmfw program, and the aft file watcher connects to the server to look for the file.

                  if you have many connections, the problem could be of resources, where the sshd server cannot allow those many connections. For the most part, that was the issue we have seen.

                  let us know what are you seeing. Maybe we can help!

                  Daniel.



                  From: "prewrap@..." <prewrap@...>
                  To: Control-X@yahoogroups.com
                  Sent: Sunday, November 17, 2013 2:07 PM
                  Subject: [Control-X] RE: AFT Filewatch not working on Linux

                   
                  Any update on this?  I still haven't had any luck getting it to work. Thinking Either firewall, VMware network. Can you suggest anything?


                  ---In control-x@yahoogroups.com, <joepalo2@...> wrote:

                  We had the same issue over the weekend and again this afternoon. It was BMC's recommendation to apply point patch 7.0.00.104 which was done on Sunday and tested. BMC noted the SSH and Network disconnect errors in the logs we sent.

                  We moved the VM Ware image from the current server to a different server to see if the problems continue on the new server location.

                  Our network team will be monioring traffic from the AFT host to the AFT target server during the transmissions on Tuesday AM.

                  --- In Control-X@yahoogroups.com, "prewrap" <prewrap@...> wrote:
                  >
                  > Hey Jrdoe,
                  >
                  > Interesting you should post this. This week I have been troubleshooting an issue with AFT filewatch on Linux. I have never done a filewatch on a remote server connecting with sftp before. All my filewatches have been on the local server that the AFT instance is installed on.
                  >
                  > I assumed it would work fine. I tried and the sysout says it looking for the file, says it finds it checks for the file being stagnant and then fails saying it can't find the file. I can use AFT to push, pull, rename, and delete with out using filewatch. I did the same as you and messed with permissions.
                  >
                  > I put the agent in debug mode and actually see it disconnect from the server, but the filewatch job continues on like it doesn't know.
                  >
                  > For my issue, I can replicate it using psftp from a windows server or sftp from a Unix. If I do a series of ls commands or cd commands, the connection will drop eventually. I can see the same error occurring in both the AFT debug log and the psftp disconnect. I believe my issue has something to do with the sftp server set up. I forwarded my logs to my Unix admin to check out.
                  >
                  > I didn't know if you were seeing a similar scenario as I described. If so can you post any updates here. If my admin finds anything, I will do the same.
                  > Paul Reynolds
                  > L.L. Bean
                  >
                  >
                  > --- In Control-X@yahoogroups.com, "Joe P. or PI Joe" <joepalo2@> wrote:
                  > >
                  > > Thanks to all who have replied.
                  > >
                  > > We had already checked for changes in the slashes in the directory path used in the failing jobs. These were set correctly.
                  > >
                  > > We checked the permissions for the files and directory. The permissions needed to be reset for the file and were changed for the directory. This did not fix the issue.
                  > >
                  > > Prior to the migration, I created a new account and authorized the new server in AFT. I reauthorized the server after the migration and the issues started. According to BMC this should not have been needed.
                  > >
                  > > We decided to recycle the Control-M agent on the host server where the AFT jobs actually run. This morning we had no issues with AFT file transfer.
                  > >
                  > > My team is still working with BMC for closure of the issue.
                  > >
                  > > Thanks
                  > >
                  > > Joe Palozzolo
                  > > Hewlett Packard
                  > > --- In Control-X@yahoogroups.com, Ashok Vaidya <avaidya10@> wrote:
                  > > >
                  > > > Save the account.XML as account.XML.org
                  > > > Add a test account with same credentials
                  > > > test FTP fw using new test account
                  > > > Compare both account XML files to locate your problem..
                  > > >
                  > > > Compare the XML of both job details to locate problem areas.
                  > > > On Aug 1, 2013 4:24 AM, "Nagarajan Madhavan pillai. sankarammal" <
                  > > > msnagarajan01@> wrote:
                  > > >
                  > > > > **
                  > > > >
                  > > > >
                  > > > > Joe,
                  > > > >
                  > > > > Also please check if the Control-M User id used by aft accout has the
                  > > > > appropriate privileages ..
                  > > > >
                  > > > > Have you checked the account validation part and also user access rights
                  > > > > and the path.. Can you state whats' the error you are facing...
                  > > > >
                  > > > >
                  > > > >
                  > > > >
                  > > > >
                  > > > > *From:* John C. Clancy <corkmeister1@>
                  > > > > *To:* "Control-X@yahoogroups.com" <Control-X@yahoogroups.com>
                  > > > > *Sent:* Wednesday, July 31, 2013 4:08 PM
                  > > > > *Subject:* Re: [Control-X] Re: AFT Filewatch not working on Linux
                  > > > > **
                  > > > >
                  > > > > Joe,
                  > > > >
                  > > > > If you are using SFTP did you generate a new encryption key for the
                  > > > > new operating system or did you migrate the key from the old operating
                  > > > > system ??
                  > > > >
                  > > > > John
                  > > > > *From:* adam.lovick <ral@>
                  > > > > *To:* Control-X@yahoogroups.com
                  > > > > *Sent:* Wednesday, July 31, 2013 5:02 PM
                  > > > > *Subject:* [Control-X] Re: AFT Filewatch not working on Linux
                  > > > >
                  > > > > Joe,****I haven't come across the AFT Filewatch specifically not working
                  > > > > but I did bump into Red Hat's 64-bit libstdc++.so.6 (as I remember) as an
                  > > > > issue. The AFT module wanted the 32-bit libstdc++.so.5 and that was
                  > > > > incompatible. We implemented it onto AIX in the end and didn't have time to
                  > > > > pursue it fully. Yours wouldn't be anything like that, I suppose?****Adam*
                  > > > > ***--- In mailto:Control-X%40yahoogroups.com <Control-X%40yahoogroups.com>,
                  > > > > Joe Palozzolo <joepalo2@> wrote:**>**> One of our clients migrated
                  > > > > from Sun Solaris to Linux over the weekend. We cloned the AFT accounts
                  > > > > which were used for the AFT transfers prior to the move and successfully
                  > > > > validated the AFT accounts against the new server prior to the migration.*
                  > > > > *> **> The files which should be looked for are present on the new server
                  > > > > and in a steady state. When the Control-M AFT jobs run on the new server
                  > > > > the files are not found if AFT filewatch is used. We have checked the job
                  > > > > definitions, checked the permissions on the new server and cannot find an
                  > > > > answer. **> **> We opened a ticket with BMC on this issue. **> **> Has
                  > > > > anyone ever seen an issue with Control-M AFT Filewatch not working on
                  > > > > Linux. **> **> Agent version is Control-M 7.0.400**> **> Joe Palozzolo**>
                  > > > > Hewlett Packard**> Control-M Tools Team**>****
                  > > > > ****
                  > > > > ****
                  > > > >
                  > > > >
                  > > >
                  > >
                  >


                Your message has been successfully submitted and would be delivered to recipients shortly.