Fails to update in pbuilder: start: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused

Bug #602896 reported by Stefano Rivera on 2010-07-07
44
This bug affects 6 people
Affects Status Importance Assigned to Milestone
procps (Ubuntu)
Low
Kees Cook
Maverick
High
Unassigned
Natty
Low
Kees Cook

Bug Description

Binary package hint: procps

# dpkg --configure -a
Setting up procps (1:3.2.8-9ubuntu3) ...
start: Unable to connect to Upstart: Failed to connect to socket /com/ubuntu/upstart: Connection refused
dpkg: error processing procps (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 procps

Cause is not allowing propc start to fail in the postinst script. Patch attached.

Related branches

Stefano Rivera (stefanor) wrote :
description: updated
dn (nobled) on 2010-07-19
Changed in procps (Ubuntu):
status: New → Confirmed
dn (nobled) wrote :

Yeah, developing/testing with pbuilder is pretty much impossible because of this bug.

I put the patch into debdiff format if that makes it easier to sponsor.

Benjamin Drung (bdrung) wrote :

dh, please use your real name in the changelog stanza instead of your nick (nobled).

Benjamin Drung (bdrung) on 2010-08-15
Changed in procps (Ubuntu):
status: Confirmed → Incomplete
Stefano Rivera (stefanor) wrote :

MIght as well do my own debdiff, (why didn't I do it ages ago)?

Changed in procps (Ubuntu):
status: Incomplete → Confirmed
importance: Undecided → Low
Steve Langasek (vorlon) wrote :

The real bug here is that procps is calling 'start' from the maintainer script at all. 'start' is not a standardized maintainer script interface; we should be calling 'invoke-rc.d' instead for all services, including those with upstart jobs. If this were fixed, I believe pbuilder uses an appropriate policy-rc.d in its chroots to avoid accidentally starting services.

Stefano Rivera (stefanor) wrote :

> we should be calling 'invoke-rc.d' instead for all services, including those with upstart jobs.

That makes sense. I'd assumed that it wasn't used for upstart jobs because every upstartified package I've seen doesn't use it.

Steve Langasek (vorlon) wrote :

Sorry for the late turnaround on this. I was going to make a case for getting this fixed post-RC on the grounds that it would break debootstrap, but now I realize that debootstrap correctly diverts /sbin/initctl when bootstrapping, in addition to start-stop-daemon - so the impact does indeed appear to be low, since it seems recommended best practices after setting up a chroot are to divert /sbin/initctl to /bin/true anyway.

This is still a bug which we should correct for natty, but I think the correct fix is to drop this line out of debian/postinst *entirely*, and instead use dh_installinit's support for starting and stopping jobs, which already knows how to do do this. Kees, you appear to be the author of this change; do you recall why you hard-coded a 'start' command in procps postinst, rather than changing debian/rules to not override dh_installinit's behavior in the first place? I don't see anything in the changelog that explains why we need to run the procps job on package install, if Debian isn't doing it this way.

Steve Langasek (vorlon) wrote :

I think this patch is the correct fix.

Kees Cook (kees) wrote :

Sorry, it's lost to history. The debdiff looks correct to me. Thanks for catching and fixing this!

Sebastien Bacher (seb128) wrote :

Steve, Kees, could one of you get that uploaded?

Kees Cook (kees) on 2010-11-04
Changed in procps (Ubuntu):
assignee: nobody → Kees Cook (kees)
milestone: none → natty-alpha-2
Changed in procps (Ubuntu Natty):
status: Confirmed → Fix Committed
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package procps - 1:3.2.8-9ubuntu4

---------------
procps (1:3.2.8-9ubuntu4) natty; urgency=low

  * debian/postinst, debian/rules: instead of manually calling 'start' in
    the postinst, allow dh_installinit to DTRT. LP: #602896.
  * debian/sysctl.d/README: fix the documentation to point at the standard
    interfaces, not at the 'start' command.
 -- Steve Langasek <email address hidden> Sat, 02 Oct 2010 00:08:14 +0000

Changed in procps (Ubuntu Natty):
status: Fix Committed → Fix Released
Steve Langasek (vorlon) wrote :

The SRU for bug #771372 shows that this bug is still a problem in maverick: the installer diverts initctl when initially bootstrapping the base system, but for some reason when it comes time to apply any package updates (such as from -updates or -proposed), initctl is no longer diverted, which means calling 'start' directly is guaranteed to fail. There's a bug in debian-installer that this is happening, but we already know that procps is also buggy and needs fixed, so we should include that in the SRU.

Changed in procps (Ubuntu Maverick):
status: New → In Progress
importance: Undecided → High

Hello Stefano, or anyone else affected,

Accepted procps into maverick-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Changed in procps (Ubuntu Maverick):
status: In Progress → Fix Committed
tags: added: verification-needed
Stefano Rivera (stefanor) wrote :

LGTM

tags: added: verification-done
removed: verification-needed
JC Hulce (soaringsky) wrote :

This bug affects Ubuntu 10.10, Maverick Meerkat. Maverick has reached end-of-life and is no longer supported, so I am closing the bugtask for Maverick. Please upgrade to a newer version of Ubuntu.
More information here: https://lists.ubuntu.com/archives/ubuntu-announce/2012-April/000158.html

Changed in procps (Ubuntu Maverick):
status: Fix Committed → Invalid
Liviu Andronic (landronimirc) wrote :

Hello
I've encountered this issue while upgrading from Lucid to Precise. That means that the issue is likely still present in Precise.

The upgrade process botched and now I can operate Ubuntu only from a chroot environment. (For the discussion on the ML see [1].) The first error that arises is this:
Setting up procps (1:3.2.8-11ubuntu6) ...
 initctl: Unable to connect to Upstart: Failed to connect to socket
 /com/ubuntu/upstart: Connection refused
 start: Unable to connect to Upstart: Failed to connect to socket
 /com/ubuntu/upstart: Connection refused
 invoke-rc.d: initscript procps, action "start" failed.
 dpkg: error processing procps (--configure):
  subprocess installed post-installation script returned error exit status 1
[..]

For various logs see this:
 cat /var/log/dist-upgrade/ : http://paste.ubuntu.com/1187299/
  dpkg --configure -a : http://paste.ubuntu.com/1187465/
  apt-get -fy install : http://paste.ubuntu.com/1187482/
  apt-get dist-upgrade : http://paste.ubuntu.com/1187510/
  dpkg --get-selections : http://paste.ubuntu.com/1187518/

Any suggestions on how to work around this issue?

[1] http://www.mentby.com/Group/xubuntu-users/failure-to-upgrade-from-1004-to-12041.html

Stefano Rivera (stefanor) wrote :

Liviu: While chrooted, you probably don't want to start any services.

I suggest creating an executable "/usr/sbin/policy-rc.d" containing simply "exit 101". That will make invoke-rc.d refuse to start or stop services. Remove this again before trying to boot the system.

On Fri, Sep 7, 2012 at 2:21 PM, Stefano Rivera <email address hidden> wrote:
> Liviu: While chrooted, you probably don't want to start any services.
>
> I suggest creating an executable "/usr/sbin/policy-rc.d" containing
> simply "exit 101". That will make invoke-rc.d refuse to start or stop
> services. Remove this again before trying to boot the system.
>
This is excellent advice! Thank you so much. With the suggestion above
apt-get managed to finish installing the packages.

I still have trouble properly booting the new system, but this is
unrelated to this report.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers