On Mon, 22 Jun 2015, Oliver Grawert wrote: >Am Montag, den 22.06.2015, 20:21 +0200 schrieb Torsten Sachse: >> On Mon, 22 Jun 2015, Steve Langasek wrote: >> > The only part that should be running when not on wifi is the crash >> > collection. We certainly *should* be running that when not on >> > wifi; you don't get a second chance to run the kernel crash >> > handler, and we want to know about crashes that only happen when >> > not on wifi (including, possibly, crashes that happen /because/ >> > you're not on wifi). >> >> While that may be true, there has to be an option to switch off such >> crash collection permanently or temporarily. This must not be >> enforced on the user, which is the way it is right now, if I >> understood all this correctly. > >there is a bug, bugs happen, people make mistakes ... you make it >sound like this is intentional ...
I know that people make mistakes as I just made a stupid one myself. To me, Steve's email sounded as if it was intentional due to the highlighted "should" which I misunderstood as a "must". I know now that I completely missed the point of the message. On Mon, 22 Jun 2015, Steve Langasek wrote: > There is an option, and there is reportedly a bug in the handling of > that option, as was already mentioned in this thread. > https://bugs.launchpad.net/ubuntu/+source/whoopsie-preferences/+bug/1437633 Thank you for the link, I must have overlooked that one somehow. Sorry for that. However, I can confirm that the option sticks after making the system writable. Actually, after remounting / as ro again, the option can no longer be switched on (consistent which what's decribed in the above thread). > I was responding to the suggestion that the behavior should somehow be > dependent on whether the device is connected to wifi at the time of > the crash. That's just wrong. I completely agree. The data should either be collected or not at all, irrespective of the current network connectivity. > While the shell can't do anything with the crashed app until the crash > handler has finished, that *shouldn't* mean that it prevents the shell > from, e.g., switching apps. This is why people were asking about > crash files for unity8. It's unexpected that a crashed app should > take out the /whole/ UI, and if that happens that's a bug in unity8, > not just a bug in the app that's crashing. Thanks for all the information. Cheers, Torsten -- 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/1278780 Title: apport takes too long to write crash report, appears to lock up phone Status in Apport crash detection/reporting: Confirmed Status in apport package in Ubuntu: Triaged Bug description: I can trigger a crash easily on my phone via bug 1262711. Other bugs are available. When that happens my phone appears to freeze. I am unable to do anything for approximately 1 to 1.5 minutes. As a user my initial gut reaction is to reboot the phone, thus losing the crash report, and wasting my time. Having the phone lock up for 1.5 minutes is a terrible user experience. Can we fix/mitigate/workaround that? ProblemType: Bug DistroRelease: Ubuntu 14.04 Package: apport 2.13.2-0ubuntu2 Uname: Linux 3.4.0-3-mako armv7l ApportVersion: 2.13.2-0ubuntu2 Architecture: armhf CrashReports: 664:32011:110:10083:2014-02-10 15:41:18.152893384 +0000:2014-02-10 15:11:09.169231740 +0000:/var/crash/_usr_lib_arm-linux-gnueabihf_upstart-app-launch_desktop-hook.32011.crash 640:0:110:1681527:2014-02-10 15:12:10.985193887 +0000:2014-02-10 15:12:05.639489630 +0000:/var/crash/_usr_bin_powerd.0.crash 640:0:110:21384:2014-02-11 07:58:44.876281991 +0000:2014-02-11 07:58:44.876281991 +0000:/var/crash/_usr_sbin_system-image-dbus.0.crash 640:32011:110:17122318:2014-02-11 09:19:49.915478726 +0000:2014-02-11 09:18:20.850439824 +0000:/var/crash/_usr_bin_unity8.32011.crash Date: Tue Feb 11 09:20:15 2014 InstallationDate: Installed on 2014-02-11 (0 days ago) InstallationMedia: Ubuntu Trusty Tahr (development branch) - armhf (20140211) PackageArchitecture: all ProcEnviron: TERM=linux PATH=(custom, no user) XDG_RUNTIME_DIR=<set> SHELL=/bin/bash SourcePackage: apport UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/apport/+bug/1278780/+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