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

Re: [firebird-support] Re: wierd gbak behavour

Expand Messages
  • Nick Upson
    ... I tried adding localhost to the string, it had no effect this is being run by cron as root -- Nick Upson (01799 533252) [Non-text portions of this message
    Message 1 of 10 , Sep 1 2:01 AM
    • 0 Attachment
      On 31 August 2011 18:06, Milan Babuskov <milanb@...> wrote:

      > **
      >
      >
      > Nick Upson wrote:
      > > the commandline used is
      > >
      > > gbak -V -CREATE 110831130601.fbk -user sysdba -pass genesis
      > > /opt/unb/archive/tmp/110831130601.fdb
      >
      > User/pass have no effect unless you give "localhost:" in front of
      > connection string. Try:
      >
      >
      > gbak -V -CREATE 110831130601.fbk -user sysdba -pass genesis
      > localhost:/opt/unb/archive/tmp/110831130601.fdb
      >
      > Under which user account are you running gbak?
      >

      I tried adding localhost to the string, it had no effect

      this is being run by cron as root

      --
      Nick Upson (01799 533252)


      [Non-text portions of this message have been removed]
    • Nick Upson
      looking at the logs for other processes, all of the last four occurrances happened at the same time as an isql session was run against the original database. I
      Message 2 of 10 , Sep 1 3:33 AM
      • 0 Attachment
        looking at the logs for other processes, all of the last four occurrances
        happened at the same time as an isql session was run against the original
        database.
        I can't think why there is any need for this isql session and the gbak
        session creating the new database to interact via the lock manager but the
        timing is exact to the second for all four.

        I shall look further back to see if this holds true for earlier sessions.

        --
        Nick Upson (01799 533252)


        [Non-text portions of this message have been removed]
      • Nick Upson
        the isql timing colission seems to hold up, I ve adjusted some timers so that both the gbak and the isql session run much more frequently and the error is now
        Message 3 of 10 , Sep 1 5:07 AM
        • 0 Attachment
          the isql timing colission seems to hold up, I've adjusted some timers so
          that both the gbak and the isql session run much more frequently and the
          error is now happening more often as well, the timing still matches.

          changing the string to include localhost (my earlier test was invalid) gets
          a variation on the same error

          gbak -V -CREATE 110901130102.fbk -user sysdba -pass genesis
          localhost:/opt/unb/archive/tmp/110901130102.fdb
          gbak:opened file 110901130102.fbk
          Fatal lock manager error: invalid lock id (223072), errno: 11
          --Resource temporarily unavailable


          On 31 August 2011 18:06, Milan Babuskov <milanb@...> wrote:

          > **
          >
          >
          > Nick Upson wrote:
          > > the commandline used is
          > >
          > > gbak -V -CREATE 110831130601.fbk -user sysdba -pass genesis
          > > /opt/unb/archive/tmp/110831130601.fdb
          >
          > User/pass have no effect unless you give "localhost:" in front of
          > connection string. Try:
          >
          >
          > gbak -V -CREATE 110831130601.fbk -user sysdba -pass genesis
          > localhost:/opt/unb/archive/tmp/110831130601.fdb
          >
          > Under which user account are you running gbak?
          >
          > --
          > Milan Babuskov
          >
          > ==================================
          > The easiest way to import XML, CSV
          > and textual files into Firebird:
          > http://www.guacosoft.com/xmlwizard
          > ==================================
          >
          >
          >



          --
          Nick Upson (01799 533252)


          [Non-text portions of this message have been removed]
        • Milan Babuskov
          ... My guess is that isql also uses a connection string without localhost: . Take a look at process list (ps command) and you will probably see two lock
          Message 4 of 10 , Sep 1 6:19 AM
          • 0 Attachment
            Nick Upson wrote:
            > looking at the logs for other processes, all of the last four occurrances
            > happened at the same time as an isql session was run against the original
            > database.
            > I can't think why there is any need for this isql session and the gbak
            > session creating the new database to interact via the lock manager but the
            > timing is exact to the second for all four.
            >
            > I shall look further back to see if this holds true for earlier sessions.

            My guess is that isql also uses a connection string without
            "localhost:". Take a look at process list (ps command) and you will
            probably see two lock managers running under different Linux user accounts.

            Try adding "localhost:" to ISQL as well and it should work fine.

            HTH

            --
            Milan Babuskov

            ==================================
            The easiest way to import XML, CSV
            and textual files into Firebird:
            http://www.guacosoft.com/xmlwizard
            ==================================
          • Nick Upson
            ... isql connection string already uses localhost, process list only shows one copy of lock manager and remember, the gbak is creating one database while the
            Message 5 of 10 , Sep 1 6:23 AM
            • 0 Attachment
              On 1 September 2011 14:19, Milan Babuskov <milanb@...> wrote:

              > **
              >
              >
              > Nick Upson wrote:
              > > looking at the logs for other processes, all of the last four occurrances
              > > happened at the same time as an isql session was run against the original
              > > database.
              > > I can't think why there is any need for this isql session and the gbak
              > > session creating the new database to interact via the lock manager but
              > the
              > > timing is exact to the second for all four.
              > >
              > > I shall look further back to see if this holds true for earlier sessions.
              >
              > My guess is that isql also uses a connection string without
              > "localhost:". Take a look at process list (ps command) and you will
              > probably see two lock managers running under different Linux user accounts.
              >
              > Try adding "localhost:" to ISQL as well and it should work fine.
              >
              > HTH
              >

              isql connection string already uses localhost, process list only shows one
              copy of lock manager

              and remember, the gbak is creating one database while the isql session is
              causing an update in another

              --
              Nick Upson (01799 533252)


              [Non-text portions of this message have been removed]
            • Nick Upson
              uninstall and then install seems to have fixed this -- Nick Upson (01799 533252) [Non-text portions of this message have been removed]
              Message 6 of 10 , Sep 6 2:46 AM
              • 0 Attachment
                uninstall and then install seems to have fixed this


                --
                Nick Upson (01799 533252)


                [Non-text portions of this message have been removed]
              Your message has been successfully submitted and would be delivered to recipients shortly.