cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Ndtrack takes 100% CPU

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

(9) Replies
ChrisG
By Community Manager Community Manager
Community Manager

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.

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)

Thanks Chris. 

 

Let me try & update back.

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.

 

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.

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)

Hi Chris,

 

I have restarted ndtask service and run it again. process got completed very quick. enclosing tracker log for reference.

ChrisG
By Community Manager Community Manager
Community Manager

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)

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)

Thanks Chris for taking this at next level to resolve. Appreciate your support as always.

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 

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.

(Did my reply solve the question? Click "ACCEPT AS SOLUTION" to help others find answers faster. Liked something? Click "KUDO". Anything expressed here is my own view and not necessarily that of my employer, Flexera.)