Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 23 down vote favorite
6

any ideas please ? first off I thought that I could easily check the timestamp of particular files, but then I realized that it wouldn't be so easy when I saw timestamps like 1991 :-)

share|improve this question
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 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

6 Answers

up vote 27 down vote accepted

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!

share|improve this answer
1  
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
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. – ring0 Jan 12 '11 at 16:20
up vote 7 down vote

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.

share|improve this answer
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 3: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
up vote 4 down vote

try 

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

the keys are generated when you install the os.

share|improve this answer
1  
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
up vote 3 down vote

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.

share|improve this answer
up vote 2 down vote

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.

share|improve this answer
up vote 1 down vote

This also works for Red Hat systems:

rpm -qi basesystem | grep "Install Date"
share|improve this answer
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 1 '12 at 19:28

protected by Chris S♦ Aug 1 '12 at 19:14

This question is protected to prevent "thanks!", "me too!", or spam answers by new users. To answer it, you must have earned at least 10 reputation on this site.

Not the answer you're looking for? Browse other questions tagged or ask your own question.