Hi,
In our environment, we have FNMS agent deployed on servers with file inventory scanning enabled.
Recently we spotted that some of the files were locked while scanning was running.
Agent was executing scanning of E drive at the time when files were locked. FNMS agent log: “[- (G, 0)] {12164} Scanning directory 'E:\' for files”.
Just wanted to clarify if this is expected behavior of FNMS agent? Also, if there are any recommendations how to avoid it or to reduce possible impact. On that specific server file scanning sometimes is taking more than 24 hours, so it an operational risk to have such locks on server file system and at the end configuration of running applications.
Thanks.
Jan 04, 2022 12:17 AM
I wouldn't normally expect ndtrack.exe processes to lock files for any longer than an instantaneous moment that it takes to open a .exe file and read a few bytes from the file header.
The agent does have a preference named GenerateMD5 which could result in the inventory gathering process reading the full content of files, which could slow things down and result in files being held open for a little longer (especially if the files are are very large). However it would be highly unusual to have this preference configured.
Another thing to look out for may be antivirus software causing some file locking behavior. I don't recall ever seeing this sort of thing happening, but I wonder if it is possible that antivirus software might open and lock a file when the inventory gathering process attempts to gather details about the file.
Jan 05, 2022 01:39 AM
It is a bit hard to run any further investigation at file level. But in our case it was obvious that we had impact on folder level. System administrators were not able to make changes (move / rename / delete) to folder until ndtrack.exe process was killed.
Maybe it is not so evident when scanning is taking few minutes, but for bigger folders where it takes hours to complete it brings some operational risks.
Jan 05, 2022 02:54 AM
Ahh yes - having handles on directories open for the duration of the scan of those directories would make sense: a handle will be needed on the directory in order to scan details of files in it.
As to why the scan is taking so long, that sounds unusual. The agent will basically be doing a recursive directory listing of the drive, and getting a few selected details from .exe files - this would not normally take that long. Some questions to consider may be:
Jan 06, 2022 12:24 AM
On this particular server, size of the disk where we spotted locking situation is 2.5TB. Folder, which was locked, has size of 360GB, with 1,5M files and 2.7M subfolders. I understand that this is quite heavy folder, and it is probably not so common across our environment. Probably this is one of the reason why we faced such complain for the first time while running scanning for 6 years.
One more question, we have enabled log4j scanning recently. Do you expect any impact with recommended configuration? We run with default setup, where we have “Collect file evidence for all folders” enabled with some folders excluded from scanning.
Jan 06, 2022 07:44 AM
I am guessing that you've taken an approach similar to what is discussed in the following article for log4j scanning: Finding installations of Apache Log4j (or other) files on computers with FlexNet Manager Suite
I don't expect that approach would materially change the time that the agent takes to scan the filesystem for files of interest: the configuration described there will change what data the agent includes in the generated inventory, but doesn't make the filesystem scanning do anything it wouldn't already be doing.
Jan 06, 2022 06:09 PM