10 Replies Latest reply on Sep 17, 2010 7:14 AM by Truffles

    error on ldiscan.sh

    Rookie

      I'm deploying Landesk manually to a few servers prior to automating the deployment but I've got a few problems that have surfaced.  I install Landesk as follows:

       

      ./linuxpull.sh "Default Linux Server Configuration.ini"

      service cba8 start

      /usr/LANDesk/common/ldiscan.sh

      service cba8 restart

      /usr/LANDesk/ldms/ldiscan -ntt=<core_svr_name:5007

       

      The ./linuxpull.sh installs w/o any events but when I run /usr/LANDesk/common/ldiscan.sh and /usr/LANDesk/ldms/ldiscan -ntt=<core_svr_name>:5007 I get the error that reads "kcore: Value too large for defined data type".

       

      I've looked into what kcore represents, I understand it is a virtual file system that should match installed ram.

      /proc/kcore = 2.1G

      free -m shows

      Mem:          2011

       

      The device never shows up in Landesk either.  Has anyone seen this before?

        • 1. Re: error on ldiscan.sh
          Truffles SupportEmployee

          WR,

           

          What linux flavor and version is this? In order for a device to show up in the 32-bit console an inventory scan must be received. Ldiscan.sh is the scanner on Linux machines so the scanner is essentially running into a problem reading the /proc/kcore. I thought that the scanner should get the total memory from another location though but I haven't ever investigated it.

           

           

          Truffles

          • 2. Re: error on ldiscan.sh
            Rookie

            This is Oracle Unbreakable 5.4 64 bit.

            • 3. Re: error on ldiscan.sh
              Rookie

              Have you had an opportunity to investigate?

              • 4. Re: error on ldiscan.sh
                Truffles SupportEmployee

                I should hopefully have an answer soon. Oracle Unbreakable isn't a supported OS but I would like to know at least why it's having problems reading /proc/kcore. I'll help with finding a work around depending on the answer.

                • 5. Re: error on ldiscan.sh
                  Rookie

                  OUL is by all accounts RH w/ different branding.  While I realize it's not 'officially' supported it's behaviour is identical to that of RH.  If that helps any.

                  • 6. Re: error on ldiscan.sh
                    Truffles SupportEmployee

                    I got in touch with one of our developers regarding this issue. He believes the problem is with the scanner as it was designed for a 32-bit OS. He theorizes that it is probably trying to assign an integer value for kcore that is larger than what the 32-bit can store. Red Hat 64-bit is supported so I don't know what the difference would be in OUL. At this time I would recommend trying it again after SP2 is released for 9.0. A lot of work has gone into Linux/Unix devices for this service pack so there is a good (not 100%) chance that it will work. 

                    • 7. Re: error on ldiscan.sh
                      Rookie

                      Yeah, we have several 64bit deployments that are running fine.  When is SP2 due out?

                      • 8. Re: error on ldiscan.sh
                        Truffles SupportEmployee

                        9.0 SP2 should be released around the November time frame. 

                        • 9. Re: error on ldiscan.sh
                          Rookie

                          I had a machine deployed from the offending VM template and ran through our normal procedure for forcing the server to report to the core server using the following commands:

                          /usr/LANDesk/common/ldiscan.sh
                          service cba8 restart
                          /usr/LANDesk/ldms/ldiscan -ntt=core_svr_name:5007

                           

                          This did not produce any changes, typical results.  So I began investigating the files that get placed when Landesk installs and came across the file, ldiscnux.conf.  This file contains a line that reads “Device ID=” followed by a long string of alphanumeric characters.  So prior to uninstall I got the Device ID from this file and ran the uninstall as follows:

                          ./linuxuninstall.sh -f ALL


                          I then returned to the /etc/ dir and found the files had not been removed they in fact had not had their timestamps changed whatsoever. So I moved the ldiscnux.conf to ldiscnux.conf.orig and ran the manual install again.  (During our initial findings I uninstalled and reinstalled the agent on multiple occasions and on multiple servers all to no avail.)

                           

                          After the file was moved and the install was completed I was rewarded with the device showing up in the Landesk console.  So it would seem that the newly created file and/or Device ID  was the key to the agent communicating with the Landesk core.  Being the agent was baked into the VM image I would guess the Device ID’s would have been identical, however this was not the case.  I viewed a few of the VM’s deployed with the agent baked in and they have differing Device ID’s.  So I’m not sure the explanation of differing keys on each VM.

                           

                          Seems like the uninstaller needs a little tweaking?

                           

                           

                          So the agent is reporting to the core server but I'm still getting the kcore error messages but they dont seem to be affecting the inventory/reporting by the agent.

                          • 10. Re: error on ldiscan.sh
                            Truffles SupportEmployee

                            This is very interesting...on a standard agent...linux or not...we typically don't remove the unique system ID when uninstalling the agent. Duplicates are handled by the inventory server and new ones are generated at the client.

                             

                            Have you tested with renaming the file and running an inventory scan again? Technincally the scanner should regenerate the file with a new ID.