Public bug reported:
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 :)
** Affects: apport (Ubuntu)
Importance: Undecided
Status: New
** Affects: update-notifier (Ubuntu)
Importance: Undecided
Status: New
** Also affects: update-notifier (Ubuntu)
Importance: Undecided
Status: New
--
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 package in Ubuntu:
New
Status in update-notifier package in Ubuntu:
New
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/ubuntu/+source/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
