当我调查以常规方式重新启动的服务器时，我开始查看“最后”实用程序，但问题是我无法找到这些列的确切含义。当然，我已经查过这个人，但它不包含此信息。
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 的服务器，只是时间似乎不匹配，这可能意味着它正在经历停机或类似的情况。例如，如果我们查看最后两行，这是否意味着我的服务器从 Apr 2 09:17 到 Apr3 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)
第二次会议似乎在第一次会议开始后结束，这对我来说没有意义。
答案1
我想这是一篇三年前的帖子，但无论如何我都会回复，为了将来遇到它的其他人的利益，就像我最近所做的那样。
通过阅读其他帖子并在一段时间内自己监控输出，看起来每一行都列出了会话的开始日期和时间、会话的结束时间（但不是结束日期）以及会话的持续时间（他们登录了多长时间），格式如下
（天+小时：分钟）
重启用户似乎被标记为在系统启动时登录，在系统重启或关闭时关闭，在这些行中，“会话持续时间”信息是“会话”持续的时间长度（天+小时：分钟），即系统在关闭之前启动了多长时间。
对我来说，最近的重新启动条目将当前时间显示为“注销”时间，并且该条目的会话持续时间数据与当前正常运行时间输出相匹配。
所以在这一行：
重新启动系统启动 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分关闭。 （或者，此输出是在当时收集的，这是最近的重新启动条目，并且“重新启动”实际上尚未“注销”。在这种情况下，如果再次运行最后一个命令，输出将会更改。）
为什么 4 月 3 日会有 2 个重启用户的条目，这两个条目都长达 9 天，这对我来说是个谜；我的系统不这样做。
答案2
概括
- 第一个时间戳似乎是系统在重新启动期间停机的时间。
- 第二个时间戳和经过的时间并不是很有用。
- 传递该
-x选项last可能有助于显示与关闭和运行级别更改相关的其他事件，这些事件会影响行中显示的时间戳reboot。另一个答案中引用的工具tuptime可能会使这一点更清楚，但我还没有看过它。
细节
lastCentOS 6 和 7 的手册页显示：
每次系统重启时，伪用户reboot都会登录。
它没有说明用户何时注销，并且下面显示的证据似乎表明没有明确记录注销时间。如果有人感兴趣的话，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”则为当前时间”跟着它。
“运行级别（到 lvl 3）”条目似乎有一个更合理的注销时间猜测，但它似乎没有考虑到崩溃。
答案3
从联机帮助页来看，最后一列似乎是会话开始、停止时间和会话持续时间。
答案4
正如你所说，最后一行的正常运行时间。我认为最后两列重启时间和当前时间。因为当我运行最后一个命令时，后面的第二列显示当前时间并且总是变化。