當我調查以常規方式重新啟動的伺服器時，我開始查看“最後一個”實用程序，但問題是我無法找到這些列的確切含義。當然，我已經查過這個人，但它不包含此資訊。
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
正如你所說，最後一行的正常運作時間。我認為最後兩列重啟時間和當前時間。因為當我運行最後一個命令時，後面的第二列顯示當前時間並且總是變化。