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

Bug #1392588 reported by Chow Loong Jin
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
debhelper (Ubuntu)
Confirmed
High
Unassigned
whoopsie (Ubuntu)
Incomplete
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

Revision history for this message
Chow Loong Jin (hyperair) wrote :
Revision history for this message
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

Revision history for this message
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
Revision history for this message
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  
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.