“ last”命令中各列的含义

在研究以常规方式重新引导的服务器时，我开始浏览“ last”实用程序，但问题是我无法找到各列的确切含义。我当然看过那个人，但其中不包含此信息。

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)   

第一列对包含的内核版本有意义。这些时间究竟代表什么？最后一个似乎是正常运行时间。

其次，这应该是24/7上的服务器，只是时间似乎不匹配，这可能意味着它正在经历停机或类似的情况。例如，如果我们查看最后两行，是否表示我的服务器从4月2日09:17到4月3日02:31处于关闭状态？

至于背景信息，这是一台Debian Squeeze服务器。

编辑

如果最后一个列是开始时间，停止时间和正常运行时间，那么如何解释这两行：

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)   

第二次会议似乎在第一个会议开始后结束，这对我来说没有意义。

我猜这是一篇已有三年历史的文章，但是无论如何，我都会做出回应，以使将来发生此事的其他人受益，就像我最近所做的那样。

通过阅读其他帖子并在一段时间内自己监视输出，看起来每一行都列出了会话的开始日期和时间，会话的结束时间（但不是结束日期）以及会话的持续时间（他们登录了多长时间）的格式如下

（天+小时：分钟）

在系统启动时，重新启动用户似乎已登录；在系统重新启动或关闭时，重新启动用户已登录；在这些行上，“会话持续时间”信息是时间长度（天+小时：分钟）该“会话”持续了一段时间，即系统在关闭之前已启动了多长时间。

对我来说，最新的重新引导条目将当前时间显示为“注销”时间，并且该条目的会话持续时间数据与当前的正常运行时间输出匹配。

所以在这一行：

重新启动系统启动3.2.13-grsec-xxx周二4月3日07:34-09:17（9 + 01：42）

该系统于4月3日（星期二）上午7:34启动，并在9天零1小时42分钟（4月12日）上午9:17关闭。（或者，该输出是在那时收集的，这是最新的重新引导条目，并且“ reboot”实际上尚未“注销”。在这种情况下，如果再次运行最后一个命令，则输出将更改。）

为什么在4月3日为重新启动用户提供2个条目（均为9天之久），这对我来说还是个谜。我的系统不这样做。

摘要

• 第一个时间戳似乎是系统在重新引导期间关闭的时间。
• 第二个时间戳和经过的时间不是很有用。
• 将-x选项传递给last可能对显示与关闭和运行级别更改相关的其他事件很有用，这些事件会影响reboot行中显示的时间戳。tuptime另一个答案中引用的工具可能使这一点更清楚，但是我没有看过。

细节

lastCentOS 6和7 的手册页上说：

每次重新引导系统时，伪用户重新引导都会登录。

它没有说明用户何时注销，并且以下证据似乎表明未明确记录注销时间。在reboot和shutdown手册页有关于如果有人有兴趣记录的运行级别更改的详细信息。

从测试来看，登录时间似乎是从关闭过程的后期开始的-不是从reboot发出命令的时间开始的。

因此，似乎登出时间（第二个时间戳）和“重新启动”的登录时间（显示在括号中）似乎应该被忽略。

如果将-F选项传递给last，它将显示完整的时间戳记，这使您可以更清楚地知道计算机不是在同一时间同时重新启动，而只是显示了几次相同的时间戳记。另外，如果传递该-x标志，它会显示“系统关闭条目和运行级别更改”。

在这里，我在CentOS 7上运行它，并且还传递了-R禁止显示主机名/内核版本列的选项。我还删除了一些无用的root登录名：

# 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)

最重要的是6条“重新引导”行的注销时间等于当前时间。

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)

最重要的是5条“重新启动”行的注销时间等于其后“关闭系统停机”的时间。

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)

“重新启动”注销时间再次与“关闭系统停机”时间匹配。

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)

如上。

我从上面的结果中假设，没有为伪用户“ reboot”记录明确的注销时间，因此last为它分配下一次“ shutdown system boot”的注销时间，或者为当前时间（如果没有“ shutdown system boot”的话）分配当前时间。 ”。

“运行级别（至3级）”条目似乎为他们猜测了更明智的注销时间，但似乎没有考虑到崩溃。

从联机帮助页来看，最后一列似乎是会话的开始，结束时间和会话的持续时间。

我正在查看服务器提供商何时重新启动服务器（一项计划任务来修补最近的Meltdown和Spectre CPU漏洞），以及该操作的真正停机时间是多少。

我使用了“上次重新启动”的替代方法，因为您也已经注意到，它感觉不太清晰。

执行中，tuptime -l我可以看到以下系统行为列表：

...
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

很明显，关机是在特定时间和日期“ 2018年1月18日上午02:56:47”按照系统关机程序进行的。停机时间为“ 18分44秒”，启动时间为“ 2018年1月18日上午03:15:31”，并且仍在运行。

正如您所说，最后一行正常运行时间。我认为最后两列的重新启动时间和当前时间。因为当我运行最后一条命令时，后面的第二列显示当前时间，并且总是在变化。