> 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? I don't think we would ever run into this with proper usage of the new functionality, just curious.
