「最後の」コマンドの列の意味

通常の方法で再起動しているサーバーを調査していたとき、「最後の」ユーティリティを調べ始めましたが、問題は、列の正確な意味を見つけることができないことです。もちろん、私はその男に目を通しましたが、この情報は含まれていません。

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時間年中無休のサーバーであると想定されていますが、時刻が一致していないように見えるため、ダウンタイムなどが発生している可能性があります。たとえば、最後の2行を見ると、サーバーが4月2日09:17から4月3 02:31までオフだったということですか？

背景情報に関しては、これはDebian Squeezeサーバーです。

編集

最後の列が開始時間、停止時間、稼働時間である場合、これら2行をどのように解釈できますか？

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)   

2番目のセッションは最初のセッションが開始した後に終了するように見えますが、これは私には意味がありません。

これは3年前の投稿だと思いますが、とにかく応答します。先ほどやったように、将来的にこの問題に遭遇した人のために。

一定期間にわたって他の投稿を読んで出力を自分で監視すると、各行にはセッションの開始日時、セッションの終了時間（終了日ではなく）、およびセッションの期間がリストされているように見えます（ログインした時間）のような形式で

（日+時間：分）

再起動ユーザーは、システムが起動するたびにログインし、システムが再起動またはシャットダウンするときにオフになり、これらの行では「セッション期間」情報は時間の長さ（日+時間：分）として記録されるように見えますその「セッション」、つまり、システムがシャットダウンされるまでの時間。

私にとって、最新の再起動エントリは現在の時間を「ログオフされた」時間として表示し、そのエントリのセッション期間データは現在のアップタイム出力と一致します。

したがって、この行では：

reboot system boot 3.2.13-grsec-xxx Tue Apr 3 07:34-09:17（9 + 01：42）

システムは、4月3日火曜日の午前7時34分に開始され、9日1時間42分後（4月12日）の午前9時17分にシャットダウンされました。（または、この出力はその時点で収集されたもので、これは最新のリブートエントリであり、「reboot」は実際には「ログオフ」されていません。この場合、最後のコマンドを再度実行すると出力が変わります。）

4月3日に再起動ユーザーに2つのエントリがあり、どちらも9日間であった理由は、私には謎です。私のシステムはそれをしません。

概要

• 最初のタイムスタンプは、再起動中にシステムがダウンした時間のようです。
• 2番目のタイムスタンプと経過時間はあまり役に立ちません。
• -xオプションを渡すと、lastシャットダウンに関連する他のイベントや、reboot行に表示されるタイムスタンプに影響する実行レベルの変更を表示するのに役立ちます。tuptime別の答えに参照されるツールは、これを明確にするかもしれないが、私はそれを見ていません。

詳細

lastCentOS 6および7 のマニュアルページには次のように記載されています。

擬似ユーザーの再起動は、システムが再起動されるたびにログインします。

ユーザーがログアウトするタイミングについては何も言わず、以下に示す証拠は、ログアウト時間が明示的に記録されていないことを示唆しているようです。rebootとshutdown manページは、誰もが興味を持っている場合は、ランレベルの変更を記録についてのより詳細な情報を持っています。

テストから、ログイン時間はシャットダウンプロセスの後半からのものであるrebootように思われます。コマンドが発行されたときからではありません。

したがって、ログアウト時間（2番目のタイムスタンプ）、および「リブート」がログインされた期間（括弧内に表示）はおそらく無視されるようです。

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

上記のように。

上記の結果から、疑似ユーザー「reboot」の明示的なログアウト時間は記録されていないためlast、次の「シャットダウンシステムブート」のログアウト時間、または「シャットダウンシステムブートがない場合は現在の時間」を割り当てます。 「それに続く。

「runlevel（to lvl 3）」エントリには、より合理的なログアウト時間が推測されているように見えますが、クラッシュを考慮していないようです。

マンページから見ると、最後の列はセッションの開始、停止時間、セッションの継続時間のようです。

サーバープロバイダーによってサーバーが再起動された時期（最近のMeltdownおよびSpecterの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

これは、特定の時間と日付「02:56:47 AM 01/18/2018」にシステムのシャットダウン手順に従ってシャットダウンが実行されたことは明らかです。ダウンタイムは「18分44秒」に沿っており、スタートアップは「2018年1月18日午前3時15分31秒」であり、現在も稼働しています。

あなたが言う最後のラインアップタイム。最後の2列の再起動時間と現在の時間を考える。私が最後のコマンドを実行すると、後ろから2番目の列に現在の時間が表示され、常に変化するためです。