You can only have one init daemon on a system, so having a separate
Upstart per-chroot doesn't work - the prime system's init daemon would
get the SIGCHLDs, etc. (unless you use pid namespaces and a kernel
patch that Lennart once wrote to redirect init behaviour to other pids)
For me, the right
initctl blocks on Upstart returning, right?
Could you do something clever with /proc/$INITCTL_PID/root?
--
misc: packages cannot be upgraded in a chroot
https://bugs.launchpad.net/bugs/430224
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct
initctl doesn't have to block, no (--no-wait)
--
misc: packages cannot be upgraded in a chroot
https://bugs.launchpad.net/bugs/430224
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
ubuntu-bugs mailing list
** Visibility changed to: Private
** This bug has been flagged as a security vulnerability
--
misc: packages cannot be upgraded in a chroot
https://bugs.launchpad.net/bugs/430224
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
** Visibility changed to: Public
** This bug is no longer flagged as a security vulnerability
--
misc: packages cannot be upgraded in a chroot
https://bugs.launchpad.net/bugs/430224
You received this bug notification because you are a member of Ubuntu
Bugs, which is a direct subscriber.
--
My understanding is that this bug is marked incomplete because it's
currently lacking discussion on how we should handle this.
I propose that the way to resolve this is to implement chroot awareness to
upstart and its commands. Perhaps either of these is possible:
- allow starting a separate
I just noticed this problem has broken cron in some of my chroots.
There needs to be some standard way to run services such as cron within
a chroot. If nothing else, at least a convenience script that can start
and stop services outside of upstart supervision.
--
misc: packages cannot be
I'm marking this as invalid as its only actually sysvinit scripts when
policy-rc.d hasn't been configured correctly that causes problems;
native upstart jobs seem to just ignore not being able to connect to
upstart regardless.
** Changed in: upstart (Ubuntu)
Status: Incomplete = Invalid
native upstart jobs seem to just ignore not being able to connect to
upstart
No, they do not. There are various stock maintainer script snippets that will
ignore these failures on the maintainer script's behalf, but:
a) this removes an important feedback channel about other problems that cause
Running:
rm /sbin/initctl
dpkg-divert --local --remove /sbin/initctl
breaks gdm in both Karmic and mint Helena.
Which leaves egg on my face since I'd included it in my chroot script
for some time!
How can I fix gdm?
--
misc: packages cannot be upgraded in a chroot
In regards to that last post, the problem was easily fixed just by an
install --reinstall upstart.
--
misc: packages cannot be upgraded in a chroot
https://bugs.launchpad.net/bugs/430224
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I started a discussion regarding this at Ubuntu Forums in Lucid testing:
http://ubuntuforums.org/showthread.php?t=1326721
Already one question I can't answer. Following:
dpkg-divert --local --rename --add /sbin/initctl
ln -s /bin/true /sbin/initctl
and completing the upgrade or other
If you're running a chroot or some other environment where you never
want upstart jobs to run, you shouldn't un-divert the initctl.
On Mon, Nov 16, 2009 at 9:04 AM, Erick Brunzell lbsol...@yahoo.com wrote:
I started a discussion regarding this at Ubuntu Forums in Lucid testing:
But if you are running a chroot where you will want upstart to run, for
example, when building a live cd environment from scratch, you do want
to remove the diversion before you exit.
--
misc: packages cannot be upgraded in a chroot
https://bugs.launchpad.net/bugs/430224
You received this bug
This is a problem for builders/testers, not just people using virtual
machines.
Making it harder to customize/test ubuntu will reduce quality going
forward.
I build a customized LiveCD for a research group at Caltech, which is
also made available to similar groups at other universities.
Package
Is there a reason that initctl couldn't respect /usr/sbin/policy-rc.d?
Especially since any real-world policy-rc.d file just exits 101
(disallowed) 99% of the time, it doesn't seem too problematic if
sysadmins have to rewrite theirs to deal with a few more potential
arguments from initctl.
--
On Mon, 2009-10-26 at 06:11 +, Daniel Holbach wrote:
Do you feel I should file a separate ubuntu-releasenotes / upstart bug
about vserver related problems?
No, because I'll just mark it Won't Fix - the problems are with vserver,
not Upstart
Scott
--
Scott James Remnant
sc...@ubuntu.com
Do you feel I should file a separate ubuntu-releasenotes / upstart bug
about vserver related problems?
--
misc: packages cannot be upgraded in a chroot
https://bugs.launchpad.net/bugs/430224
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Would you like to begin that discussion?
** Changed in: upstart (Ubuntu)
Status: New = Incomplete
--
misc: packages cannot be upgraded in a chroot
https://bugs.launchpad.net/bugs/430224
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Text added at
https://wiki.ubuntu.com/KarmicKoala/ReleaseNotes#Upstart%20jobs%20cannot%20be%20run%20in%20a%20chroot:
Upstart jobs cannot be started in a chroot because upstart acts as a
service supervisor, and processes within the chroot are unable to
communicate with the upstart running outside
I don't think release noting this is a very satisfactory solution in the
long term.
Replacing /sbin/initctl with a symlink to /bin/true is a fairly standard
way to disable services in a chroot.
No; a) it's an upstart-specific way to disable services in a chroot, and
b) this bug isn't about how
Unfortunately there's the same problem in vservers.
Things like this won't work any more:
sudo reboot (needs to be restarted from outside the guest)
sudo start/stop/restart service (very problematic as there's a few daemons
already that don't ship old style init scripts any more: cron,
** Changed in: upstart (Ubuntu)
Status: Triaged = Won't Fix
--
misc: packages cannot be upgraded in a chroot
https://bugs.launchpad.net/bugs/430224
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Sounds like we'll need to write a release note to ensure that people are
informed of this, since in practice it is a change in behaviour from
what people are used to. I've added a bug task for that.
** Also affects: ubuntu-release-notes
Importance: Undecided
Status: New
--
misc:
Since there's now a Release Notes target, I don't think there's any
outstanding fix for this for Upstart
** Changed in: upstart (Ubuntu Karmic)
Status: Triaged = Won't Fix
--
misc: packages cannot be upgraded in a chroot
https://bugs.launchpad.net/bugs/430224
You received this bug
** Summary changed:
- blows up package upgrades in a chroot
+ misc: packages cannot be upgraded in a chroot
** Changed in: upstart (Ubuntu Karmic)
Milestone: ubuntu-9.10-beta = None
** Changed in: upstart (Ubuntu Karmic)
Importance: High = Medium
--
misc: packages cannot be upgraded in
26 matches
Mail list logo
