Team,
NDtrack is taking 100% CPU. Below are tracker log.
If any one has also faced this. please let me know
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/dems0n16' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/jlewalsk' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/aron' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/thmoll/.snapshot/7to7.2022-02-22_1100' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/ncf02017' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/makrzyzo' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/dems1c67' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/ankikuma' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/psulm' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/ute' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/build' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/psweb' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/li72989' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/krohn' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/dems1gd4' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/dems17e7' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/glavinic' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} File tracking on mount point '/home/durgesin' of type 'nfs' will be excluded
[Mon 11 Apr 2022 09:45:08 AM CEST (G, 0)] {13643} Started package database update for package types 'IA,BEA,OUI,ISMP,IIM,RPM,DPKG,APK' into '/var/opt/managesoft/cache/packagedb.cdb'
[Mon 11 Apr 2022 10:23:40 AM CEST (G, 0)] {13643} Error: A package list count not be found
[Mon 11 Apr 2022 10:23:40 AM CEST (G, 0)] {13643} Package database update failed. Return code -508952471
Apr 11, 2022 03:54 AM
I've found details of one other similar report of high CPU usage, from several years ago. A clear root cause was not identified in that case, but a hypothesis was that the high CPU usage had something to do with processing rpm database information on the computer.
If you're in a position to do some troubleshooting, here are some some thoughts on things to consider.
Try manually running ndtrack with the following command line options to see if the "package database update" step in the logging still runs for a long time and shows high CPU usage. This command line removes "RPM" from the list of package database types that are scanned.
ndtrack -t Machine -o "PackageDatabaseTypes=IA,BEA,OUI,ISMP,IIM,DPKG,APK"
You could also try running the following command to see if it there is anything unusual about its output. This is similar to a command that the ndtrack process executes to gather rpm database information. For example - does this take a long time to run, or generate a massive amount of output?
rpm --query --all --queryformat '%{NAME}%%%{VERSION}%%%{RELEASE}%%%{ARCH}%%%{INSTALLTIME}
[%{FILENAMES}
]%%%%%%%%%%%%%%%%%%%%EOP
' >rpm-query.txt
NB. I assume from your message that the high CPU usage starts at the time the "Started package database update" log message is output, and ends with the "Package database update failed" message. If that assumption is incorrect then the above comments are likely irrelevant to your situation.
Apr 11, 2022 05:05 AM
Thanks Chris.
Let me try & update back.
Apr 11, 2022 05:40 AM
I have run both the commands. Ndtrack is still running from last 5 min & trying to obtain semaphore.
Another one has completed & generated 100 MB file output.
Apr 11, 2022 06:19 AM
Waiting for a semaphore likely indicates that there is already another ndtrack process running on the computer. Wait until the previous process finishes, or kill it, to allow your process to proceed.
Apr 11, 2022 06:29 AM
For reference, here is an article describing the issue that was encountered here: Known Issue: ndtrack may consume high CPU usage for an extended period processing RPM package information after logging line "Started package database update for package types '...' into '/var/opt/managesoft/cache/packagedb.cdb'" (IOK-608835)
May 26, 2022 06:52 PM
Thanks Chris for taking this at next level to resolve. Appreciate your support as always.
May 27, 2022 05:19 AM
Hi @ChrisG, I notice with the bug fix, it is not scheduled to be fixed.
If we experience this issue, and have to apply the work around, in terms of inventory do we lose any inventory data. As I appreciate .rpm is Linux installer packages and ideally we would need to scan these. As I'm not 100% fully familiar with Linux. I just need to understand by using this configuration on the agent, what we would actually be excluding?
Ben
May 27, 2022 05:44 AM
Applying the workaround to exclude "RPM" from the PackageDatabaseTypes agent preference would mean that data about installed RPM is not gathered, so any application installations that would normally be recognized based on that data won't get recognized.
May 27, 2022 05:53 AM