这是 Duply 输出的一部分，在 20.04 系统上运行。

 19 |Start duply v2.2, time is 2022-03-31 03:24:01.
 20 |Using profile '/etc/duply/system'.
 21 |Using installed duplicity version 0.8.12, python 3.8.10 (/usr/bin/python3), gpg 
     2.2.19 (Home: /root/.gnupg), awk 'GNU Awk 5.0.1, API: 2.0 (GNU MPFR 4.0.2, G
     NU MP 6.2.0)', grep 'grep (GNU grep) 3.4', bash '5.0.17(1)-relea
     se (x86_64-pc-linux-gnu)'.
 22 |Autoset found secret key of first GPG_KEY entry '6DC41962' for signing.
 23 |Checking TEMP_DIR '/tmp' is a folder and writable (OK)
 24 |Test - Encrypt to '6DC41962' & Sign with '6DC41962' (OK)
 25 |Test - Decrypt (OK)
 26 |Test - Compare (OK)
 27 |Cleanup - Delete '/tmp/duply.2031592.1648697042_*'(OK)
 29 |--- Start running command BKP at 03:24:02.958 ---
 30 |Reading globbing filelist /etc/duply/system/exclude
 31 |Synchronizing remote metadata to local cache...
 32 |Deleting local /root/.cache/duplicity/duply_system/duplicity-full-signatures.202
     20322T032402Z.sigtar.gpg (not authoritative at backend).
 33 |Last full backup left a partial set, restarting.
 34 |Last full backup date: Tue Mar 22 03:24:02 2022
 35 |Reuse configured PASSPHRASE as SIGN_PASSPHRASE
 36 |RESTART: Volumes 1060 to 1060 failed to upload before termination.
 37 |         Restarting backup at volume 1060.
 38 |Restarting after volume 1059, file var/lib/autopostgresqlbackup/weekly/REDACTE
     D/redacted_week.11.2022-03-19_06h25m.sql.gz, block 298
 39 |Attempt 1 failed. BrokenPipeError: Broken pipe
 40 |Attempt 2 failed. BrokenPipeError: Broken pipe
 41 |Attempt 3 failed. BrokenPipeError: Broken pipe
 42 |Attempt 4 failed. BrokenPipeError: Broken pipe
 43 |Giving up after 5 attempts. BrokenPipeError: Broken pipe
 44 |04:57:25.120 Task 'BKP' failed with exit code '50'.
 45 |--- Finished state FAILED 'code 50' at 04:57:25.120 - Runtime 01:33:22.1
     61 ---

这已经连续几天发生了。

我看过那个.sql.gz文件，看起来还不错。file命令说这正是我所期望的（gzip'd 文本），......我在想文件或文件系统可能在那个“块 298”上已损坏。

退出代码“50”代表什么？
来自正在写入后端的管道的 BrokenPipeError 是……还是……？
对此有什么想法吗？

4 月 6 日更新

后端“目标”是一个s3+http://URL。这是一个运行生产服务的 Linode 系统；网络连接良好（或者我预计会有其他问题，以及监控警报等）

正如答案中所建议的，我试图强制进行清理。Duplicity尽职尽责地做到了。然后我开始另一个备份...输出略有不同，但管道仍然损坏...

 19 |Start duply v2.2, time is 2022-04-06 03:24:01.
 20 |Using profile '/etc/duply/system'.
 21 |Using installed duplicity version 0.8.12, python 3.8.10 (/usr/bin/python3), gpg 
     2.2.19 (Home: /root/.gnupg), awk 'GNU Awk 5.0.1, API: 2.0 (GNU MPFR 4.0.2, G
     NU MP 6.2.0)', grep 'grep (GNU grep) 3.4', bash '5.0.17(1)-relea
     se (x86_64-pc-linux-gnu)'.
 22 |Autoset found secret key of first GPG_KEY entry '6DC41962' for signing.
 23 |Checking TEMP_DIR '/tmp' is a folder and writable (OK)
 24 |Test - Encrypt to '6DC41962' & Sign with '6DC41962' (OK)
 25 |Test - Decrypt (OK)
 26 |Test - Compare (OK)
 27 |Cleanup - Delete '/tmp/duply.761614.1649215441_*'(OK)
 29 |--- Start running command BKP at 03:24:02.723 ---
 30 |Reading globbing filelist /etc/duply/system/exclude
 31 |Local and Remote metadata are synchronized, no sync needed.
 32 |Last full backup date: Sat Feb 19 03:24:03 2022
 33 |Last full backup is too old, forcing full backup
 34 |Reuse configured PASSPHRASE as SIGN_PASSPHRASE
 35 |Attempt 1 failed. BrokenPipeError: Broken pipe
 36 |Attempt 2 failed. BrokenPipeError: Broken pipe
 37 |Attempt 3 failed. BrokenPipeError: Broken pipe
 38 |Attempt 4 failed. BrokenPipeError: Broken pipe
 39 |Giving up after 5 attempts. BrokenPipeError: Broken pipe
 40 |16:21:20.829 Task 'BKP' failed with exit code '50'.
 41 |--- Finished state FAILED 'code 50' at 16:21:20.829 - Runtime 12:57:18.1
     06 ---

当它得到 BrokenPipeError 时，我如何弄清楚它在做什么？

我有一个运行 openssl 以在本地检查证书有效性的 perl 脚本。我不想只是设置一个环境变量然后走开。这感觉更像是我的 openssl 安装或配置很有趣

系统是什么，版本...

我正在本地验证来自 Letsencrypt 的证书。这是一个 20.04/Focal 系统。Openssl 是OpenSSL 1.1.1f 31 Mar 2020，所以我希望它能够愉快地验证证书，即使 LE 使用新的 ISRG 根证书“交叉签名”它们。

然而，一旦旧的 X3 证书过期，这些错误就开始了……

openssl verify -verbose -purpose sslserver -CAfile /path/redacted/chain.pem /path/redacted/cert.pem
C = US, O = Internet Security Research Group, CN = ISRG Root X1. 
error 2 at 2 depth lookup: unable to get issuer certificate. 
error /path/redacted/cert.pem: verification failed

这感觉很奇怪。一些挖掘使我想-trusted_first知道openssl verify. 如果未启用trusted-first 选项，这正是openssl会抱怨的。但是，尝试显式启用该选项没有任何影响：

openssl verify -trusted_first -verbose -purpose sslserver -CAfile /path/redacted/chain.pem /path/redacted/cert.pem
C = US, O = Internet Security Research Group, CN = ISRG Root X1
error 2 at 2 depth lookup: unable to get issuer certificate
error /path/redacted/cert.pem: verification failed

好的。自 openssl 1.1.1 以来，该选项应默认启用（即该系统，见上文）。所以我明确包括它应该没有什么区别。

但最终我尝试将其指定为环境变量。等等，哇？为什么指定此环境变量会修复 openssl 的行为以信任它在链中找到的第一个根证书：

set X509_V_FLAG_TRUSTED_FIRST openssl verify -trusted_first -verbose -purpose sslserver -CAfile /path/redacted/chain.pem /path/redacted/cert.pem

…以退出值为零运行。

缩小

我不明白为什么 openssl 不能正常工作（tm）。这是一个完全更新的 20.04。较新的 ISRG 根证书已安装/etc/ssl/certs/ISRG_Root_X1.pem并且update-ca-certificates很高兴：

Updating certificates in /etc/ssl/certs...
0 added, 0 removed; done.
Running hooks in /etc/ca-certificates/update.d...
done.

是否有 PerlApache::Log::Parser模块的 apt-get 包？