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. Wondering out loud: Currently we order the marks on the mark obj_list, within the same priority group, first-subscribed-last-handled. I never stopped to think if this order made sense or not. Seems like it was just the easier way to implement insert by priority order. But if we order the marks first-subscribed-first-handled within the same priority group, we won't need to restart the syscall to restart mark list iteration. The new group of the newly started daemon, will be next in the mark list after the current stopped group returns FAN_ALLOW. Isn't that a tad less intrusive handover then restarting the syscall and causing a bunch of unrelated subsystems to observe the restart? And I think that the first-subscribed-first-handled order makes a bit more sense logically. I mean, if admin really cares about making some super important security group first, admin could make sure that its a priority service that starts very early admin cannot make sure that the important group starts last... Thanks, Amir.
