Mr. Junjiro R. Okajima,
nearly two years ago I send you the script bldchraufs. Since
that time
many things have changed. This concerns the Linux kernel - now the
kernel is dressed with a three as major number - and the current
Debian
distribution of the testing domain is called Wheezy. All these
changes
have had an impact on the script bldchraufs. For that reason an
adapta-
tion of the script was necessary.
These adaptations concerns mainly the following points:
- Debian distribution Wheezy introduced a new directory run. This
new directory is now the home of the shared memory directory shm.
- With Wheezy vanished the init script hal.
The attached tape archive includes the first release candidate
of the
adapted script bldchraufs. The script is a part of the all in one
script bldchraufs-0.2rc1.aio. In addition, the all in one script
includes
three new example scripts. These scripts demonstrate the
automatized
building, removing and cleaning of a change root environment
based on
AUFS. More instructions can be found in the script
bldchraufs-0.2rc1.aio.
1. Kernel messages
I send you the first release candidate and not a final version
because
I have questions concerning some kernel messages that I saw
during the
creation and removal of the chroot environment.
The first kernel message appears during the run of the following
script:
$> sudo /bin/bash /usr/local/share/bldchraufs/build_chroot.sh
This script creates the ro and rw branches under /tmp/
jailcache.ro.*
and /tmp/jailcache.rw.* and unifies both branches in the directory
/tmp/jail. The code of the script build_chroot.sh is printed under
chapter thirteen in the script bldchraufs-0.2rc1.aio.
The following kernel message is the output that was produced during
the run of the above mentioned script:
[ 99.881160] aufs: module is from the staging directory, the
quality
is unknown, you have been warned.
[ 99.884200] aufs 2.1-standalone.tree-3.0-rcN-20110711
[ 99.984955] aufs test_add:262:mount[2493]: uid/gid/perm
/tmp/jailcache.ro.usrlocal 0/50/02775, 0/0/0755
[ 100.071844] aufs test_add:262:mount[2499]: uid/gid/perm
/tmp/jailcache.ro.home 1000/1000/0755, 0/0/0755
It seems that the above message has only a informational meaning
and can be ignored.
The second kernel message was written during the GNOME Desktop
session log in:
[ 129.434722] aufs au_opts_parse:1039:mount[3397]: unknown option
errors=remount-ro
[ 129.441762] aufs au_opts_parse:1039:mount[3398]: unknown option
commit=0
[ 129.452269] aufs au_opts_parse:1039:mount[3400]: unknown option
commit=0
[ 129.468503] aufs au_opts_parse:1039:mount[3402]: unknown option
commit=0
[ 129.473906] aufs au_opts_parse:1039:mount[3403]: unknown option
commit=0
[ 129.477398] aufs au_opts_parse:1039:mount[3404]: unknown option
commit=0
This message makes me a little bit nervous because I don't
understand
the meaning of the message text. Maybe I used the wrong options to
mount the branches. Please, could you take a look on the script
bldchraufs. You find the code of bldchraufs in chapter twelve of
the
all in one script bldchraufs-0.2rc1.aio.
The last kernel message was produced during the removal of the
chroot
environment. The following command removes the bindings and mounted
branches of the created chroot environment:
$> sudo /bin/bash /usr/local/share/bldchraufs/remove_chroot.sh
The code of the above script remove_chroot.sh is printed under
chapter fourteen in the all in one script bldchraufs-0.2rc1.aio.
Now follows the kernel message that pops up during the run of the
above mentioned script:
[ 3942.141187] ------------[ cut here ]------------
[ 3942.141298] WARNING: at /build/buildd-linux-2.6_3.0.0-3-
amd64-9ClimQ/
linux-2.6-3.0.0/debian/build/source_amd64_none/fs/
aufs/
plink.c:450 au_plink_put+0x39/0x6b [aufs]()
[ 3942.141531] Hardware name: M720-US3
[ 3942.141588] pseudo-link is not flushed
[ 3942.141649] Modules linked in: aufs(C)
.
.
.
many kernel modules
.
.
.
[last unloaded: scsi_wait_scan]
[ 3942.143848] Pid: 4071, comm: umount Tainted:
P C O 3.0.0-1-amd64 #1
[ 3942.143957] Call Trace:
[ 3942.144038] [<ffffffff81046521>] ? warn_slowpath_common
+0x78/0x8c
[ 3942.144147] [<ffffffff810465d6>] ? warn_slowpath_fmt+0x45/0x4a
[ 3942.144253] [<ffffffff810383fc>] ? need_resched+0x1a/0x23
[ 3942.144355] [<ffffffff8103840a>] ? should_resched+0x5/0x24
[ 3942.144448] [<ffffffff8103840a>] ? should_resched+0x5/0x24
[ 3942.144558] [<ffffffffa103b778>] ? au_plink_put+0x39/0x6b
[aufs]
[ 3942.144667] [<ffffffffa1024834>] ? aufs_kill_sb+0x9b/0x123
[aufs]
[ 3942.144772] [<ffffffff810ed34e>] ? kmem_cache_free+0x2d/0x69
[ 3942.144868] [<ffffffff810fd7ab>] ? deactivate_locked_super
+0x1e/0x48
[ 3942.145000] [<ffffffff81112aff>] ? sys_umount+0x2e5/0x313
[ 3942.145094] [<ffffffff8133bd12>] ? system_call_fastpath
+0x16/0x1b
[ 3942.145193] ---[ end trace b727a8b7ae441974 ]---
Maybe you know the meaning of the above kernel message. I would be
glade if you could help me to avoid the above message.
2. Chroot environment removal and forgotten daemons
Another problem I have is the removal of the on AUFS based chroot
environment. A removal of the chroot environment is only successful
if no process like a daemon has access to one of the under AUFS
mounted
file systems. The problem is the user can't know which daemons or
background processes he triggers if he executes a command in the
chroot
environment.
The executable lshal is an example that shows what happens.
During the
execution of the command lshal, the hal daemon hald and some helper
background processes were started. In this situation a removal
of the
mounted branches and the union will fail.
Umount and its command options can't help, because before I can run
umount successfully I have to kill all processes and daemons
that use
the file systems under AUFS. The problem is how can I detect
processes
like daemons that were started after the check in into the chroot
environment. The command killall or killall5 could be a solution
but
the command killall5 with option -15 goes to far. This command
stops
all processes of the whole system.
Maybe you could give me an advice how to handle such situations.
3. NFS in an on AUFS based chroot environment
Some time ago I read an article about the collaboration of the
network
file system (NFS) and AUFS. The article said that a
collaboration of
both file systems is successful if a special compiled AUFS kernel
module is used. Maybe I understand the statement the wrong way.
Maybe
the author of the article wrote about the following case - the
export
of an AUFS into an NFS. I use the NFS in the chroot environment
that
used AUFS. In that environment I start the NFS server and export
the
wanted directories. The NFS is used locally with an ARM systems
that
runs under the emulator qemu. As NFS server I selected the UNFS3 an
user-space implementation of the NFSv3 server specification. The
choice
falls on the user-space NFS server because the above article
mentioned
the user-space server as alternative to a kernel-space server to
avoid
the compilation of the special AUFS kernel module. I was so
impressed
by the statement of the article that I never had tested the NFS
kernel
server. Now my questions, is the above statement correct? Do I
need the
special kernel module to run the NFS kernel server under AUFS or
is the
statement obsolete?
I would be very glad, if you could find some time to answer my
questions.
Thanks a lot in advanced.
Regards,
Robert Wotzlaw
Attachment:
1. Tape archive email-attachment-04.tar.gz
- All in one file bldchraufs-0.2rc1.aio,
version 0.2rc1, 2012-03-14 12:17:00+01:00
email-attachment-04.tar.gz
Description: GNU Zip compressed data
------------------------------------------------------------------------------ Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/
