Meanings of the columns in "last" command

Question

As I was investigating a server that is rebooting in a regular fashion, I started looking through the "last" utility but the problem is that I am unable to find what the columns mean exactly. I have, of course, looked through the man but it does not contain this information.

root@webservice1:/etc# last reboot   
reboot   system boot  3.2.13-grsec-xxx Thu Apr 12 09:44 - 09:58  (00:13)    
reboot   system boot  3.2.13-grsec-xxx Thu Apr 12 09:34 - 09:43  (00:08)    
reboot   system boot  3.2.13-grsec-xxx Thu Apr 12 09:19 - 09:33  (00:13)    
reboot   system boot  3.2.13-grsec-xxx Thu Apr 12 08:51 - 09:17  (00:25)    
reboot   system boot  3.2.13-grsec-xxx Thu Apr 12 00:11 - 09:17  (09:05)    
reboot   system boot  3.2.13-grsec-xxx Wed Apr 11 19:40 - 09:17  (13:36)    
reboot   system boot  3.2.13-grsec-xxx Sun Apr  8 22:06 - 09:17 (3+11:10)   
reboot   system boot  3.2.13-grsec-xxx Sat Apr  7 14:31 - 09:17 (4+18:45)   
reboot   system boot  3.2.13-grsec-xxx Fri Apr  6 10:20 - 09:17 (5+22:56)   
reboot   system boot  3.2.13-grsec-xxx Thu Apr  5 00:16 - 09:17 (7+09:01)   
reboot   system boot  3.2.13-grsec-xxx Tue Apr  3 07:34 - 09:17 (9+01:42)   
reboot   system boot  3.2.13-grsec-xxx Tue Apr  3 02:31 - 09:17 (9+06:45)   
reboot   system boot  3.2.13-grsec-xxx Mon Apr  2 23:17 - 09:17 (9+09:59)   

The first columns makes sense up to the kernel versions included. What do these times represent exactly ? The last one seems to be the uptime.

Secondly, this is supposed to be a server on 24/7 except the times don't seem to match which could mean that it is experiencing downtime or somthing similar. For example, if we look at the two last lines, does it mean that my server was off from Apr 2 09:17 until Apr3 02:31 ?

As for the background information, this is a Debian Squeeze server.

EDIT

If the last colums are start time, stop time and uptime, how can you interpret these two lines :

reboot   system boot  3.2.13-grsec-xxx Tue Apr  3 07:34 - 09:17 (9+01:42)   
reboot   system boot  3.2.13-grsec-xxx Tue Apr  3 02:31 - 09:17 (9+06:45)   

The second session seems to end after the first one starts which doesn't make sense to me.

Answer 1

I guess this is a three year old post, but I'll respond anyway, for the benefit of anyone else who happens across it in the future, like I just did recently.

From reading other posts and monitoring the output myself over a period of time, it looks like each line lists the start date and time of the session, the end time of the session (but not the end date), and the duration of the session (how long they were logged in) in a format like

(days+hours:minutes)

The reboot user appears to be noted as having logged in whenever the system is started, and off when the system was rebooted or shutdown, and on those lines, the "session duration" information is the length of time (days+hours:minutes) that "session" lasted, that is, how long the system was up before it was shutdown.

For me, the most recent reboot entry shows the current time as the "logged off" time, and the session duration data for that entry matches the current uptime output.

So on this line:

reboot system boot 3.2.13-grsec-xxx Tue Apr 3 07:34 - 09:17 (9+01:42)

The system was started on Tuesday, April 3rd, at 7:34 am, and it was shutdown 9 days and 1 hour and 42 minutes later (on April 12th), at 9:17 in the morning. (Or, this output was gathered at that time, and this is the most recent reboot entry, and "reboot" hasn't actually "logged off" yet. In which case the output will change if you run the last command again.)

Why you would have 2 entries for the reboot user, on April 3rd, that were both 9 days long, is a mystery to me; my systems don't do that.

Answer 2

Summary

• The first timestamp appears to be the time at which the system went down during the reboot.
• The second timestamp, and the elapsed time, aren't very useful.
• Passing the -x option to last may be useful to show other events related to shutdowns and run level changes which influence the timestamps shown in the reboot lines. The tuptime tool as referenced in another answer may make this clearer, but I haven't looked at it.

Details

The last man page on CentOS 6 and 7 says:

The pseudo user reboot logs in each time the system is rebooted.

It doesn't say anything about when the user logs out, and the evidence shown below seems to suggest that no log out time is explicitly recorded. The reboot and shutdown man pages have more detail about recording the run level changes if anyone is interested.

From testing, it appears that the log in time is from late in the process of shutting down - it's not from the time that the reboot command was issued.

Therefore it would seem that the log out times (the second timestamp), and the duration for which "reboot" was logged in (shown in parentheses), should probably be ignored.

If you pass the -F option to last, it will show you full timestamps, which makes it slightly clearer that the machine isn't being coincidentally rebooted at the same time, it's just showing the exact same timestamp a few times. Also, if you pass the -x flag, it shows "system shutdown entries and run level changes."

Here, I ran it on CentOS 7, and I also passed the -R option to suppress the hostname/kernel version column. I also stripped out some uninteresting root logins:

# date ; last -x -F -R
Mon Nov 12 01:10:44 UTC 2018
root     pts/0        Mon Nov 12 00:02:57 2018   still logged in
runlevel (to lvl 3)   Sat Nov 10 17:57:29 2018 - Mon Nov 12 01:10:44 2018 (1+07:13)
reboot   system boot  Sat Nov 10 17:57:12 2018 - Mon Nov 12 01:10:44 2018 (1+07:13)
runlevel (to lvl 3)   Sat Oct 27 17:58:20 2018 - Sat Nov 10 17:57:29 2018 (13+23:59)
reboot   system boot  Sat Oct 27 17:58:03 2018 - Mon Nov 12 01:10:44 2018 (15+07:12)
runlevel (to lvl 3)   Sat Jul 21 18:14:55 2018 - Sat Oct 27 17:58:20 2018 (97+23:43)
reboot   system boot  Sat Jul 21 18:14:16 2018 - Mon Nov 12 01:10:44 2018 (113+06:56)
runlevel (to lvl 3)   Sun Nov 12 22:36:14 2017 - Sat Jul 21 18:14:55 2018 (250+19:38)
reboot   system boot  Sun Nov 12 22:35:35 2017 - Mon Nov 12 01:10:44 2018 (364+02:35)
root     pts/0        Fri Nov 10 07:13:20 2017 - crash                    (2+15:22)
runlevel (to lvl 3)   Sun Aug 27 04:15:56 2017 - Sun Nov 12 22:36:14 2017 (77+18:20)
reboot   system boot  Sun Aug 27 04:14:59 2017 - Mon Nov 12 01:10:44 2018 (441+20:55)
runlevel (to lvl 3)   Mon Aug 14 00:14:01 2017 - Sun Aug 27 04:15:56 2017 (13+04:01)
reboot   system boot  Mon Aug 14 00:13:46 2017 - Mon Nov 12 01:10:44 2018 (455+00:56)

The 6 "reboot" lines above all have a logout time equal to the current time.

shutdown system down  Fri Aug 11 08:05:29 2017 - Mon Aug 14 00:13:46 2017 (2+16:08)
root     pts/0        Fri Aug 11 08:05:23 2017 - down                      (00:00)
runlevel (to lvl 3)   Fri Jun 30 07:05:42 2017 - Fri Aug 11 08:05:29 2017 (42+00:59)
reboot   system boot  Fri Jun 30 07:05:27 2017 - Fri Aug 11 08:05:29 2017 (42+01:00)
[...]
root     pts/0        Fri Jun 30 05:48:16 2017 - crash                     (01:17)
root     pts/0        Tue Jun 27 04:59:56 2017 - Tue Jun 27 05:00:30 2017  (00:00)
root     pts/0        Mon Jun 26 11:20:57 2017 - Mon Jun 26 04:24:39 2017  (-6:-56)
runlevel (to lvl 3)   Mon Jun 26 11:15:13 2017 - Fri Jun 30 07:05:42 2017 (3+19:50)
reboot   system boot  Mon Jun 26 11:14:57 2017 - Fri Aug 11 08:05:29 2017 (45+20:50)
root     pts/0        Sun Jun 25 14:07:51 2017 - crash                     (21:07)
[...]
root     tty1         Thu Jun 22 13:07:42 2017 - crash                    (3+22:07)
runlevel (to lvl 3)   Thu Jun 22 13:07:07 2017 - Mon Jun 26 11:15:13 2017 (3+22:08)
reboot   system boot  Thu Jun 22 13:06:51 2017 - Fri Aug 11 08:05:29 2017 (49+18:58)
root     pts/0        Thu Jun 22 12:43:56 2017 - crash                     (00:22)
runlevel (to lvl 3)   Thu Jun 22 12:30:53 2017 - Thu Jun 22 13:07:07 2017  (00:36)
reboot   system boot  Thu Jun 22 12:30:38 2017 - Fri Aug 11 08:05:29 2017 (49+19:34)
root     pts/1        Thu Jun 22 12:26:49 2017 - crash                     (00:03)
root     pts/0        Thu Jun 22 11:55:28 2017 - crash                     (00:35)
runlevel (to lvl 3)   Thu Jun 22 11:49:53 2017 - Thu Jun 22 12:30:53 2017  (00:41)
reboot   system boot  Thu Jun 22 11:49:14 2017 - Fri Aug 11 08:05:29 2017 (49+20:16)

The 5 "reboot" lines above all have a logout time equal to the time of the "shutdown system down" that followed them.

shutdown system down  Thu Jun 22 11:47:45 2017 - Thu Jun 22 11:49:14 2017  (00:01)
[...]
runlevel (to lvl 3)   Wed Jun 21 15:59:42 2017 - Thu Jun 22 11:47:45 2017  (19:48)
reboot   system boot  Wed Jun 21 15:59:27 2017 - Thu Jun 22 11:47:45 2017  (19:48)

"reboot" logout time matches "shutdown system down" time again.

shutdown system down  Wed Jun 21 15:57:58 2017 - Wed Jun 21 15:59:27 2017  (00:01)
root     pts/0        Wed Jun 21 14:27:43 2017 - down                      (01:30)
[...]
runlevel (to lvl 3)   Tue Jun 20 17:14:15 2017 - Wed Jun 21 15:57:58 2017  (22:43)
reboot   system boot  Tue Jun 20 17:14:00 2017 - Wed Jun 21 15:57:58 2017  (22:43)

As above.

I assume from the results above that no explicit logout time is recorded for the pseudo user "reboot", so last assigns it a logout time of the next "shutdown system boot", or the current time if there isn't a "shutdown system boot" following it.

The "runlevel (to lvl 3)" entries seem to have a more sensible logout time guessed for them, but it doesn't appear to take into account the crashes.

Answer 3

From the manpage, the last columns seem to be the session start, stop times and the duration of the session.

Answer 4

I was looking when a server was rebooted by the server provider (a scheduled task to patch the recent Meltdown and Spectre CPU vulnerabilities) and what was the real downtime of the operation.

I use an alternative to "last reboot" because I feel that it laks of clearity as you already notice too.

Executing tuptime -l I can see the following list of the system behaviour:

...
Startup:  26  at  06:51:32 AM 11/06/2017
Uptime:   72 days, 20 hours, 5 minutes and 15 seconds
Shutdown: OK  at  02:56:47 AM 01/18/2018
Downtime: 18 minutes and 44 seconds

Startup:  27  at  03:15:31 AM 01/18/2018
Uptime:   5 days, 7 hours, 11 minutes and 32 seconds

In which is clear that the shudown was done following the system shutdown procedure at the specific hour and date "02:56:47 AM 01/18/2018". The downtime was along "18 minutes and 44 seconds" and the startup was at the "03:15:31 AM 01/18/2018" and it still running for now.

Answer 5

The last line uptime as you say. Last two column reboot time and current time I think. Because when I run last command the second column from back shows the current time and always change.