presents crash reports repeatedly when /var is mounted noatime

Bug #85809 reported by Bart Samwel
26
Affects Status Importance Assigned to Milestone
apport (Ubuntu)
Fix Released
High
Martin Pitt

Bug Description

Binary package hint: apport

After an application has crashed, a bomb icon is shown in the tray. Clicking it allows me to report the problem. However, the next time I log on, the bomb appears again. And again. And again. The thing is, crash reports are not deleted from /var/crash after reporting. Clearing /var/crash solves the problem -- until the next time an application crashes.

Do you have any idea what could be causing this?

Revision history for this message
Martin Pitt (pitti) wrote :

Hm, usually reports that have been looked at (i. e. access time > modification time) are disregarded. Can you please copy&paste the output of 'mount' here? Also, can you please attach /var/log/apport.log?

Changed in apport:
status: Unconfirmed → Needs Info
Revision history for this message
Bart Samwel (bart-samwel) wrote :

Yes, I have my partitions mounted noatime.

The thing is, laptop mode, which is integrated in Ubuntu's laptop support, automatically mounts all filesystems noatime because this is beneficial for hard drive spindown times. Not _that_ beneficial BTW, but:

(a) it's the default (AFAIK), and
(b) I need it for testing laptop mode tools, of which I'm the upstream maintainer. So yes, I have kind-of special needs here. ;-)

In my experience there are very little tools that actually use atime for anything. The only other example that I know of is mutt, and only on local mailboxes. It would be really useful if atime weren't used here either, especially since it's pretty common to mount filesystems noatime. What are your thoughts on this?

Revision history for this message
Martin Pitt (pitti) wrote :

When atime works, it is really handy. I think a good compromise would be to just delete seen crash reports when atime does not work. How about that?

Changed in apport:
assignee: nobody → pitti
importance: Undecided → Low
status: Needs Info → Confirmed
Revision history for this message
Bart Samwel (bart-samwel) wrote : Re: [Bug 85809] Re: crash reports not erased after reporting

Martin Pitt wrote:
> When atime works, it is really handy. I think a good compromise would be
> to just delete seen crash reports when atime does not work. How about
> that?

Sounds good, as this makes sure that it always works. :-) Thanks!

Martin Pitt (pitti)
Changed in apport:
importance: Low → High
Martin Pitt (pitti)
Changed in apport:
status: Confirmed → Fix Committed
Revision history for this message
Martin Pitt (pitti) wrote :

 apport (0.60) feisty; urgency=low
 .
   * gtk/apport-gtk.glade: Reintroduce window titles. Since the crash
     notifications are like alerts, title have been removed recently to comply
     with Gnome HIG standards, but then the user will get 'nameless window'
     buttons in the task bar. Let's have the smaller evil then. (LP: #87164)
   * apport/packaging.py: Add get_architecture() interface for determining the
     architecture of a particular package (which might not match the overall
     system architecture on multiarch-capable systems, e. g. an i386 Firefox
     package installed on amd64).
   * backends/packaging-dpkg.py: Implement get_architecture() and add test
     case.
   * apport/report.py, add_package_info(): Add Architecture: field.
     (LP: #87424)
   * apport/ui.py: Already mark report as seen when we load it, not just in the
     information collection thread. That way, reports will only be shown once
     on systems which have /var/crash mounted noatime, too. (LP: #85809)
   * apport/fileutils.py, mark_report_seen(): If os.utime() fails, and opening
     the report file for reading does not change the atime (happens with
     noatime mount option), don't throw an exception, just delete the report.
     (other aspect of LP: #85809)
   * qt4/apport-qt: Wrap gettext() into an unicode(str, 'UTF-8') call,
     otherwise all non-ASCII unicode strings are broken. (LP: #87757)

Changed in apport:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.