The suggested workaround here is to disable the copying by removing or commenting out the databases in the NSSDATABASES file in the script-config file for the chroot. These are /default/nssdatabases and /default/config by default.
In the future, we will be working on a better scheme for keeping the host and chroot databases in sync which can merge entries rather than overwriting the entire database, which would preserve chroot-specific changes.
The most commonly-used snapshotting method is to use LVM snapshots (chroot type 'lvm-snapshot'). In this case the chroot must exist on an LVM logical volume (LV); snapshots of an LV may then be made with lvcreate(8) during chroot session setup. However, these use up a lot of disk space. A newer method is to use Btrfs snapshots which use up much less disk space (chroot type 'btrfs-snapshot'), and may be more reliable than LVM snapshots. Btrfs is however still experimental, but it is hoped that it will become the recommended method as it matures.
Unions are an alternative to snapshots. In this situation, instead of creating a copy of the chroot filesystem, we overlay a read-write temporary filesystem on top of the chroot filesystem so that any modifications are stored in the overlay, leaving the original chroot filesystem untouched. The Linux kernel has yet to integrate support for union filesystems such as aufs and unionfs, so LVM snapshots are still the recommended method at present.
When schroot runs, it begins a session, runs the specified command or shell, waits for the command or shell to exit, and then it ends the session. For a normal command or shell, this works just fine. However, dæmons normally start up by running in the background and detaching from the controlling terminal. They do this by forking twice and letting the parent processes exit. Unfortunately, this means schroot detects that the program exited (the dæmon is a orphaned grandchild of this process) and it then ends the session. Part of ending the session is killing all processes running inside the chroot, which means the dæmon is killed as the session ends.
In consequence, it's not possible to run a dæmon directly with schroot. You can however do it if you create a session with --begin-session and then run the dæmon with --run-session. It's your responsibility to end the session with --end-session when the daemon has terminated or you no longer need it.
For example, to remove a session named my-session by hand:
NOTE: Do not remove any directories without checking if there are any filesystems mounted below them, since filesystems such as /home could still be bind mounted. Doing so could cause irretrievable data loss!
which would run the command command in the squeeze chroot. While it's not apparent that a session is being used here, schroot is actually doing the following steps:
Now, if you wanted to run more than one command, you could run a shell and run them interactively, or you could put them into shell script and run that instead. But you might want to do something in between, such as running arbitrary commands from a program or script where you don't know which commands to run in advance. You might also want to preseve the chroot state in between commands, where the normal automatic session creation would reset the state in between each command. This is what sessions are for: once created, the session is persistent and won't be automatically removed. With a session, you can run as many commands as you like, but you need to create and delete the session by hand since schroot can't know by itself when you're done with it unlike in the single command case above. This is quite easy: % schroot --begin-session -c squeeze␍ squeeze-57a69547-e014-4f5d-a98b-f4f35a005307
This created a new session based upon the squeeze chroot. The unique name for the session, the session ID, was printed to standard output, so we could also save it as a shell variable at the same time like so: % SESSION=$(schroot --begin-session -c squeeze)␍ % echo $SESSION␍ squeeze-57a69547-e014-4f5d-a98b-f4f35a005307
Now we have created the session and got the session ID, we can run commands in
it using the session ID:
% schroot --run-session -c squeeze-57a69547-e014-4f5d-a98b-f4f35a005307 \
-- command1␍
or % schroot --run-session -c "$SESSION" -- command1␍
and then as many more commands as we like % schroot --run-session -c "$SESSION" -- command2␍ % schroot --run-session -c "$SESSION" -- command3␍ % schroot --run-session -c "$SESSION" -- command4␍
etc.
When we are done with the session, we can remove it with --end-session: % schroot --end-session -c squeeze-57a69547-e014-4f5d-a98b-f4f35a005307␍
or % schroot --end-session -c "$SESSION"␍
Since the automatically generated session names can be long and unwieldy, the --session-name option allows you to provide you own name:
% schroot --begin-session -c squeeze --session-name my-name␍ my-name
The master branch containes the current development release. Stable releases are found on branches, for example the 1.4 series of releases are on the schroot-1.4 branch.
is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.