Mr. Junjiro R. Okajima,
today I looked again on the last outstanding kernel message and have
found the reason for that message.
1. Kernel messages
The reason for the kernel message is the following shell script:
/usr/lib/pm-utils/power.d/journal-commit
The script is a part of the Debian binary package pm-utils version
1.4.1-8. The script remounts ext3 file systems with the option
commit. It is triggered by a DBUS service. The service is called
during the GNOME Desktop session log in.
The following lines show the code of the script:
#!/bin/sh
. ${PM_FUNCTIONS}
JOURNAL_COMMIT_TIME_AC=${JOURNAL_COMMIT_TIME_AC:-0}
JOURNAL_COMMIT_TIME_BAT=${JOURNAL_COMMIT_TIME_BAT:-600}
help() {
cat <<EOF
Journal commit time parameters:
JOURNAL_COMMIT_TIME_AC = number of seconds between journal commits\
on AC.
Defaults to 0, which sets the filesystem back to its default value.
JOURNAL_COMMIT_TIME_BAT = number of seconds between journal commits\
on battery.
Defaults to 600 (10 minutes).
We currently only handle EXT3 filesystems
EOF
}
# The following shell function command_exists() was included by
# Robert Wotzlaw. The function lives in following shell and is a
# part of the Debian binary package pm-utils version 1.4.1-8:
#
# /usr/lib/pm-utils/functions
#
# The shell function was included to run the script journal-commit
# outside of its environment. The functions is needed by the
# function handle_filesystems().
#
command_exists()
{
# $1 = command to test for. It can be an executable in the path,
# a shell function, or a shell builtin.
type "$1" >/dev/null 2>&1
return $?
}
# actually remount the file system
remount_fs()
{
# $1 = filesystem to remount
# $2 = mount option to change
mount -o remount,$2 $1
}
# invoked on an ext3 file system
handle_ext3()
{
# $1 = filesystem to remount
# $2 = commit time
remount_fs $1 "commit=${2}"
}
handle_ext4() { handle_ext3 "$@"; }
handle_filesystems()
{
# $1 = new journal commit time in seconds
while read DEV MOUNT FSTYPE REST;
do
command_exists "handle_${FSTYPE}" || continue
printf "Setting journal commit time for %s to %d..." \
"$MOUNT" "$1"
"handle_${FSTYPE}" $MOUNT $1 && echo Done. || echo Failed.
done < /proc/mounts
}
case $1 in
true) handle_filesystems $JOURNAL_COMMIT_TIME_BAT ;;
false) handle_filesystems $JOURNAL_COMMIT_TIME_AC ;;
help) help;;
*) exit $NA ;;
esac
exit 0
After I had created the on AUFS based chroot environment. Please
take a look at one of my last letters to learn how I created the
chroot environment. I checked into the chroot environment:
$> sudo chroot /tmp/jail /bin/login
In the new environment the following command line executed the
script journal-commit:
chroot_$> sudo ./journal-commit false > journal-commit_inaufs.log \
2>&1
That produced the following output:
Setting journal commit time for / to 0...mount: / not mounted \
already, or bad option
Failed.
Setting journal commit time for /home to 0...mount: /home not \
mounted already, or bad option
Failed.
Setting journal commit time for /opt to 0...mount: /opt not \
mounted already, or bad option
Failed.
Setting journal commit time for /srv to 0...mount: /srv not \
mounted already, or bad option
Failed.
Setting journal commit time for /tmp to 0...mount: /tmp not \
mounted already, or bad option
Failed.
Setting journal commit time for /usr to 0...mount: /usr not \
mounted already, or bad option
Failed.
Setting journal commit time for /usr/local to 0...mount: /usr/local\
not mounted already, or bad option
Failed.
Setting journal commit time for /var to 0...mount: /var not mounted\
already, or bad option
Failed.
Setting journal commit time for /tmp/jailcache.ro.root \
to 0...mount: mount point /tmp/jailcache.ro.root does not exist
Failed.
Setting journal commit time for /tmp/jailcache.ro.var \
to 0...mount: mount point /tmp/jailcache.ro.var does not exist
Failed.
Setting journal commit time for /tmp/jailcache.ro.usr \
to 0...mount: mount point /tmp/jailcache.ro.usr does not exist
Failed.
Setting journal commit time for /tmp/jailcache.ro.usrlocal \
to 0...mount: mount point /tmp/jailcache.ro.usrlocal does not exist
Failed.
Setting journal commit time for /tmp/jailcache.ro.home \
to 0...mount: mount point /tmp/jailcache.ro.home does not exist
Failed.
Setting journal commit time for /tmp/jailcache.ro.srv \
to 0...mount: mount point /tmp/jailcache.ro.srv does not exist
Failed.
And produced the following well known kernel message. This message
was usually created during the GNOME Desktop session log in:
[11771.764716] aufs au_opts_parse:1039:mount[9011]: unknown option
errors=remount-ro
[11771.771709] aufs au_opts_parse:1039:mount[9013]: unknown option
commit=0
[11771.775236] aufs au_opts_parse:1039:mount[9015]: unknown option
commit=0
[11771.782918] aufs au_opts_parse:1039:mount[9017]: unknown option
commit=0
[11771.796819] aufs au_opts_parse:1039:mount[9018]: unknown option
commit=0
[11771.812259] aufs au_opts_parse:1039:mount[9019]: unknown option
commit=0
The script tries to remount bound etx3 partitions but the origins of
the bound do not exists in the chroot environment. An error is the
consequence.
Running the same script outside of the chroot environment provides
the following output:
$> sudo ./journal-commit false > journal-commit_outaufs.log 2>&1
Setting journal commit time for / to 0...Done.
Setting journal commit time for /home to 0...Done.
Setting journal commit time for /opt to 0...Done.
Setting journal commit time for /srv to 0...Done.
Setting journal commit time for /tmp to 0...Done.
Setting journal commit time for /usr to 0...Done.
Setting journal commit time for /usr/local to 0...Done.
Setting journal commit time for /var to 0...Done.
Setting journal commit time for /tmp/jailcache.ro.root to 0...Done.
Setting journal commit time for /tmp/jailcache.ro.var to 0...Done.
Setting journal commit time for /tmp/jailcache.ro.usr to 0...Done.
Setting journal commit time for /tmp/jailcache.ro.usrlocal\
to 0...Done.
Setting journal commit time for /tmp/jailcache.ro.home to 0...Done.
Setting journal commit time for /tmp/jailcache.ro.srv to 0...Done.
In this case the kernel shows no message.
The question is how can I avoid the above problems with the script
journal-commit:
- Sure, do not use it.
- Convince the developer to rewrite their script.
- Ignore the kernel message and the failed remount.
Desktop user can ignore the failed commit but batterie powered
computer should use a commit because the commit reduce the power
consumption.
Or have you another solution?
Maybe the bind mounts and a chroot environment based on AUFS are
more general problem.
I would be very glad, if you could find some time to answer my
questions. Thanks a lot in advanced.
Regards,
Robert Wotzlaw
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
