whoopsie's postinst fails when systemd is running and report_crashes=false in /etc/default/whoopsie
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/
Active: failed (Result: start-limit) since Fri 2014-11-14 12:51:17 SGT; 11min ago
Process: 29535 ExecStartPre=
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/
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/
+ chmod 0640 /var/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.
+ [ -x /etc/init.
+ [ -e /etc/init/
+ 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.
update-rc.d whoopsie defaults >/dev/null
fi
if [ -x "/etc/init.
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:
CurrentDesktop: Unity
Date: Fri Nov 14 12:57:19 2014
RelatedPackageV
SourcePackage: whoopsie
UpgradeStatus: Upgraded to utopic on 2014-10-23 (21 days ago)
modified.
[General]
report_
report_
mtime.conffile.
Changed in whoopsie (Ubuntu): | |
importance: | Undecided → High |
Changed in debhelper (Ubuntu): | |
importance: | Undecided → High |
Setting report_crashes=true in /etc/default/ whoopsie at least allows dpkg to complete:
Setting up whoopsie (0.2.39ubuntu0.1) ... whoopsie. 0.crash whoopsie. 0.crash d/whoopsie ] d/whoopsie ] whoopsie. conf ] t-helper rm_conffile /etc/cron. daily/whoopsie 0.1.25 -- configure 0.2.39
+ [ configure = configure ]
+ getent passwd whoopsie
+ mkdir -p -m 3777 /var/crash
+ chmod g+s /var/crash
+ chgrp whoopsie /var/crash
+ chgrp whoopsie /var/crash/
+ chmod 0640 /var/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.
+ [ -x /etc/init.
+ [ -e /etc/init/
+ invoke-rc.d whoopsie start
+ [ -d /run/systemd/system ]
+ systemctl --system daemon-reload
+ deb-systemd-invoke start whoopsie.service
+ dpkg-maintscrip
+ exit 0