[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAASffotazEgv9gxCjeC+sh8E2bWZE2ZZhQnqypaEnwJc_5w6hw@mail.gmail.com>
Date: Thu, 10 Jul 2025 14:58:30 +1000
From: Stephen Von Takach <steve@...ce.technology>
To: Rich Felker <dalias@...c.org>
Cc: musl@...ts.openwall.com, Viv Briffa <viv@...ce.technology>
Subject: Re: unlink on NFS volume fails silently
Yeah I see your point and this was closed as a kernel issue:
https://gitlab.alpinelinux.org/alpine/aports/-/issues/10960
We're running these two containers on the same kernel and seeing the same
behaviour as that alpine issue.
Happy to continue working around the issue by using debian userspace to
build our service.
It does seems crazy that there is clearly an issue, possibly a kernel issue
that is being handwaved away by all parties
Stephen von Takach Dukai
Engineering Lead
PlaceOS
Australia, Hong Kong, London, New York
p: +61 408 419 954
e: steve@...ce.technology
On Thu, 10 Jul 2025 at 10:03, Rich Felker <dalias@...c.org> wrote:
> On Thu, Jul 10, 2025 at 09:01:57AM +1000, Stephen Von Takach wrote:
> > We're using docker containers running on the same kernel using the same
> > mount setup.
> > Works on debian, does not work on alpine.
> >
> > The difference is at the libc interface.
>
> Unless I'm missing something, musl and glibc are doing exactly the
> same thing here. There is no userspace code for unlink; it's just a
> syscall. You can compare the glibc code at:
>
>
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/unlink.c;hb=glibc-2.41
>
> with the musl code at:
>
> https://git.musl-libc.org/cgit/musl/tree/src/unistd/unlink.c?id=v1.2.5
>
> If you're seeing different behavior, something else is the cause. It's
> almost surely what I said, a timing-dependent NFS bug.
>
> Rich
>
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
