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.

protobuf is needed to build.

makedepends=('cmake' 'make' 'gtest' 'sparsehash' 'help2man' 'protobuf')

@vandelli Waiting for an upstream fix could you please include the patch linked by ktht and bump the package version? Thank you.

Hi, @stqian! I confirm what you reported a week ago. With the latest Manjaro update, curl was upgraded from version 8.19 to 8.20 [1], which caused CVMFS to break for me.

The commit in curl that broke CVMFS is [2] (PR [3]). From what I could understand, the commit changes how curl manages DNS resolver threads. This caused some problems in the curl code (see the PRs linked in the discussion of [3]), which is why threaded resolver was initially disabled in the curl build [4], but it was enabled later [5] with some patches cherry-picked from the curl repository on top [6]. Still, curl 8.20-7 build causes CVMFS to hang indefinitely.

The easiest solution is to just downgrade curl to 8.19, or rebuild curl with --disable-threaded-resolver, or put CVMFS in foreground (cvmfs2 -f ...) instead of running it as a daemon (mount -t cvmfs ...). I confirm that all these options work. However, I don't think that the issue is with curl per se, rather it's on the CVMFS side. I brought this up with CVMFS developers in [7]. In the meantime, you can grab a patch from [8] (md5sum 34562ccbe55d61e19961bf64b0ea6d37) and rebuild CVMFS. It works with the latest curl on my machine. (edit: removed link to an alternative patch)

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