Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

That should be a quick one:

I'm running a small server, and one day discovered, that one of the LXC containers inside is down. I started it again, but I want to find out, for how long it was down.

I guess, that the most detailed information will be in dmesg logs, but to read timestamps in them I need to know exact moment the system was started during that session.

share|improve this question

You can /proc/uptime for this, the first number there is the uptime of the machine in seconds. Also, there's dmesg -T for human readable output.

share|improve this answer
Thank you. It works perfectly. (Reading the logs with proper time stamps I'm even more puzzled). – Adam Ryczkowski Nov 11 '13 at 10:05
[me@server]$ last reboot
reboot   system boot  2.6.32-279.22.1. Thu Oct  3 08:35 - 10:59 (39+03:23)  
share|improve this answer
In my case, it only shows the current boot time. Not the previous. That is all my output: reboot system boot 3.8.2-030802-gen Mon Nov 11 10:29 - 11:01 (00:31) wtmp begins Mon Nov 11 10:29:57 2013 – Adam Ryczkowski Nov 11 '13 at 10:02
But on my Ubuntu desktop this command works just fine. Maybe it can be a clue of what happened? (i.e. why the system went down) – Adam Ryczkowski Nov 11 '13 at 10:03
If it only shows the current boot time, that means that at some point your wmtp/utmp files have been truncated - either because /var got full, or because you were under attack/cracked and the cracker wanted to hide what they'd done. – Jenny D Nov 11 '13 at 10:08
Ouch... It makes sense. – Adam Ryczkowski Nov 11 '13 at 10:15
Also, the dmesg log will tell you what happened at the point of reboot. It's likely that the reason for the reboot occured just before that - so I'd start looking at syslog/messages from just before then, rather than the dmesg log. And given that there is a risk of attack, now would be a good time to start sending syslog to a second server in case the attack happens again and the attacker edits or removes the local log files. – Jenny D Nov 11 '13 at 11:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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