使用 rpm -qa –last 命令可查看基于rpm的linux系统中所有已安装软件包的安装日期，1. 该命令会列出所有rpm包并按安装时间倒序排列，最新安装的显示在最上方；2. 每个条目包含软件包名、版本、架构及具体安装时间；3. 对于排查近期系统变更或问题定位非常有用。对于非rpm系如debian/ubuntu，1. 可通过查看apt历史日志（/var/log/apt/history.log）获取安装记录；2. 也可检查dpkg日志（/var/log/dpkg.log）过滤出安装操作。手动安装的软件无统一追踪方式，1. 可尝试查看文件创建或修改时间；2. 查阅编译安装日志或源码目录时间戳；3. 最佳实践是保留详细安装文档作为参考。使用包管理器查看安装日期时需注意：1. 显示的是最后一次安装或升级时间而非初始安装时间；2. 系统时间错误会影响记录准确性；3. 日志轮转可能导致旧记录丢失；4. 手动安装软件不在包管理器中记录；5. 注意日志与时区设置可能带来的混淆。
使用 rpm -qa –last 命令可以方便地查看linux系统上所有已安装RPM软件包的安装日期，它会按时间倒序排列，最新安装的软件包会显示在最上面，这对于快速定位近期系统变更或排查问题非常有帮助。
解决方案
在Linux环境中，如果你使用的是基于RPM的发行版（比如red Hat Enterprise Linux, centos, Fedora, openSUSE等），那么查看软件包安装日期的最直接、最有效的方法就是利用 rpm 命令的 –last 选项。
简单来说，你只需要在终端输入：
rpm -qa --last
执行这个命令后，系统会列出所有已安装的RPM软件包，并且非常贴心地按照它们的安装时间（从最新到最旧）进行排序。每一行都会显示软件包的完整名称（包括版本和架构）以及其安装的具体日期和时间。
例如，你可能会看到类似这样的输出：
systemd-udev-239-64.el8_6.1.x86_64 Tue 01 Nov 2023 10:30:05 AM CST kernel-4.18.0-372.26.1.el8_6.x86_64 Tue 01 Nov 2023 10:28:40 AM CST bash-4.4.20-4.el8_5.x86_64 Mon 31 Oct 2023 09:15:22 PM CST ...
从这些信息中，你可以清晰地了解到每个软件包是什么时候被安装或更新到当前版本的。这在很多场景下都非常有用，比如当你怀疑某个系统问题是最近的更新导致的，或者需要审计系统的变更历史时。我个人在排查一些莫名其妙的系统行为时，经常会先用这个命令扫一眼，看看最近有没有什么“大动作”，很多时候都能找到线索。
非RPM系Linux发行版如何查看软件包安装日期？
当然，Linux世界并非只有RPM一种包管理方式。如果你使用的是Debian、Ubuntu、Linux Mint等基于DEB包的发行版，rpm -qa –last 命令自然是无效的。那么，这些系统如何查看软件包的安装日期呢？
其实，Debian/Ubuntu系的包管理器 dpkg 本身并没有一个直接像 rpm –last 这样能显示安装日期的选项。它们更依赖于系统日志来追踪这些信息。最常用的方法是查看 apt 或 dpkg 的历史日志文件。
-
查看APT历史日志：apt（Advanced Package Tool）在执行安装、升级、删除等操作时，都会在 /var/log/apt/history.log 文件中留下详细的记录。这个文件会记录每次操作的开始时间、结束时间、执行的用户以及安装/删除的软件包列表。
你可以使用 cat 或 less 命令来查看这个文件：
cat /var/log/apt/history.log
或者，如果你想快速查找某个特定软件包的安装记录，可以结合 grep：
grep -E "Install:|Upgrade:" /var/log/apt/history.log | grep <package_name>
例如，要查找 nginx 的安装记录：
grep -E "Install:|Upgrade:" /var/log/apt/history.log | grep nginx
你会看到类似这样的输出：
Start-Date: 2023-10-25 14:30:01 Commandline: apt install nginx Install: nginx:amd64 (1.18.0-6ubuntu14.4) End-Date: 2023-10-25 14:30:08
这提供了非常精确的安装时间。
-
查看dpkg日志： 更底层的 dpkg 工具也会记录所有包操作。它的日志文件通常是 /var/log/dpkg.log。这个日志文件会记录每个软件包的安装、配置、卸载等操作。
grep " install " /var/log/dpkg.log
同样，你可以通过 grep 过滤出你关心的软件包：
grep " install " /var/log/dpkg.log | grep
输出会是这样的：
2023-10-25 14:30:05 startup packages configure 2023-10-25 14:30:05 install nginx:amd64 <none> 1.18.0-6ubuntu14.4
虽然这些方法不像 rpm –last 那样直接列出所有包的安装日期，但通过日志文件，我们依然能够回溯到软件包的安装历史。在我看来，日志文件提供了更细粒度的操作记录，不仅仅是安装日期，还有整个操作的上下文。
手动编译或非包管理器安装的软件如何追踪？
这是一个更棘手的问题，因为包管理器（无论是RPM还是DEB）的强大之处在于它们维护了一个统一的数据库来管理系统上的软件。一旦你绕过了它们，直接进行手动编译安装（比如 make && make install）或者从源代码安装，那么就没有一个中央的数据库来记录这些软件的安装日期了。
在这种情况下，追踪软件的“安装日期”就变得有些模糊和困难，因为它没有一个明确的定义。我们能做的，更多是去猜测或者寻找一些间接的线索：
-
文件创建/修改时间： 这是最常见的间接方法。当你手动安装一个软件时，通常会把它的可执行文件、库文件、配置文件等复制到 /usr/local/bin、/usr/local/lib、/etc 等目录。你可以尝试查看这些文件的创建时间（ctime，inode change time）或最后修改时间（mtime）。
ls -l --time=ctime /usr/local/bin/<executable_name>
或者使用 stat 命令获取更详细的文件时间戳信息：
stat /usr/local/bin/<executable_name>
但要注意，这些时间戳可能会因为文件被修改、备份恢复或系统时间调整而发生变化，所以它们不总是可靠的“安装日期”。
-
查看编译/安装日志： 如果你在编译安装时有习惯将编译输出或安装过程的日志重定向到文件，那么这些日志文件本身的时间戳或内部记录的时间信息，就能提供非常有价值的线索。很多时候，项目会自带一个 install.log 或者你手动创建的日志文件。
-
源代码目录： 如果你保留了编译时的源代码目录，那么这个目录的最后修改时间或者其内部文件的修改时间，也可以作为大致的参考。
-
个人记录/文档： 这是最可靠但往往被忽视的方法。对于重要的、非包管理器安装的软件，最好的做法是自己做好记录，包括安装时间、版本、安装路径、编译选项等。我自己的经验是，如果一个服务不是通过包管理安装的，一旦出了问题，回溯起来简直是噩梦，所以一个详细的安装文档是无价之宝。
总之，对于手动安装的软件，没有“一劳永逸”的查看安装日期的方法。这更像是一场侦探游戏，需要你根据各种线索进行推断。
查看软件包安装日期时常见的误区与局限性
尽管 rpm -qa –last 和日志文件提供了查看软件包安装日期的有效途径，但在实际使用中，我们还是会遇到一些误区和局限性，理解这些能帮助我们更准确地解读信息。
-
“安装日期”的定义：rpm -qa –last 显示的是软件包最后一次被安装或升级的日期。这意味着如果一个软件包被升级了，它显示的日期是升级的日期，而不是它最初被安装到系统上的日期。对于Debian/Ubuntu系的日志，你可能需要仔细区分 Install: 和 Upgrade: 记录。如果你想知道某个软件包最初是什么时候进入系统的，这可能需要更深入地挖掘历史日志，甚至可能无法追溯到。
-
系统时间的影响： 软件包的安装日期是基于系统当时的日期和时间记录的。如果系统在安装某个软件包时，其时间设置是错误的（比如跳回了过去或跳到了未来），那么记录下来的安装日期也会是错误的。这在一些不常同步NTP的虚拟机或嵌入式设备上尤其常见。
-
日志轮转与删除：/var/log/apt/history.log 和 /var/log/dpkg.log 等日志文件会受到日志轮转（logrotate）策略的影响。为了避免日志文件过大，系统会定期对它们进行压缩、归档或删除。这意味着你可能无法查看到非常久远以前的安装记录，因为相关的日志文件可能已经被清理掉了。
-
非包管理器安装的盲区： 正如前面提到的，所有包管理器的方法都只适用于通过它们自身安装的软件包。对于手动编译安装、通过脚本直接复制的可执行文件，或者从其他非官方渠道直接部署的软件，包管理器是完全无感的，它们不会出现在 rpm -qa 或 dpkg -l 的列表中，更不会有安装日期记录。
-
时区问题： 显示的日期和时间通常是系统本地时区的时间。但在跨时区协作或分析日志时，需要注意日志记录的时间可能基于UTC，而显示出来的时间又根据本地时区转换过，这可能会造成一些混淆。确保你理解当前系统的时间设置和日志记录的时区，有助于避免误判。
理解这些局限性，能让我们在分析软件包安装日期时，做出更准确的判断，避免被表面信息所迷惑。很多时候，技术问题没有银弹，需要结合多方面的信息去综合判断。
