Hotfix HFBM-0071 addresses two problems in the new keystroke log transport framework introduced in BoKS 7.0.



Problem

I.
The keystroke log server receiving log data from remote keystroke log client applications, uses the select(2) system call in some instances when communicating with the BoKS servc process. The select(2) system call has a hard limit for the largest file descriptor value it can handle.
The remote keystroke logging typically use two file descriptors per session. The select(2) limit thus introduces a limit for the number of simultaneous keystroke log sessions the server can handle.

II.
The new file transport framework used by BoKS 7.0 keystroke logging, uses a file queuing mechanism based on the rename(2) system call and signaling on a FIFO. Although the rename(2) system call is an atomic operation, it turns out that on some file systems the process view of file meta-data might not be in sync between the process signaling and the process being signaled.
The result is that the signaled process might fail when trying to read the file and will go back to waiting for the next signal. This can cause a file to be stuck in the queue for some time if the frequency
of new files entering the queue is low.




Solution

Apply hotfix HFBM-0071, available for download from the HelpSystems Community Portal.

I.
The keystroke log server to BoKS servc communication is modified to uses the poll(2) system call that does not have a hard limit on file descriptor value, thus the number of simultaneous session is limited only by the processing power of the keystroke log server host.

II.
The queuing mechanism is modified so that the process waiting for new files entering a queue, in addition to being alerted by a signal on the FIFO, also makes a periodic timer based wake-up to check the queue.


Still have questions? We can help. Submit a case to Technical Support.

Last Modified On: May 25, 2018