> On Thu, Jul 3, 2025 at 4:43 PM Jan Kara <jack@xxxxxxx> wrote: > > > > On Thu 03-07-25 10:27:17, Amir Goldstein wrote: > > > On Thu, Jul 3, 2025 at 9:10 AM Ibrahim Jirdeh <ibrahimjirdeh@xxxxxxxx> wrote: > > > > > > > > > On Wed, Jul 2, 2025 at 6:15 PM Jan Kara <jack@xxxxxxx> wrote: > > > > > > Eventually the new service starts and we are in the situation I describe 3 > > > > > > paragraphs above about handling pending events. > > > > > > > > > > > > So if we'd implement resending of pending events after group closure, I > > > > > > don't see how default response (at least in its current form) would be > > > > > > useful for anything. > > > > > > > > > > > > Why I like the proposal of resending pending events: > > > > > > a) No spurious FAN_DENY errors in case of service crash > > > > > > b) No need for new concept (and API) for default response, just a feature > > > > > > flag. > > > > > > c) With additional ioctl to trigger resending pending events without group > > > > > > closure, the newly started service can simply reuse the > > > > > > same notification group (even in case of old service crash) thus > > > > > > inheriting all placed marks (which is something Ibrahim would like to > > > > > > have). > > > > > > > > > > > > > I'm also a fan of the approach of support for resending pending events. As > > > > mentioned exposing this behavior as an ioctl and thereby removing the need to > > > > recreate fanotify group makes the usage a fair bit simpler for our case. > > > > > > > > One basic question I have (mainly for understanding), is if the FAN_RETRY flag is > > > > set in the proposed patch, in the case where there is one existing group being > > > > closed (ie no handover setup), what would be the behavior for pending events? > > > > Is it the same as now, events are allowed, just that they get resent once? > > > > > > Yes, same as now. > > > Instead of replying FAN_ALLOW, syscall is being restarted > > > to check if a new watcher was added since this watcher took the event. > > > > Yes, just it isn't the whole syscall that's restarted but only the > > fsnotify() call. I was trying out the resend patch Jan posted in this thread along with a simple ioctl to trigger the resend flow - it worked well, any remaining concerns with exposing this functionality? If not I could go ahead and pull in Jan's change and post it with additional ioctl.
