Arch Linux User Repository

@DiV21dSREL I had almost the exact same issue: after the Manjaro update on 29/09/25 I was unable to access /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase, although its parent directory was accessible. After a fair bit of debugging (rebuilding cvmfs with debug symbols; setting CVMFS_HTTP_TRACING=on and specifying CVMFS_DEBUGLOG in /etc/cvmfs/default.local), it finally clicked for me that the offending package must be curl, as it got stuck waiting for the response from cvmfs servers. It also lines up with the fact that curl was upgraded from version 8.15 to 8.16 with the Manjaro update. After downgrading curl to version 8.15 (with sudo manjaro-downgrade curl if you're on Manjaro), I was able to access cvmfs just like before the update.

I also ran git bisect between tags 8.15 and 8.16 in the curl repo to figure out the commit that broke cvmfs. The offending commit happens to be this one, which is part of this PR. Following the discussion there, it seems that the PR introduced a regression in curl, which effectively caused it to run into a deadlock in some scenarios (cf this issue for details). The bug was fixed 2 weeks ago, and the problem is now gone with the current master branch. So we'll just have to wait for the next release of curl.

TLDR: downgrade curl to version 8.15; skip 8.16; wait for version 8.17.

Hi here,

I think I am still hitting the issue that seems to be related to curl. Basically the symptoms are identical: cvmfs-config.cern.ch mounts, directory listings work, but the first open() of a real file under it wedges forever. No TCP connections ever opened, cache size stays flat, no error logged. If I dig deeper, gdb on the cvmfs2 DownloadManager I/O thread shows:

▎ ▎ #4-#6 libcurl.so.4 (internal multi.c)

▎ #7 curl_multi_cleanup

▎ #8 curl_multi_add_handle

▎ #9 download::DownloadManager::MainDownload (cvmfs/network/download.cc:640)

▎ Workaround that fixed it for me: swap curl_multi_add_handle for synchronous curl_easy_perform in MainDownload. I documented these here.

I am on Omarchy, not sure if it is just me hitting this?

@hcartiaux thanks for your proposal and apologies for the late answer. I have had a busy period ... I will have a look and come back to you. Feel free to get in touch by email (see PKGBUILD file) if you want a more direct discussion.

Hi there,

It would be great to split cvmfs from its default configuration like its done for the RHEL packages, see my updated PKGBUILD here: https://gitlab.archlinux.org/hcartiaux/cvmfs

Especially:

• the package is split into the client cvmfs and its config cvmfs-config-default
• CVMFS_CONFIG_REPOSITORY cannot be used in conjuction with autofs, so I'd rather not have it set by default in the configuration, especially since I want to use cvmfs-config-eessi
• the gentoo patch is imported to compile against system libraries instead of the bundled libs

Feedback welcome ;)

@hcartiaux thanks for the suggestion, makes sense. I can add it for the next update

@vandelli I think it makes sense to add autofs to the optdepends array (but I've not tried yet, autofs does not build right now probably due to a recent upstream change).

@gdevenyi Thanks for the heads up and prompt follow. It should be possible to fetch the patch from the github pull request and apply it in the PKGBUILD. I will look into this ASAP

Following up about the make -j1 bug, I reported it upstream and its now patched, you may want to cherry pick the fix since the next release might be a while.

https://github.com/cvmfs/cvmfs/issues/4070

Hello.

On my system the CVMFS build has a race condition where help2man fails during build.

If I swap make for make -j1 then the serial build succeeds. I know this is likely an upstream issue, but in the meantime can you please update the PKGBUILD for this. Thanks.

@ktht Thanks for the extensive debugging, that's super helpful and I've made your post sticky for the time being until curl is updated.

@DiV21dSREL I had almost the exact same issue: after the Manjaro update on 29/09/25 I was unable to access /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase, although its parent directory was accessible. After a fair bit of debugging (rebuilding cvmfs with debug symbols; setting CVMFS_HTTP_TRACING=on and specifying CVMFS_DEBUGLOG in /etc/cvmfs/default.local), it finally clicked for me that the offending package must be curl, as it got stuck waiting for the response from cvmfs servers. It also lines up with the fact that curl was upgraded from version 8.15 to 8.16 with the Manjaro update. After downgrading curl to version 8.15 (with sudo manjaro-downgrade curl if you're on Manjaro), I was able to access cvmfs just like before the update.

I also ran git bisect between tags 8.15 and 8.16 in the curl repo to figure out the commit that broke cvmfs. The offending commit happens to be this one, which is part of this PR. Following the discussion there, it seems that the PR introduced a regression in curl, which effectively caused it to run into a deadlock in some scenarios (cf this issue for details). The bug was fixed 2 weeks ago, and the problem is now gone with the current master branch. So we'll just have to wait for the next release of curl.

TLDR: downgrade curl to version 8.15; skip 8.16; wait for version 8.17.