On Fri, Mar 13, 2020 at 3:23 PM Richard Guy Briggs <rgb@xxxxxxxxxx> wrote: > On 2020-03-13 12:42, Paul Moore wrote: ... > > The thread has had a lot of starts/stops, so I may be repeating a > > previous suggestion, but one idea would be to still emit a "death > > record" when the final task in the audit container ID does die, but > > block the particular audit container ID from reuse until it the > > SIGNAL2 info has been reported. This gives us the timely ACID death > > notification while still preventing confusion and ambiguity caused by > > potentially reusing the ACID before the SIGNAL2 record has been sent; > > there is a small nit about the ACID being present in the SIGNAL2 > > *after* its death, but I think that can be easily explained and > > understood by admins. > > Thinking quickly about possible technical solutions to this, maybe it > makes sense to have two counters on a contobj so that we know when the > last process in that container exits and can issue the death > certificate, but we still block reuse of it until all further references > to it have been resolved. This will likely also make it possible to > report the full contid chain in SIGNAL2 records. This will eliminate > some of the issues we are discussing with regards to passing a contobj > vs a contid to the audit_log_contid function, but won't eliminate them > all because there are still some contids that won't have an object > associated with them to make it impossible to look them up in the > contobj lists. I'm not sure you need a full second counter, I imagine a simple flag would be okay. I think you just something to indicate that this ACID object is marked as "dead" but it still being held for sanity reasons and should not be reused. -- paul moore www.paul-moore.com
