On Sun, 9 Jun 2019 at 19:01, <[1]sf...@users.sourceforge.net> wrote:
Kirill Kolyshkin:
> During my weeks of extensive stress testing of aufs I noticed this
bug
> happened twice on one of the servers:
>
> May 31 20:05:42 kirtest dockerd[3912]:
> time="2019-05-31T20:05:42.686603244Z" level=warning msg="auplink
flush
> failed: auplink:plink.c:158: proc: No such file or directory\n"
error="exit
> status 2" method=Unmount storage-driver=aufs
A A A A :::
> I took a look at the source code, and it seems that auplink binary
fails to
> open /proc/fs/aufs/plink_maint file for writing. I do not
understand why
> this could ever happen.
As you might know, the lifetime of /proc/fs/aufs/plink_maint is
equivalent to aufs module's.A Unless you unload aufs module, it
must
exists.
That was my first idea -- that I was replacing aufs module during this
time.
But systems logs shows no trace of that.
A
So I am afraid you hit another bug of procfs', and aufs has
nothing to do essentially.A cgroup and namespace may be related to
procfs since docker uses them.A But I am not a docker user and know
few
things about that.
I am pretty sure dockerd runs "auplink flush" on the host, with the
host cgroup and
initial namespaces.
A
There may exist a similar workaround as well as the previous problem
of
/proc/mounts, ie. try opening /proc/fs/aufs/plink_maint twice or
more.
Obviously it is not a good solution, and I don't like it.
Do you think that such workaround is helpful?
I'm not sure either. For /proc/mounts, we are pretty sure now that this
happens,
and thus the workaround is legitimate. In this very case, I have
absolutely no
idea why this could ever happen, and it looks like you don't have it
either.
Any pointers about how to debug it?
Regards,
A Kir
References
1. mailto:sf...@users.sourceforge.net
