我如何发现Linux系统已安装多久了?


97

如果没有人试图隐藏Linux系统,我如何才能找到它的时间?


您的年龄是什么意思?
Let_Me_Be

@让:自成立以来的时间。

1
@让:我期待着“检查/ some / oscure /文件的时间戳,它永远不会被修改”的答案。请回答。

2
这是否有点像问[Theusus的飞船]的年龄(en.wikipedia.org/wiki/Ship_of_Theseus)?
东武

2
多年来,Linux安装的每个部分都被替换了吗,它仍然是相同的安装吗?(这与一艘船的所有零件都缓慢更换的原始比喻类似)我问,因为我的根分区已更改了磁盘和文件系统,而我的主分区早于此。有些设备曾经准备为黄金映像,然后在部署时获得自定义主机名,ssh主机密钥和fs uuid。黄金图像可以被修改并再次冻结,例如交钥匙的Linux血统。
东武

Answers:


99
tune2fs -l /dev/sda1 **OR** /dev/sdb1*  | grep 'Filesystem created:'

这将告诉您何时创建文件系统。

* =在第一列中df /可以找到要使用的确切分区。


4
通常/dev/sda1或类似的内容(无论df /第一列中显示什么),但原理是合理的。
吉尔斯

1
嘿,这很容易知道,谢谢。并且此信息也可以复制文件系统。+1。
Faheem Mitha

4
该解决方案很好,但是依赖于文件系统,并且需要root特权。
golem

7
+1。但是,我必须指出,我当前的桌面是在1994年左右创建的。从那时起,关于它的所有内容绝对发生了多次更改(包括磁盘和我使用的文件系统类型),但它仍然是同一系统。这种方法充其量只能告诉我最近转移到新文件系统的日期。
cas

这不应该是公认的答案,因为它仅适用于我不使用的ext2(可能高达ext4?)。
soger,2017年

23

使用dumpe2fs检查根文件系统的日期。除了您要查找的日期外,我真的想不出什么:

dumpe2fs $(mount | grep 'on \/ ' | awk '{print $1}') | grep 'Filesystem created:'

1
...或tune2fs -l
forcefsck

2
您忘了提到这仅适用于ext2 / ext3 / ext4文件系统。
Let_Me_Be 2011年

您会在我的几台机器上输入错误的日期,在这些机器上我已经升级了硬盘驱动器,并且只是将安装复制过来。
derobert

1
@derobert,鉴于操作人员的问题,我仍然认为我的答案是正确的。新磁盘与新RAM没有什么不同-即使您在以下位置弹出了新磁盘,您仍然具有相同的“安装”
权限

@pboin不,当我复制安装时,它的磁盘更大,因此我重新分区并进行mkfs(然后使用tar / cp复制它,而不是dd)。甚至可能是一个不同的文件系统(例如ext2-> ext3-> ext4),这样您就可以得到我复制安装的时间了。这就是OP寻找日期之外的方式。
derobert

16

有一些约会。

  • 所有文件都有日期。
  • 日志文件中包含日期。

在Debian或Ubuntu及其衍生产品上,请查看/var/log/installer/syslog是否存在明确的答案(如果存在),它是灌输日志的一部分。

但是请注意,这不能保证。(由于某些原因可能无法正常工作,请参阅其他答案/评论。)


不过,这可能特定于Debian / Ubuntu。
Faheem Mitha

@Faheem Mitha:Ubuntu使用相同的文件/目录。
BillThor

1
@Bill:是的,我说的是针对Debian / Ubuntu的。这意味着该食谱对Debian和Ubuntu均适用,但可能不适用于其他(非基于Debian的)Linux发行版。
Faheem Mitha

但是,并非所有文件都有创建日期。AFAIK的出生日期仅在ext4中引入,无论如何不是POSIX。
Konrad Gajewski 2015年

@KonradGajewski但是这个答案,或者它的任何评论都提到了文件创建日期。
ctrl-alt-delor

12

在基于Red Hat的发行版(例如CentOS,Scientific,Oracle等)上,您可以使用:

rpm -qi basesystem
Name        : basesystem
Version     : 10.0
Release     : 7.el7
Architecture: noarch
Install Date: Mon 02 May 2016 19:20:58 BST
Group       : System Environment/Base
Size        : 0
License     : Public Domain
Signature   : RSA/SHA256, Tue 01 Apr 2014 14:23:16 BST, Key ID     199e2f91fd431d51
Source RPM  : basesystem-10.0-7.el7.src.rpm
Build Date  : Fri 27 Dec 2013 17:22:15 GMT
Build Host  : ppc-015.build.eng.bos.redhat.com
Relocations : (not relocatable)
Packager    : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla>
Vendor      : Red Hat, Inc.
Summary     : The skeleton package which defines a simple Red Hat Enterprise Linux system
Description :
Basesystem defines the components of a basic Red Hat Enterprise Linux
system (for example, the package installation order to use during
bootstrapping). Basesystem should be in every installation of a system,
and it should never be removed.

要么

rpm -q basesystem --qf '%{installtime:date}\n'
Mon 02 May 2016 19:20:58 BST

1
为什么rpm -qi给我Install Date: Mon 07 Jul 2014 03:20:44 PM UTC,而tune2fsFilesystem created: Sat Dec 20 23:41:41 2014
本杰明

在我的Azure的VM上所有时间都相同,因此rpm根本不可靠
Chris

10

对文件系统和分发(我可以提出)最不中性的解决方案是使用给出的最旧的文件ls -lact /etc,该文件在创建时会查看每个文件的元数据。虽然可以玩游戏,但它不受touch提取档案文件的影响或创建的文件(例如tar -p,保存时间戳记)。

我认为最好查看文件而不是目录,因为目录的内容更改时,目录的确会更改其创建时间元数据(也许有人可以弄清楚为什么会这样?)

ls -lact --full-time /etc |tail

缺少GNU Coreutils的系统应删除该--full-time选项(排序顺序仍然正确,您仍然可以使用)。您可以使用从文件的元数据中获取创建时间stat FILE |grep Change(在列出的最旧文件上运行ls -lact)。

在其他非Linux系统上,stat该信息的排列可能略有不同,可能需要不同的标志。请注意,这仍然会使用文件的元数据,因此无法保证准确性。

还要注意,stat从GNU到Coreutils,它的“出生”时间往往是错误的(具有ext4收益的Linux 0表示它是未知的,带有UFS的 FreeBSD 显示的“出生”时间比我查询的系统要早)。正确的值列为其“更改”时间。

如果您想花哨的时间,并获得以下文件中最旧文件的创建时间/etc

ls -lact --full-time /etc |awk 'END {print $6,$7,$8}'

该命令在旧的FreeBSD系统(UFS,没有GNU utils)上为我工作:

stat "/etc/$(ls -act /etc |tail -1)" |awk -F\" '{print $6}'

(是的,这是解析的ls,这是禁忌,但是在中不应有错误命名的文件/etc。)

您还可以stat用来获取其他时间格式。例如,要在Unix时代获取创建时间:(stat -c %Z FILE对于GNU,请注意,这%Z是“上次状态更改的时间”,但这是我的Linux和BSD系统的正确标志,如上所述;%W是“文件的诞生时间” )或stat -f %c FILE(使用BSD)。


6

在Fedora中,anaconda安装程序会将安装的配置详细信息存储在root的主文件夹中,这可以使您有所了解。

在Debian(至少是最新的)上,安装中的几个日志存储在中/var/log/installer/。旧版本将它们存储在中/var/log/installer.*。至少可以追溯到2003年。


4

根据OP的要求。

如果您正在寻找时间,请在设置系统时确定该时间。首先,该系统可能已被克隆(未安装),从而有效地伪造了文件创建时间。

您可以通过搜索最早的文件来估计使用时间。


mattdm是正确的;您可以获得访问时间,修改时间和更改时间;ctime是最后一个。看到这样的帖子
Michael Mrozek


2

我查看了/ boot中最旧的文件(“ ls -ltr / boot”的顶部。通常从第一次安装开始就有一个原始的引导扇区。在我最旧的系统上,它给出了原始安装的日期,尽管已经替换了其中的所有内容)。机器并复制文件系统的内容大约几次:)


2

我一直在寻找类似的工具,而我能想到的最好的就是ls -lAhF /etc/hostname,只是主机名文件的使用期限。我认为,通常,系统的主机名是在开始时设置的,在系统的生命周期内保持不变。创建文件系统的日期确实有帮助,但可能会引起误解。例如,我经常使用我之前安装的虚拟机映像,将其复制,更改主机名并从中创建新服务器。因此,就我而言,/etc/hostnametune2fs -l /dev/sda1


1

如果在安装期间使用了LVM,则可以检查在安装当天完成的逻辑卷的创建日期,例如:

$ sudo lvdisplay /dev/mapper/KUbuntu_VG-rootFS | grep Creation
  LV Creation host, time kubuntu, 2014-12-28 20:52:15 +0100

0

ls -alct /root ->根主目录是在安装时创建的


1
但是事后可能会发生变化。/如果不保留内核,则开启时间的变化可能性会略微降低/,但这仍然不是一个很好的指标。(提醒:-c不是创建时间,而是元数据更改时间。大多数Unix文件系统都不存储文件的创建时间。)
Gilles

告诉我任何无法更改的时间:)
jet

该问题的假设是“假设没有人试图隐藏它”。的ctime /root可能会自然变化(例如,每次有人在那里创建文件时)。
Gilles

0

从前一段时间以来,我通常在sime时安装linux发行版的软件包Tuptime,该软件包保留有关运行时间,启动,关闭的有用统计信息...

对于您的问题,“系统寿命”行中包含该信息。例如:

System startups:    110   since   10:15:27 08/08/15
System shutdowns:   107 ok   -   2 bad
System uptime:      4.04 %   -   1 days, 22 hours, 4 minutes and 44 seconds
System downtime:    95.96 %   -   45 days, 13 hours, 57 minutes and 30 seconds
System life:        47 days, 12 hours, 2 minutes and 15 seconds

Largest uptime:     2 hours, 10 minutes and 44 seconds   from   20:49:17 09/08/15
Shortest uptime:    9 seconds   from   10:23:36 08/08/15
Average uptime:     25 minutes and 8 seconds

Largest downtime:   7 days, 10 hours, 17 minutes and 26 seconds   from   06:09:45 10/08/15
Shortest downtime:  15 seconds   from   19:27:24 19/09/15
Average downtime:   9 hours, 56 minutes and 42 seconds

Current uptime:     23 minutes and 33 seconds   since   21:54:09 24/09/15

更多信息:https//github.com/rfrail3/tuptime/



-4

我找到了一个简单的文件。名称“ 1”。也许是第一个文件。

▶ ls -lact --full-time /1
-rw-r--r--. 1 root root 0 2017-03-23 12:02:46.880994133 +0800 /1

为什么要投票。这个时间实际上是指出最后一次系统安装的时间。
utopic eexpress

我的Linux上没有此文件。
凯文·勒梅尔
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.