Daemons in schroot or how to start chroot automatically
On Mon, 2012-07-23 at 10:25 +0100, Roger Leigh wrote:
> On Sun, Jul 22, 2012 at 05:27:14PM +0200, Ramon Hofer wrote:
> > On Son, 2012-07-22 at 15:58 +0100, Roger Leigh wrote:
> > > On Sun, Jul 22, 2012 at 03:25:49PM +0200, Ramon Hofer wrote:
> > > > On Sam, 2012-07-21 at 22:05 +0100, Roger Leigh wrote:
> > > > > I would also check the return status of schroot. If sid-sab
> > > > > already exists, then session creation will fail, and you'll
> > > > > reuse the old session. That might not be incorrect, but
> > > > > in the general case, I'd recommend checking.
> > > >
> > > > I was thinking about this too. But I saw no need to create a new session
> > > > if the old is still there.
> > > > What could be drawbacks of doing so?
> > >
> > > None really; they can even persist across reboots. (That's what
> > > the "recover-session" action is for.)
> >
> > Hmm, then maybe I should check if there'are lost sessions upon the start
> > of the script?
> > Or will either schroot -b or -r work with such a lost session?
>
> By default, the schroot init script will automatically recover any
> sessions at boot (see /etc/default/schroot). So you shouldn't have
> to worry about that. It's basically just running the setup scripts
> again to ensure that all filesystems are mounted, etc.
Ok, great!
I now changed the stop function to (added the if test) to get rid of
error messages when running `sid-sabnzbdplus stop` twice:
stop_sab() {
if [ -f /var/lib/schroot/session/sid-sab ]; then
schroot -rq -c $NAME /etc/init.d/sabnzbdplus stop
schroot -eq -c $NAME
else
echo "SABnzbd+ not running, not stooped" 2>&1
fi
}
Or is there a better way to test if a session is still available?
`schroot -l -c $NAME` didn't work because it returns the same error
message as e.q. `schroot -eq -c $NAME` when the session isn't running
anymore.
Cheers
Ramon
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1343060842.4271.22.camel@hoferr-desktop.hofer.rummelring
07-23-2012, 06:15 PM
Roger Leigh
Daemons in schroot or how to start chroot automatically
On Mon, Jul 23, 2012 at 06:27:22PM +0200, Ramon Hofer wrote:
> I now changed the stop function to (added the if test) to get rid of
> error messages when running `sid-sabnzbdplus stop` twice:
> stop_sab() {
> if [ -f /var/lib/schroot/session/sid-sab ]; then
> schroot -rq -c $NAME /etc/init.d/sabnzbdplus stop
> schroot -eq -c $NAME
> else
> echo "SABnzbd+ not running, not stooped" 2>&1
> fi
> }
>
> Or is there a better way to test if a session is still available?
> `schroot -l -c $NAME` didn't work because it returns the same error
> message as e.q. `schroot -eq -c $NAME` when the session isn't running
> anymore.
That certainly works, but might break with future schroot versions,
since that directory is an implementation detail. You can do
Note that this is also version-specific since only newer versions
add the session: namespace.
Regards,
Roger
--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120723181521.GN25141@codelibre.net">http://lists.debian.org/20120723181521.GN25141@codelibre.net
07-23-2012, 09:09 PM
Ramon Hofer
Daemons in schroot or how to start chroot automatically
On Mon, 2012-07-23 at 19:15 +0100, Roger Leigh wrote:
> On Mon, Jul 23, 2012 at 06:27:22PM +0200, Ramon Hofer wrote:
> > I now changed the stop function to (added the if test) to get rid of
> > error messages when running `sid-sabnzbdplus stop` twice:
> > stop_sab() {
> > if [ -f /var/lib/schroot/session/sid-sab ]; then
> > schroot -rq -c $NAME /etc/init.d/sabnzbdplus stop
> > schroot -eq -c $NAME
> > else
> > echo "SABnzbd+ not running, not stooped" 2>&1
> > fi
> > }
> >
> > Or is there a better way to test if a session is still available?
> > `schroot -l -c $NAME` didn't work because it returns the same error
> > message as e.q. `schroot -eq -c $NAME` when the session isn't running
> > anymore.
>
> That certainly works, but might break with future schroot versions,
> since that directory is an implementation detail. You can do
>
> schroot -l --all-sessions
> ==> session:sid-sbuild-28666af7-3e88-42cd-a83c-16267088d3f6
>
> Note that this is also version-specific since only newer versions
> add the session: namespace.
Thanks alot for your help!
Now I'm testing with
[ "$(schroot -l --all-sessions)" = session:sid-sab ]
and hope that the output of future versions won't change 8-)
Best regards
Ramon
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/1343077759.4639.2.camel@hoferr-desktop.hofer.rummelring
08-15-2012, 11:58 PM
Bob Proulx
Daemons in schroot or how to start chroot automatically
Roger Leigh wrote:
> Bob Proulx wrote:
> > I haven't submitted a bug yet but I always have problems with sysvinit
> > postinst depending upon ischroot and ischroot getting it wrong and
> > that leaving a broken /run - /var/run behind. You might hit that too.
>
> If this is still happening, please file a serious bug against
> ischroot (debianutils IIRC) with the details of your system.
> It should not be getting it wrong in the simple case of a
> chroot.
While looking to file this bug I found that one had already been
filed on 26 Mar 2012.
There has been no response to this bug. With your advice I will add
more information to it and increase the severity to serious.
Bob
08-16-2012, 12:12 AM
Roger Leigh
Daemons in schroot or how to start chroot automatically
On Wed, Aug 15, 2012 at 05:58:03PM -0600, Bob Proulx wrote:
> Roger Leigh wrote:
> > Bob Proulx wrote:
> > > I haven't submitted a bug yet but I always have problems with sysvinit
> > > postinst depending upon ischroot and ischroot getting it wrong and
> > > that leaving a broken /run - /var/run behind. You might hit that too.
> >
> > If this is still happening, please file a serious bug against
> > ischroot (debianutils IIRC) with the details of your system.
> > It should not be getting it wrong in the simple case of a
> > chroot.
>
> While looking to file this bug I found that one had already been
> filed on 26 Mar 2012.
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665827
>
> There has been no response to this bug. With your advice I will add
> more information to it and increase the severity to serious.
Note that this is a bug against initscripts, not debianutils.
Is the problem due to ischroot not working in your chroot?
Or is it due to initscripts not using the return value properly?
If it's a deficiency in the ischroot tool, then please file a
bug against debianutils about it. If it's the latter, then
a followup to the above bug is appropriate.
In the above bug's case, ischroot returns zero if it's a chroot,
1 if it's not a chroot, and 2 if it wasn't possible to tell. We
only run the chroot codepath if we get a zero value back,
otherwise we run the standard codepath for a base system. I'm
not sure that there's a more reasonable solution here--we don't
have the information to make a better choice if it's 2. So it
would be useful to know exactly what the return value of
ischroot is (it must be run as root), and why.
Regards,
Roger
--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120816001201.GW25141@codelibre.net">http://lists.debian.org/20120816001201.GW25141@codelibre.net
08-16-2012, 12:54 AM
Bob Proulx
Daemons in schroot or how to start chroot automatically
Roger Leigh wrote:
> Bob Proulx wrote:
> > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=665827
>
> Note that this is a bug against initscripts, not debianutils.
Yes. But both are buggy! I also filed a bug against ischroot.
> Is the problem due to ischroot not working in your chroot?
> Or is it due to initscripts not using the return value properly?
It is both. But the initscripts bug is the most grevious since it
ignores an error condition and leaves the system in a bad state. True
that ischroot returns the first error. But initscripts ignores the
error.
> If it's a deficiency in the ischroot tool, then please file a
> bug against debianutils about it. If it's the latter, then
> a followup to the above bug is appropriate.
I did that too.
> In the above bug's case, ischroot returns zero if it's a chroot,
> 1 if it's not a chroot, and 2 if it wasn't possible to tell. We
> only run the chroot codepath if we get a zero value back,
> otherwise we run the standard codepath for a base system. I'm
> not sure that there's a more reasonable solution here--we don't
> have the information to make a better choice if it's 2. So it
> would be useful to know exactly what the return value of
> ischroot is (it must be run as root), and why.
There are two issues. And I know that the /run transition was
discussed at length in debian-devel. Unfortunately I wasn't following
it then and only run into this problem now. I think using bind mounts
in either of the two cases is an unfortunate choice. I *really*
dislike it. So for me one issue is that the transition uses bind
mounts at all. But I am still investigating. I haven't figured out
why initscripts takes two different paths depending upon being in a
chroot or not. I think that is the root cause of the problem.
Whatever it decides to do it should to the same thing in either case.
Regardless the chroot problem is that initscripts upgrade in a chroot
leaves the host system with three additional bind mounts in the
chroot. These make working with the chroot by traditional means
difficult. For example in my test case I ended up with these
additional mounts which are invisible inside the chroot.
But worse is that in order to continue to use the chroot that the /run
configuration needs to be manually re-stitched.
Bob
08-16-2012, 10:54 AM
Roger Leigh
Daemons in schroot or how to start chroot automatically
On Wed, Aug 15, 2012 at 06:54:56PM -0600, Bob Proulx wrote:
> There are two issues. And I know that the /run transition was
> discussed at length in debian-devel. Unfortunately I wasn't following
> it then and only run into this problem now. I think using bind mounts
> in either of the two cases is an unfortunate choice. I *really*
> dislike it. So for me one issue is that the transition uses bind
> mounts at all. But I am still investigating. I haven't figured out
> why initscripts takes two different paths depending upon being in a
> chroot or not. I think that is the root cause of the problem.
> Whatever it decides to do it should to the same thing in either case.
So one key question here: do you have /proc mounted inside the
chroot? That's required by ischroot to detect that it's in a chroot;
but more importantly, it's required for lots of things to work
properly, including libc, so it's something which is expected to be
present. Note that it's also used by package maintainer scripts, so
during an upgrade, it's also required.
The reason for the bind mounts. We are migrating:
/var/run -> /run
/var/lock -> /run/lock
/dev/shm -> /run/shm
/lib/init/rw -> [removed]
We are also doing this on a live system. We can't move the locations
except at boot time, but we want it to be functional as soon as
initscripts is configured. Then packages can simply Depend on
(initscripts >= $version) and get a functional /run. So it works in
two stages:
1) Bind mount /var/run, /var/lock and /dev/shm under /run. Any
programs with open files on these filesystems will be unaffected.
Programs can use both the old and new paths without problems.
2) On reboot, mount a tmpfs on /run and replace these directories
with symlinks. Programs can use both the old and new paths.
This works very well. See
http://wiki.debian.org/ReleaseGoals/RunDirectory
for the detail.
However, it won't work in a chroot: chroots don't run init scripts at
boot, so on reboot, the bind mounts will be lost and the migration
won't complete. chroots are a special case, and because we can't
move the directories while they might be in use, we have to adopt a
different strategy. See the latest initscripts postinst in unstable
for what we have to deal with. It's really nasty; but we don't have a
choice. We also have little control over what parts of the host
system are bind mounted on /dev, /dev/shm, /run or /run/shm; we need
to take extra special care never to modify them, lest we break the
host system.
One thing we could do here is check if /proc is mounted with
"mountpoint -q", and then assume we're in a chroot if it fails,
since having /proc not mounted is very unlikely on the host system.
However, it will need careful consideration, since the chroots are
the special case here--we never want to run the special case setup
for a chroot on the host system unintentionally. "Unlikely" isn't
a good enough guarantee here--we need to be absolutely certain.
Regards,
Roger
--
.'`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' schroot and sbuild http://alioth.debian.org/projects/buildd-tools
`- GPG Public Key F33D 281D 470A B443 6756 147C 07B3 C8BC 4083 E800
--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120816105436.GY25141@codelibre.net">http://lists.debian.org/20120816105436.GY25141@codelibre.net
08-21-2012, 07:15 PM
Bob Proulx
Daemons in schroot or how to start chroot automatically
Roger Leigh wrote:
> Bob Proulx wrote:
> > There are two issues. ...
>
> So one key question here: do you have /proc mounted inside the
> chroot?
No. I only do that if the task and applications I am running in the
chroot require it. But for my typical chroot these are rarely
required. Sure they are required to run Chromium, required to run
Apache, required to run a long list of things. But they have never
been required to compile a program for example. Being able to compile
using a specified environment is my usual need for specific
environments.
> That's required by ischroot to detect that it's in a chroot;
Apparently. But I call that a bug since it seems remarkably
insufficient to determine if the process is running in a chroot.
Having or not having /proc mounted isn't related to whether the root
directory of the calling process has been changed to a different root
directory. In practice I think that if there isn't a /proc mounted
then that would be a pretty strong indication that a chroot is in
effect.
Traditional Unix filesystems including ext{2,3,4} set the inode of the
root filesystem to 2. Inodes are uniquely numbered over the
filesystem. When a chroot has changed root to a different directory
then the root inode will be a number other than 2. That has been the
only sure way to know if the process is in a chroot. However I do not
know if all filesystems behave that way and I would bet that they do
not and therefore that test would be insufficient on other
filesystems. Those are the most common for root filesystems though
and using that test on those filesystems would be correct.
> but more importantly, it's required for lots of things to work
> properly, including libc, so it's something which is expected to be
> present.
I am not disagreeing that if we look at the sum total of all code
everywhere that a system expects to have various parts available. But
in the simple case for example of creating a chroot for compiling
software and other simple tasks there hasn't previously been a
requirement for having /proc or other extras mounted. If things are
moved to require it then I think that is a very bad direction of
movement. It makes things that would otherwise be very simple much
more complicated. That is bad.
Note that I did specify a policy-rc.d script to disallow running any
daemons other than those listed in the example.
So I do disagree that a simple chroot requires /proc. It never needed
it for Squeeze. If it has become so now then that is a terrible
misfeature and should be improved so as not to require it anymore.
> Note that it's also used by package maintainer scripts, so
> during an upgrade, it's also required.
Other than the 'initscripts' package what others in the basic
debootstrap related packages require it?
I think it is unfortunate to the point of being a bug that initscripts
has this dependency. Fortunately it is only during an upgrade and it
seems to work okay subsequently without it. So I only need to bridge
the gap of an upgrade. It definitely goes in my documentation of
special handling that is required for an upgrade.
I understand that Chromium, Apache, others, need /proc and other
extras. I am not disputing the long list of packages in the entire
repository. But in the basic system there hasn't been a need for it
previously. I am talking debootstrapping a basic installation and
installing basic things like build-essential. And I think that
includes the entire history of Unix-like systems since the early days.
I have been using chroots for a very long time. It is a very useful
feature.
> > And I know that the /run transition was
> > discussed at length in debian-devel. Unfortunately I wasn't following
> > it then and only run into this problem now. I think using bind mounts
> > in either of the two cases is an unfortunate choice. I *really*
> > dislike it. So for me one issue is that the transition uses bind
> > mounts at all. But I am still investigating. I haven't figured out
> > why initscripts takes two different paths depending upon being in a
> > chroot or not. I think that is the root cause of the problem.
> > Whatever it decides to do it should to the same thing in either case.
>
> The reason for the bind mounts. We are migrating:
> /var/run -> /run
> /var/lock -> /run/lock
> /dev/shm -> /run/shm
> /lib/init/rw -> [removed]
> We are also doing this on a live system. We can't move the locations
> except at boot time, but we want it to be functional as soon as
> initscripts is configured. Then packages can simply Depend on
> (initscripts >= $version) and get a functional /run. So it works in
> two stages:
> 1) Bind mount /var/run, /var/lock and /dev/shm under /run. Any
> programs with open files on these filesystems will be unaffected.
> Programs can use both the old and new paths without problems.
> 2) On reboot, mount a tmpfs on /run and replace these directories
> with symlinks. Programs can use both the old and new paths.
> This works very well. See
> http://wiki.debian.org/ReleaseGoals/RunDirectory
> for the detail.
Thank you very much for that nice summary! It helps me a lot.
> However, it won't work in a chroot: chroots don't run init scripts at
> boot, so on reboot, the bind mounts will be lost and the migration
> won't complete.
And in the case of a simple chroot the bind mounts make the
directories "busy" and create a sumbling block. Until the system is
rebooted and then things return to a non-blocked state. But of course
then the /run related dirs need to be fixed up.
> chroots are a special case, and because we can't
> move the directories while they might be in use, we have to adopt a
> different strategy. See the latest initscripts postinst in unstable
> for what we have to deal with.
I will read through them.
> It's really nasty; but we don't have a choice.
You always have choices. You may not like the current ones. There
will always be possibilities you have not thought of yet. They are
many and uncountable.
Perhaps a better statement would be that among the choices considered
the least objectionable choice was taken.
> We also have little control over what parts of the host
> system are bind mounted on /dev, /dev/shm, /run or /run/shm; we need
> to take extra special care never to modify them, lest we break the
> host system.
Agreed.
> One thing we could do here is check if /proc is mounted with
> "mountpoint -q", and then assume we're in a chroot if it fails,
> since having /proc not mounted is very unlikely on the host system.
Yes. That would definitely improve things.
At the least if ischroot returns an error then you know there is
already problem with the postinst assumptions. That case is
definitely not handled correctly.
> However, it will need careful consideration, since the chroots are
> the special case here--we never want to run the special case setup
> for a chroot on the host system unintentionally. "Unlikely" isn't
> a good enough guarantee here--we need to be absolutely certain.
Given the choice between host system breakage and chroot system
breakage I would of course always choose breaking the chroot over
breaking the host system.
But if that is a possibility to break something then improved
documentation in the form of yet another critical package NEWS item
should explain the reason for the breakage and what needs to be done
to work around it.
Daemons in schroot or how to start chroot automatically
