Comment 6 for bug 1058158

This is particularly painful when the compositing or window manager is what crashed. apport-gtk eats all CPU for 90 seconds, during which, there is little or no UI feedback about what's happening and a user would assume that the entire system needs to be rebooted.

From the eons I had to watch the system in a vt, it looks like apport-gtk isn't nice at all. No "N" in process state.

cmiller 29887 10.5 2.7 195012 83720 ? Sl 18:43 0:25 /usr/bin/python3 /usr/share/apport/apport-gtk
cmiller 29894 12.0 2.7 195000 83684 ? Sl 18:43 0:28 /usr/bin/python3 /usr/share/apport/apport-gtk

Some vmstat lines make it look like it's churning on IO.

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r b swpd free buff cache si so bi bo in cs us sy id wa
 2 0 0 227272 158884 1364532 0 0 892 0 767 1568 67 33 0 1
 5 0 0 220800 160412 1367096 0 0 4252 0 1007 2059 68 31 1 1
 2 0 0 213420 160932 1374324 0 0 5352 0 1071 2176 63 36 0 1

One of those apport-gtk threads is off running Python several times to gather information that doesn't change with the process state, like release name. That sort of thing could be deferred and run slowly and nicely so the user can't notice. I don't need to report a crash right *now*, just some time today.