On Wed, Jun 8, 2022 at 2:01 PM Gal Rosen <gal.rosen@xxxxxxxxxxxxxx> wrote: > > Hi Amir, > > What do you mean by bumping the CAP_SYS_ADMIN limit ? > You mean to increase the max open file for my process that watches the FANOTIFY fd ? Yes > May I instead decrease the read buffer size ? Yes. > My read buffer is 4096 * 6, the fanotify_event_metadata structure size is 24 bytes, so it can hold 1024 file events at one read. > My process Max open files soft limit is 1024, so why do I get this error ? Perhaps you already have several open files (the fanotify ds itself to name one) > Ohh, maybe because after reading the events I put them in a queue and continue for the next read, so if file events still have not been released by my application, then the next read can exceed 1024 files opened. > Yes, that can explain it. There could be many other reasons. do ls -l /proc/<your process pid>/fd/ > Yes ,we use permission events. We watch on FAN_OPEN_PERM | FAN_CLOSE_WRITE. > We also want to support the oldest kernels. > > BTW: What do you mean by "assuming that your process has CAP_SYS_ADMIN" ? The fanotify process must be running as root. > > Regarding the EPERM, how do we continue to investigate it ? Besides adding prints to the kernel I don't know. Basically, there is a file that is being opened by some process that your listener process has no permissions to open, so check with the people responsible to the SELinux policy what that could be. Thanks, Amir.
