[Lxc-users] concurrent aptitude/dpkg runs in separate containers --> bork bork bork

[Trent W. Buck]

I can provision a new LXC container, which includes running a few
"aptitude install foo" lines (inside the containers), and it Just Works.
If I try to provision two containers at the same time, both containers
appear to hang with a dpkg process in the D state[0].

Has anybody run into this before?

I'm invoking aptitude in the post-install hook with triggered when
ISC dhclient acquires a DHCP address.  Where /etc/lxc/$name.setup
contains lines like "aptitude install -yq foo",

    chroot $target_dir tee >/dev/null /root/lxc-setup </etc/lxc/$name.setup
    chroot $target_dir chmod +x /root/lxc-setup
    [...]
    chroot $target_dir tee >/dev/null /etc/dhcp3/dhclient-exit-hooks.d/lxc-postinst <<EOF
    case \$reason in
            BOUND|RENEW|REBIND|REBOOT) :;;
            *) return;;
    esac
    exec >/dev/console 2>&1 </dev/null
    rm -f /etc/dhcp3/dhclient-exit-hooks.d/lxc-postinst # delete self
    if $debug_p
    then ${TERM+export TERM=$TERM} # colour during debug build
         PS4="\`tput setaf 2||:\`\$PS4\`tput sgr0||:\`"
         set -x
    fi
    export DEBIAN_FRONTEND=noninteractive
    export HOME=\`mktemp -d\` # needed for apt->etckeeper->git
    git config --global user.name root
    git config --global user.email root@\`hostname --fqdn\`
    etckeeper commit "Generate new SSL host key."
    # Generate new SSH host keys.
    rm /etc/ssh/ssh_host_???_key*
    dpkg-reconfigure openssh-server
    etckeeper commit "Generate new SSH host keys."
    test -x /root/lxc-setup && /root/lxc-setup
    etckeeper commit "Ran container-specific posthook."
    EOF

I'm using ubuntu 10.04 for both dom0 and containers, with its stock
2.6.32 kernel, and an lxc 0.7.3 from natty.  My config for each
container looks like this:

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: proud.conf
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110112/932b413e/attachment.ksh>
-------------- next part --------------

[0] To make matters worse, attempting to cleanly shut down those
    containers causes them to run /bin/sync, which also hangs in D!
    I've workaround that part by replacing /bin/sync with a link to
    /bin/true in containers, since I see no reason why a container would
    need to run it.