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

Roger Leigh rleigh at whinlatter.ukfsn.org
Sun Sep 25 16:07:53 UTC 2005


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Jacobowitz <dan at debian.org> writes:

> On Wed, Sep 21, 2005 at 09:06:41PM +0100, Roger Leigh wrote:
>> tags 329403 + confirmed fixed-upstream pending
>> thanks
>> 
>> Roger Leigh <rleigh at whinlatter.ukfsn.org> writes:
>> 
>> > Daniel Jacobowitz <dan at debian.org> writes:
>> >
>> >> Enabling the scripts on a per-chroot basis in schroot.conf perhaps?
>> >
>> > That's even better, thanks.
>> 
>> I've installed the following changes into CVS to fix this.  This will
>> be uploaded to Debian in a few days, pending some other changes.
>
> Thanks!  This looks perfect.

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.

These are configured independently, with two options:

  run-setup-scripts (previously run-setup)  Defaults to false (don't run)
  run-session-scripts  Defaults to true (do run)

The session scripts are to do per-user setup tasks, for example to
create /build/$user for sbuild.  Unlike the setup scripts, they should
be harmless, so I've defaulted them to run.

Overall, things get run like this

/etc/schroot/setup.d/* called with "setup-start"
{
  [chroot constructed and is now present at $CHROOT_MOUNT_LOCATION]
  /etc/schroot/session.d/* called with "session-start"
  {
    [session command or shell is run]
  }
  /etc/schroot/session.d/* called in reverse order with "session-stop"

  /etc/schroot/session.d/* called with "session-start"
  {
    [session command or shell is run]
  }
  /etc/schroot/session.d/* called in reverse order with "session-stop"

  [session may be entered and left multiple times...]
}
/etc/schroot/setup.d/* called in reverse order with "setup-stop"
[chroot session state and possibly also actual chroot is deleted]


Is this acceptable to you?

I won't have this uploaded for a few days; I'm still working on the
locking issues with the session state files.  I'm going to create a
/var/lock/schroot/$session_uuid lockfile while reading/writing
/var/lock/schroot/session/$session_uuid, but I also need to implement
some form of read lock so I don't partially read session state while
another instance is writing it out.


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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFDNstTVcFcaSW/uEgRArwEAKCU3OFVrhSiJJsowkiog68fX5x40gCeKLFT
grXRwdqXM3s7ftcUibdYYT4=
=6Srk
-----END PGP SIGNATURE-----




More information about the Buildd-tools-devel mailing list