whoopsie's postinst fails when systemd is running and report_crashes=false in /etc/default/whoopsie

Bug #1392588 reported by Chow Loong Jin on 2014-11-14
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
debhelper (Ubuntu)
High
Unassigned
whoopsie (Ubuntu)
High
Unassigned

Bug Description

Here's the output of systemctl status whoopsie

whoopsie.service - crash report submission daemon
   Loaded: loaded (/lib/systemd/system/whoopsie.service; enabled)
   Active: failed (Result: start-limit) since Fri 2014-11-14 12:51:17 SGT; 11min ago
  Process: 29535 ExecStartPre=/bin/grep -sqi report_crashes=true /etc/default/whoopsie (code=exited, status=1/FAILURE)

As you can see, ExecStartPre intentionally fails the starting of whoopsie.service when report_crashes=true is not found. This is fine, and done even during the upstart days.

However, the postinst doesn't seem to handle it so well. I added set -x to /var/lib/dpkg/info/whoopsie.postinst, and found the following output:

Setting up whoopsie (0.2.39ubuntu0.1) ...
+ [ configure = configure ]
+ getent passwd whoopsie
+ mkdir -p -m 3777 /var/crash
+ chmod g+s /var/crash
+ chgrp whoopsie /var/crash
+ chgrp whoopsie /var/crash/whoopsie.0.crash
+ chmod 0640 /var/crash/whoopsie.0.crash
+ mkdir -p -m 3777 /var/metrics
+ chmod g+s /var/metrics
+ chgrp whoopsie /var/metrics
+ deb-systemd-helper unmask whoopsie.service
+ deb-systemd-helper --quiet was-enabled whoopsie.service
+ deb-systemd-helper enable whoopsie.service
+ [ -x /etc/init.d/whoopsie ]
+ [ -x /etc/init.d/whoopsie ]
+ [ -e /etc/init/whoopsie.conf ]
+ invoke-rc.d whoopsie start
Job for whoopsie.service failed. See 'systemctl status whoopsie.service' and 'journalctl -xn' for details.
invoke-rc.d: initscript whoopsie, action "start" failed.
+ exit 1
dpkg: error processing package whoopsie (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 whoopsie

The affected section in the postinst looks like this:
# Automatically added by dh_installinit
if [ -x "/etc/init.d/whoopsie" ]; then
 update-rc.d whoopsie defaults >/dev/null
fi
if [ -x "/etc/init.d/whoopsie" ] || [ -e "/etc/init/whoopsie.conf" ]; then
 invoke-rc.d whoopsie start || exit $?
fi
# End automatically added section

I'm not sure if the packaging of whoopsie is at fault, or dh_installinit is at fault here. In the first place, is it right to fail a package upgrade just because the service refuses to launch?

ProblemType: Bug
DistroRelease: Ubuntu 14.10
Package: whoopsie 0.2.39ubuntu0.1
Uname: Linux 3.16.2-hyper1 x86_64
ApportVersion: 2.14.7-0ubuntu8
Architecture: amd64
CrashReports: 640:0:154:278767:2014-11-14 09:48:15.120531913 +0800:2014-11-14 09:48:14.926532689 +0800:/var/crash/whoopsie.0.crash
CurrentDesktop: Unity
Date: Fri Nov 14 12:57:19 2014
RelatedPackageVersions: apport-noui N/A
SourcePackage: whoopsie
UpgradeStatus: Upgraded to utopic on 2014-10-23 (21 days ago)
modified.conffile..etc.default.whoopsie:
 [General]
 report_crashes=false
 report_metrics=false
mtime.conffile..etc.default.whoopsie: 2014-11-14T09:52:54.378414

Chow Loong Jin (hyperair) wrote :
Chow Loong Jin (hyperair) wrote :

Setting report_crashes=true in /etc/default/whoopsie at least allows dpkg to complete:

Setting up whoopsie (0.2.39ubuntu0.1) ...
+ [ configure = configure ]
+ getent passwd whoopsie
+ mkdir -p -m 3777 /var/crash
+ chmod g+s /var/crash
+ chgrp whoopsie /var/crash
+ chgrp whoopsie /var/crash/whoopsie.0.crash
+ chmod 0640 /var/crash/whoopsie.0.crash
+ mkdir -p -m 3777 /var/metrics
+ chmod g+s /var/metrics
+ chgrp whoopsie /var/metrics
+ deb-systemd-helper unmask whoopsie.service
+ deb-systemd-helper --quiet was-enabled whoopsie.service
+ deb-systemd-helper enable whoopsie.service
+ [ -x /etc/init.d/whoopsie ]
+ [ -x /etc/init.d/whoopsie ]
+ [ -e /etc/init/whoopsie.conf ]
+ invoke-rc.d whoopsie start
+ [ -d /run/systemd/system ]
+ systemctl --system daemon-reload
+ deb-systemd-invoke start whoopsie.service
+ dpkg-maintscript-helper rm_conffile /etc/cron.daily/whoopsie 0.1.25 -- configure 0.2.39
+ exit 0

Brian Murray (brian-murray) wrote :

I believe the following changes may have fixed this particular bug:

whoopsie (0.2.42) vivid; urgency=medium

  * Disable whoopsie in systemd if the sysadmin set it as disabled in
    /etc/default/whoopsie: (LP: #1390014)
    - remove report_crashes key from the conffile
    - if was set to false, generate an upstart override and disable it
      with systemctl
    - remove the condition in the upstart job, just use the override
  * Add Environment= to units instead of executing a shell script to set
    the daemon env.
  * Ship an init script file and handle upstart/init startup being disabled
    depending on /etc/default/whoopsie.
  * Use systemd debhelper sequence now.

 -- Didier Roche <email address hidden> Thu, 06 Nov 2014 12:32:06 +0100

Do you mind double checking? Thanks!

Changed in whoopsie (Ubuntu):
status: New → Incomplete
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in debhelper (Ubuntu):
status: New → Confirmed
Changed in whoopsie (Ubuntu):
importance: Undecided → High
Changed in debhelper (Ubuntu):
importance: Undecided → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers