7 Replies Latest reply on Aug 6, 2013 9:19 AM by R V

    Inventory Script error in v8.3.01

    R V

      Hi folks,

       

      I want to share some "insight". Maybe it's worth including this in the knowledge-base as a document for future reference.

       

      Here we go.

       

      After upgrading BDSSA to v8.3.01 I ran the Inventory Template import script on our application server for upgrading the Linux templates. This went well and I exited the installer-script.

       

      After that I wanted to restart the import-script (i.e. load-bl-inventory-templates.nsh) to finish work for the non-Linux-OS-Templates but I got the following message:

       

      blasadmin now running against deployment: _template

      [FileServer]

      [06 Jun 2013 19:06:03,926] [main] [ERROR] Unable to read data: No DB information available.

      ERROR: Could not find fileserver location:  //

      Please check if blasadmin show FileServer all works on the command-line.

      Fix this issue and re-run inventory template installer.

      Trying to find out what happend i wanted to run "blasadmin show fileserver all" - I got the following message:

       

      blasadmin now running against deployment: default

      [FileServer]

      [06 Jun 2013 19:07:41,886] [main] [ERROR] Unable to read data: No DB information available.

      A similar output I got from  "blasadmin show database all":

       

      blasadmin now running against deployment: default
      [Database]
      [06 Jun 2013 19:08:04,657] [main] [ERROR] java.sql.SQLRecoverableException: IO Error: Got minus one from a read call

      At first I got not idea what could be the reason for all this.

       

      The day after we got knowlegde of an incident from the Oracle-team. They could not "su - oracle" because of messages like:

       

      blhost:/dev # su - oracle
      /etc/profile[12]: /dev/null: cannot create [Permission denied]
      /etc/profile[41]: /dev/null: cannot create [Permission denied]

      ... and some of these more...

       

      The SysAdmins found that the character special device file /dev/null wasn't there any longer - instead we had a really normal file named "null" in the /dev-directory. And we asked: who or what was responsible for that? The time of the incident and the time of the InventoryTemplate-load-script-run were very close to each other.

       

      And so I did in one terminal:

      # while true; do ls -l /dev/null; sleep 1; done

       

      which showed:

      crw-rw-rw- 1 root root 1, 3 Jun  7 09:45 null

      crw-rw-rw- 1 root root 1, 3 Jun  7 09:45 null

      crw-rw-rw- 1 root root 1, 3 Jun  7 09:45 null

      [over and over again - yeah, really ;-) ]

       

      and in another terminal I ran:

      # load-bl-inventory-templates.nsh

       

      chose "Linux-Templates" (or some similar named entry) to enter the Linux-Templates into th BL-DB

       

      and suddenly when the load-script came to an end we got:

      /bin/ls: null: No such file or directory

      /bin/ls: null: No such file or directory

      -rw-r----- 1 root root 63 Jun  7 09:46 null

      As you can see - just a normal file created presumably by some output redirection to a - at that moment non-existent - file named "null".

       

      We rebuild our device-file - we had to to this in a semicolon-separated way, so no process could create the "normal" null-file again:

       

      # rm /dev/null; mknod /dev/null c 1 3; chmod 666 /dev/null

       

      And all went well again. We ran the load-bl-template-inventory.nsh-script in another environment and for all OS - and the result was always the "normal null file" instead of the character-special-device-null-file.

       

      And here comes the solution (aka root-cause):

      in the Inventory-Templates.zip we have: bsara-reports-scripts/content-loader-pdq.nsh

       

      and content-loader-pdq.nsh contains (hera including line-numbers for clearity):

         3015 OS=`uname -s`
         3016 if [ "$OS" != "WindowsNT" ]
         3017 then
         3018         NULL=/dev/null
         3019 else
         3020         NULL=NUL_file
         3021 fi
      

       

      and at the very last two lines:

       

         3171 # Cleanup
         3172 rm -f "$NULL"
      

       

      You got it? On Windows a normal file is used to catch all output from the various commands inside with "2>$NULL". And of course it's a good idea to delete this - ON WINDOWS.

       

      On Linux it's a very bad idea to delete /dev/null.

       

      A ticket is open - but as this will take some time to come around - I just suggest this article. Of course you could give me a "Like" (if you like it) ;-)

       

      Best regards,

      Reinhard

       

      Nachricht geändert durch Reinhard Vielhaber: just changed formatting of shell-commands and script