Bug#329403: [Buildd-tools-devel] Bug#329403: schroot: Clobbers files in the chroot without warning

[Roger Leigh]

Daniel Jacobowitz <dan at debian.org> writes:

> On Sun, Sep 25, 2005 at 05:07:53PM +0100, Roger Leigh wrote:
>> I've make a slight change to this scheme.  There are now two script
>> directories:
>> 
>>   - /etc/schroot/setup.d   Scripts used to create, set up and destroy
>>                            chroots (same as existing scheme).  Run
>>                            once during chroot setup, and once during
>>                            teardown.
>>   - /etc/schroot/session.d Scripts run on chroot entry and exit to do
>>                            additional setup/cleanup.  These may be run
>>                            multiple times during the chroot lifetime.
>> 
>> "Lifetime" here refers to creation and destruction of persistent
>> session state.  For LVM snapshots, this will correspond with creation
>> of the snapshot and its removal.  For block devices, it corresponds
>> with mounting and unmounting, and for plain chroots means doing
>> nothing except perhaps mounting ancillary filesystems and passwd
>> setup.
>
> I'm trying to map this onto the simple way I use it and I'm not having
> much luck.  What's the "lifetime" of a chroot?  I assumed it was "while
> any sessions are running" except (a) you can't usefully judge that; I
> run daemons in a chroot using schroot; and (b) your example further
> down shows a session ending and then another one starting without the
> chroot being "destroyed".

The behaviour depends upon the chroot type.  If it's a "plain" chroot,
then it will continue to exist after schroot has ended.  In this case,
if you disable the scripts, it's no different than dchroot.

I might be able to demonstrate this better if I explain what the
feature is for.  The session stuff primarily exists for sbuild, so
that I can build in automatically created LVM snapshots.  With this
scenario, I want to be able to create a new chroot as a snapshot at
the start of the build.  Without session support, the snapshot gets
created and destroyed each time I run schroot, but during the build I
want to run several commands to e.g. install packages, download
sources, do the build etc..  What I really want is for it to persist
for the duration of the build, and get removed at the end.

For LVM snapshots, the "lifetime" is the time the chroot exists, from
initial chroot creation through to destruction.  During that period,
schroot may be run many times, specifying an existing session to
restore.  It will work like this:

$ SESSION=$(schroot --begin-session --chroot=unstable)
[LVM snapshot created, session key stored in $SESSION]
$ echo $SESSION
08903913-2599-4bb3-b555-6ac99bae3793
$ schroot --run-session=$SESSION "command1"
[Run command in an existing chroot session]
$ schroot --run-session=$SESSION "command2"
$ schroot --run-session=$SESSION "command3"
$ schroot --run-session=$SESSION "command4"
$ schroot --end-session=$SESSION
[Finally end the session, deleting the LVM snapshot]

For normal chroots, the session exists only for the lifetime of the
schroot process.

This is only needed because sbuild is written in Perl.  If I could
move the necessary parts into C code, it could all run in one process,
and handle the session management internally.  I've written schroot
with this in mind (the core objects could be moved into a library).
In the meantime, this is to integrate with the existing sbuild code.

> Especially since the schroot documentation that I'm looking at here
> doesn't say anything about creating snapshots, mounting devices, et
> cetera, so I assume this is all something new...

Yes, it will be in 0.1.6.  This introduces chroot "types".  Currently,
it supports "plain" traditional filesystem chroots, "block-device"
(devices mounted on demand) and "lvm-snapshot" (LVM snapshot created
on demand).  It's only for the LVM snapshot types that the session
stuff is really useful.

> All I was looking for was a superior and packaged alternative to
> dchroot.  I'm worried that as you make schroot increasingly more
> powerful it's going to get harder to do simple things with it.

I've tried hard to make the defaults "just work".  I'd like it to work
as a dchroot alternative out of the box; the extra features can
otherwise be ignored, and default to "off" for that reason.  If that's
not happening, I'll be happy to make whatever changes are necessary.


Regards,
Roger

-- 
Roger Leigh
                Printing on GNU/Linux?  http://gimp-print.sourceforge.net/
                Debian GNU/Linux        http://www.debian.org/
                GPG Public Key: 0x25BFB848.  Please sign and encrypt your mail.