I have a proposal to make things a bit more robust: 0/ Change crash report producers to create new files rather than overwriting the content of existing ones.
1/ When starting the GUI process, we open the crash file and take out a lock on it. If the lock is already held, we simply skip the file. 2/ When requiring more information (assuming it's done via spawning a new process, which I believe is the case) we pass in the FD as input (rather than relying on the filename as it might have been overwritten by another crash), and a hidden temporary file as output FD. 3a/ If the user wants to upload, we link the output FD to the .upload filename (so that we're sure that's actually what they wanted to be uploaded, again in case of overwrite by subsequent crash) 3b/ If they want to abort, we link the output FD (or, if that one is missing, the original crash FD) to the .seen filename. 4/ We unlink the crash FD from the .crash filename. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apport in Ubuntu. https://bugs.launchpad.net/bugs/2087535 Title: Apport GUI triggering is very fragile Status in Apport: Triaged Status in apport package in Ubuntu: Triaged Status in update-notifier package in Ubuntu: Triaged Bug description: The mechanism used by apport/update-notifier to prompt the user when a crash occurs is both buggy and fragile. It's buggy because it suffers from a pretty big TOCTOU race, with a sizeable gap between the "check if seen" and "mark as seen" steps where apport collects some data about the crash. It's fragile because it relies on specific values for the mtime and atime filesystem attributes, and the latter is not that reliable: it depends on the FS atime granularity as well as mount options (noatime remaining a fairly popular one, and the default being relatime). Furthermore, anytime there is FS activity in the crash directory the script will check *all* crashes rather than whichever files triggered the systemd unit in the first place, exacerbating the issues. Sadly, I don't think that one is solvable. I believe this might be the actual culprit for bug 2066995 which we actually saw live at Ubuntu Summit on a demo Framework laptop :) To manage notifications about this bug go to: https://bugs.launchpad.net/apport/+bug/2087535/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
