在极少数情况下，运行 yum update 后，会安装一个或多个包含 0 大小文件的软件包，并且在重新安装受影响的软件包后问题会得到解决。
我本来相信外部因素，但时间戳始终与已安装的软件包相同。
我使用的是 Oracle Linux 7.9
uname -r
5.4.17-2102.200.13.el7uek.x86_64
rpm -q rpm --last
rpm-4.11.3-48.el7_9.x86_64 Sun 05 Jun 2022 05:07:48 AM UTC
rpm -q yum --last
yum-3.4.3-168.0.3.el7.noarch Fri 21 May 2021 02:23:50 PM UTC
例如。：
# showing the last transaction
rpm -q gzip --last
gzip-1.5-11.el7_9.x86_64 Sat 13 Aug 2022 05:30:27 AM UTC
# showing information for the file size and timestamp
stat /usr/bin/gzip
File: ‘/usr/bin/gzip’
Size: 0 Blocks: 0 IO Block: 4096 regular empty file
Device: fd01h/64769d Inode: 50463530 Links: 1
Access: (0755/-rwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2022-08-17 07:18:10.066983772 +0000
Modify: 2022-05-11 17:23:29.000000000 +0000
Change: 2022-08-13 05:30:27.680595054 +0000
Birth: -
# validating package integrity shows that size and the MD5 sum differs from rpmdb.
rpm -V gzip
S.5...... /usr/bin/gunzip
S.5...... /usr/bin/gzexe
S.5...... /usr/bin/gzip
S.5...... /usr/bin/zcat
S.5...... /usr/bin/zcmp
S.5...... /usr/bin/zdiff
S.5...... /usr/bin/zegrep
S.5...... /usr/bin/zfgrep
S.5...... /usr/bin/zforce
S.5...... /usr/bin/zgrep
S.5...... /usr/bin/zless
S.5...... /usr/bin/zmore
S.5...... /usr/bin/znew
S.5...... d /usr/share/doc/gzip-1.5/AUTHORS
S.5...... d /usr/share/doc/gzip-1.5/ChangeLog
S.5...... d /usr/share/doc/gzip-1.5/NEWS
S.5...... d /usr/share/doc/gzip-1.5/README
S.5...... d /usr/share/doc/gzip-1.5/THANKS
S.5...... d /usr/share/doc/gzip-1.5/TODO
S.5...... d /usr/share/info/gzip.info.gz
S.5...... d /usr/share/man/man1/gunzip.1.gz
S.5...... d /usr/share/man/man1/gzexe.1.gz
S.5...... d /usr/share/man/man1/gzip.1.gz
S.5...... d /usr/share/man/man1/zcat.1.gz
S.5...... d /usr/share/man/man1/zcmp.1.gz
S.5...... d /usr/share/man/man1/zdiff.1.gz
S.5...... d /usr/share/man/man1/zforce.1.gz
S.5...... d /usr/share/man/man1/zgrep.1.gz
S.5...... d /usr/share/man/man1/zless.1.gz
S.5...... d /usr/share/man/man1/zmore.1.gz
S.5...... d /usr/share/man/man1/znew.1.gz
这是 yum 更新日志，我已经编辑了其他软件包：
Loaded plugins: fastestmirror, product-id, search-disabled-repos, subscription-
: manager
Loading mirror speeds from cached hostfile
foreman-private-oracle-latest | 2.1 kB 00:00
Resolving Dependencies
--> Running transaction check
---> Package gzip.x86_64 0:1.5-10.el7 will be updated
---> Package gzip.x86_64 0:1.5-11.el7_9 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
================================================================================
Package Arch Version Repository Size
================================================================================
Updating:
gzip x86_64 1.5-11.el7_9 foreman-private-oracle-latest 129 k
Transaction Summary
================================================================================
Upgrade 132 Packages
Total download size: 305 M
Downloading packages:
No Presto metadata available for foreman-private-oracle-latest
(37/132): gzip-1.5-11.el7_9.x86_64.rpm | 129 kB 00:00
--------------------------------------------------------------------------------
Total 24 MB/s | 305 MB 00:12
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Updating : gzip-1.5-11.el7_9.x86_64 36/264
Cleanup : gzip-1.5-10.el7.x86_64 227/264
Verifying : gzip-1.5-11.el7_9.x86_64 65/264
Verifying : gzip-1.5-10.el7.x86_64 157/264
Updated:
gzip.x86_64 0:1.5-11.el7_9
答案1
发现了问题，所以我正在回答我自己的问题。
重新启动之前运行“同步”。
事实证明，Oracle Linux 7.9 无法与 AWS API 重新启动良好配合。我使用的更新程序工具执行了两个步骤：yum 更新和从 AWS API 重新启动。这样做时，内核没有时间将内存中缓冲的所有数据同步到磁盘，因此新创建的文件要么根本没有保存，要么大小为 0，其中没有内容。
仅当从 AWS API 执行重新启动过程时才会出现此问题，因为使用操作系统重新启动命令不会重现该问题。