“最后”命令中列的含义

Question

当我在调查一台以常规方式重新启动的服务器时，我开始查看“最后”实用程序，但问题是我无法找到列的确切含义。当然，我已经看穿了那个人，但里面没有这方面的信息。

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一直到Apr3 02:31关闭？

至于背景信息，这是一个Debian压缩服务器。

编辑

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

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)   

第二次会议似乎是在第一次开始之后结束的，这对我来说毫无意义。

Answer 1

我想这是一个三年前的帖子，但我还是会回复的，为了其他人的利益，在未来发生的事情，就像我最近做的那样。

通过阅读其他帖子并在一段时间内监视输出，每一行都会以如下格式列出会话的开始日期和时间、会话的结束时间(但不是结束日期)以及会话的持续时间(登录时间)

(days+hours:minutes)

重新引导用户似乎被注意到在系统启动时登录，在系统被重新启动或关闭时关闭，在这些行上，“会话持续时间”信息是“会话”持续的时间长度(days+hours:minutes)，即系统在关闭之前的运行时间。

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

所以在这条线上：

重启系统启动3.2.13-grsec-xxx Tue 4月3日:34- 09:17 (9+01:42)

该系统于4月3日星期二上午7:34启动，9天1小时42分钟后(4月12日)上午9:17关闭。(或者，这个输出是在那个时候收集的，这是最近的重新启动条目，而且" reboot“还没有真正”注销“。在这种情况下，如果再次运行最后一个命令，输出将发生变化。)

对于我来说，为什么在4月3日重新启动用户有两个条目，都长达9天，这对我来说是个谜；我的系统不会这么做。

Answer 2

摘要

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

详细信息

last在CentOS 6和7上的手册页面上写着：

每次重新启动系统时，伪用户都会重新启动日志。

它没有提到用户何时注销，下面显示的证据似乎表明没有明确记录注销时间。如果有人感兴趣的话，reboot和shutdown手册页有关于记录运行级别更改的更多细节。

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

因此，似乎应该忽略注销时间(第二个时间戳)和“重新启动”登录的时间(括号中显示)。

如果您将-F选项传递给last，它将向您显示完整的时间戳，这会稍微清楚地显示机器不是同时被重新引导的，它只是显示了几次完全相同的时间戳。另外，如果您传递-x标志，它将显示“系统关机条目和运行级别更改”。

在这里，我在CentOS 7上运行它，我还传递了-R选项来抑制主机名/内核版本列。我还删除了一些无聊的根登录：

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

如上段所述。

根据上面的结果，我假设没有为伪用户“重新启动”记录显式的注销时间，因此last为它分配下一个“关机系统启动”的注销时间，或者如果在它之后没有“关闭系统启动”，则指定当前时间。

“运行级(到lvl 3)”条目似乎有一个更合理的注销时间，但似乎没有考虑到崩溃。

Answer 3

从手册页来看，最后几列似乎是会话的开始、停止时间和会话的持续时间。