45

I thought that I could easily check the timestamp of particular files. Then I realized that it wouldn't be so easy when I saw timestamps like 1991.

Dave M
  • 4,494
  • 21
  • 30
  • 30
lisak
  • 637
  • 2
  • 7
  • 19
  • 1
    I love all these answers, and have upvoted some, and learned from them. But it occurs to me that the question isn't well-defined: for instance, my colo'ed box has been through two incarnations of motherboard and four complete changes of HDD in the ten years it's been running, with the FS being dump|restored each time. All my ssh public keys are dated Feb 19, 2001; but the root FS was created Jun 11 2010, 20:59:01, when the mobo was last upgraded (along with the discs); yet other tests give yet different results, and it occurs to me: how do you define (not discover) the age of a linux system? – MadHatter Jan 12 '11 at 14:37
  • 4
    Apparently this is also known as the Ship of Theseus problem; see http://en.wikipedia.org/wiki/Ship_of_Theseus . – MadHatter Jan 12 '11 at 14:43
  • I always have a hdd with a partition that exists since I bought the machine... I put all the stuff I need to back up in there when I buy a new drive or create a new root partition with fresh kernel... But it didn't occur to me :-) – lisak Jan 12 '11 at 15:17

7 Answers7

51

The simplest way would probably be (presuming sda1 is your /root/):

tune2fs -l /dev/sda1 | grep created

This should show you the date on which the file system was created. Confirmed to work on ext2 to ext4, not sure about other file systems!

Niall Donegan
  • 3,859
  • 19
  • 17
  • 2
    When I get a new drive for my PCs I usually create partitions on it and then `cp -a` data over. So in short: it's not possible to determine the age of the system in all cases. – Hubert Kario Jan 12 '11 at 12:37
  • 1
    Perhaps using `/dev/root` is a bit more general. – camh Jan 12 '11 at 12:50
  • I installed a new system over the previous one, keeping the sda1 FS, and thus the solution of MihaiM below (ssh keys) was more accurate. – Déjà vu Jan 12 '11 at 16:20
16

One mechanism I often use is to check the change time (ctime) on files within the root home directory. Since the /root home directory is created at install time, and is often seldom used, this can provide a relatively good approximation. As clarified by Kyle in the comments, since ctime refers to the inode, and not the data, modifying the file contents will not change the ctime.

By default, the ls command prints the modification time (mtime) of the file. So if substitute in the ctime option like so,

ls -alct /root

This will print all files, display the create time, and sort by time.

As an example, here is a sample of the 3 oldest files in the /root directory from one of my systems.

ls -alt install.log.syslog .cshrc .tcshrc
-rw-r--r--. 1 root 10238 Feb 18  2010 install.log.syslog
-rw-r--r--. 1 root   129 Dec  3  2004 .tcshrc
-rw-r--r--. 1 root   100 Sep 22  2004 .cshrc

And then by checking the change time

ls -alct install.log.syslog .cshrc .tcshrc
-rw-r--r--. 1 root   100 Feb 18  2010 .cshrc
-rw-r--r--. 1 root 10238 Feb 18  2010 install.log.syslog
-rw-r--r--. 1 root   129 Feb 18  2010 .tcshrc

The date Feb 18th of 2010 certainly tracks with the approximate time I would have first installed that system.

Scott Pack
  • 14,717
  • 10
  • 51
  • 83
  • 4
    ctime is actually not the create time of a file, but rather is the change time. This is the last time I change was made to the inode. If you change the permissions or owner of a file this would change. Chances are the owner or permissions of the /root folder itself hasn't changed which is why this is lining up. (I don't know what the c actually stands for -- Single unix specification just has "time_t st_ctime Time of last status change". – Kyle Brandt Jan 12 '11 at 03:19
  • Indeed, the date/time of the installer log. Which may or may not be there depending on your distribution / os. – Koos van den Hout Jan 12 '11 at 18:05
6

try 

ls -alp /etc/ssh/ssh_host_dsa_key.pub | cut -d " " -f6

the keys are generated when you install the os.

MihaiM
  • 708
  • 1
  • 8
  • 17
  • 3
    This is a good idea however some weaknesses have been found in SSH keys and if you've done system updates (and you should be doing system updates!) then the keys would have been regenerated. – Josh Jan 12 '11 at 14:36
  • Excellent idea! However, if the key is new enough, `ls` shows the date differently (at least on my machine) so the `cut` command doesn't work right. I would now use `stat -c %y /etc/ssh/ssh_host*pub`. Also, I wonder why file creation times haven't gotten more love on Linux... – Rennex Nov 30 '15 at 02:57
4

Checking the hardware would be a good bet, if you have access to it. You could inspect the system and/or hardware components to get a good idea of when it was assembled.

Alternately, if you can gain access to the BIOS screen there's often date info there that can be used to determine how old a machine is.

If you can gain access to the SMART info on the hard drive (smartctl -a /dev/sda) there might be something there to go on. I don't see a specific timestamp in SMART but there is at least an hours of usage counter. That would provide a lower bound on how old the machine is (since if the hard drive has been running for 100 hours, the system can't be younger than 100 hours).

As for filesystem checks, you could look at the date info for /lost+found - that directory was created when the filesystem was created. The date on it should agree with the tunefs info from the previous answer.

Phil Hollenback
  • 14,647
  • 4
  • 34
  • 51
  • +1 for the `/lost+found` hint, as this information is available to non-privileged users. Running a batch operation like tune2fs on root filesystems as the superuser is a bit worrysome. In addition, this solution works on FreeBSD and non-ext2/3/4 filesystems. – Stefan Lasiewski Apr 04 '14 at 19:10
  • 1
    on a recent ubuntu system non-admins can't do this, one can however use this: stat -c "%z" /lost+found/ This should give something similar to 2014-05-26 15:14:15.000000000 +0200 Bonus: not locale influenced. – Cie6ohpa Dec 08 '20 at 14:52
3

With RedHat and derivatives, it's pretty easy to get a general idea of the OS version/vintage through a combination of file age and other system files. I'll usually check the /root/anaconda-ks.cfg file, as it contains the initial server setup and package parameters. Sometimes uname -a will have good information about the kernel build date. There would also be a cluster of files with the same date in /etc; typically the rcx.d links, rc scripts, inittab, etc.

ewwhite
  • 194,921
  • 91
  • 434
  • 799
3

This also works for Red Hat systems:

rpm -qi basesystem | grep "Install Date"
Mark
  • 31
  • 2
  • Note that this (and the tune2fs trick) works less well with virtual machines, if they're being spun up from a common image. The check of the ssh host keys is accurate on my Linode, though. – cjc Aug 01 '12 at 19:28
0

On an openSUSE system I checked the creation (aka birth) date of /var/log/wtmp will not be reset on rotation. It gets created on the first boot after installation. Thus it is likely to to show a time from shortly after the first boot started:

# ls -l --time=creation --time-style\=full-iso /var/log/wtmp
-rw-rw-r-- 1 root utmp 232323 2005-05-23 23:23:23.235000000 +0200 /var/log/wtmp

Not all file systems support creation date, see https://unix.stackexchange.com/a/91200 . It is not the same as ctime (here c for change) from GNU ls. Even if this information exists and can be read, there might have been reasons the date was reset, e.g. human intervention.

Jan Zerebecki
  • 138
  • 6