Linux内核3.8.0服务器git-lfs pull停滞在0%的问题求助

API 探路者

2026-7-2

可能的原因及验证方向

老旧内核的TLS兼容性缺陷
Linux 3.8.0内核发布于2013年，配套的系统加密库（如OpenSSL）版本通常较低，可能不支持Git LFS默认使用的TLS 1.2+协议版本。普通git pull走Git仓库元数据通道，可能兼容旧TLS版本或使用SSH协议，而Git LFS的对象下载请求强制要求高版本TLS，导致握手失败后静默阻塞。
验证：用git lfs env获取LFS对象存储地址，执行curl -v <LFS对象URL>查看是否出现TLS握手错误。
内核网络栈并发连接Bug
3.8.0内核的TCP/IP栈存在已知的并发连接处理缺陷，Git LFS默认会同时发起多个对象下载请求，老旧内核无法处理这种并发连接，导致连接死锁或停滞。
验证：执行git config lfs.concurrenttransfers 1将并发数改为1，再重新执行git lfs pull。
系统依赖库版本不兼容
Git LFS运行依赖libcurl、glibc等系统库，老旧服务器的这些库版本过旧，无法适配Git LFS的底层网络请求逻辑，导致请求发起后无响应。即使更换多个Git LFS版本，也无法绕过系统库的限制。
验证：执行ldd $(which git-lfs)查看依赖库版本，对比本地正常环境的库版本差异。
LFS存储端点的兼容性限制
若仓库的LFS对象存储在第三方云服务（如S3、GitLab LFS），这些服务可能已停止对旧TLS版本或旧客户端的支持。普通git pull连接的是Git服务器，与LFS存储端点是不同的服务，因此不受影响，但LFS对象下载会被拦截。
验证：尝试将LFS对象手动下载到服务器（如用wget测试），看是否能正常获取。
磁盘IO或文件系统阻塞
普通git pull仅下载小体积的元数据文件，而Git LFS需下载大体积对象文件。老旧服务器的磁盘可能存在IO瓶颈，或使用的文件系统（如ext3）存在大文件写入Bug，导致下载后的写入操作阻塞，表现为下载进度停滞。
验证：执行git lfs pull --verbose查看详细日志，确认是卡在下载阶段还是写入阶段；同时用iostat监控磁盘IO状态。