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

[Trent W. Buck]

Daniel Lezcano <daniel.lezcano at free.fr> writes:

> On 01/12/2011 07:39 AM, Trent W. Buck wrote:
>> Mike<debian at good-with-numbers.com>  writes:
>>
>>>> Trent W. Buck wrote:
>>>>> 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].
>>>>>
>>>>> My config for each container looks like this:
>>>>> lxc.mount.entry  = /home       /srv/lxc/proud/home       none bind
>>> Doesn't aptitude write into the home directory that you're sharing
>>> across containers? locks ~/.aptitude/cache?
>> Possibly, but dhclient's running aptitude as uid 0, whose home is in
>> /root, which is not shared between hosts.
>>
>> In any case, IIRC I export HOME=`mktemp -d` before aptitude runs, as a
>> fugly workaround for etckeeper.
>>
>> I suppose if containers' /tmp are tmpfses, aptitude might be running
>> into some problem with locking on tmpfs, although I'm not aware of any
>> bogus operational semantics for tmpfs...
>
> Can you give, for each process in D state, the content of 
> /proc/<pid>/stack ?
> That may help to understand where the lock occurs in the kernel

I'll try to get to this RSN; the box in question is in production, so I
have to be a little careful.