「最後の」コマンドでの列の意味
定期的に再起動しているサーバーを調査していたため、「最後の」ユーティリティを調べ始めましたが、問題は、列の意味が正確に見つからないことです。もちろん、私は男性を調べましたが、この情報は含まれていません。
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)
最初の列は、含まれているカーネルのバージョンまで意味があります。これらの時間は正確に何を表していますか？最後は稼働時間のようです。
第2に、これは24時間365日のサーバーであると想定されますが、時刻が一致していないように見えるため、ダウンタイムまたは同様の問題が発生している可能性があります。たとえば、最後の2行を見ると、サーバーが4月2日の09:17からApr3 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年前の投稿だと思いますが、とにかく返信します。私が最近行ったように、今後この投稿で遭遇した人のためにです。
他の投稿を読んだり、自分で出力を一定期間監視したりすると、各行にセッションの開始日と時刻、セッションの終了時刻（ただし、終了日は含まない）、およびセッションの期間が表示されます。 （彼らがログインしていた時間）のような形式で
（日数+時間：分）
再起動ユーザーは、システムが起動するたびにログインし、システムが再起動またはシャットダウンするとオフになったように見えます。これらの行の「セッション期間」情報は、時間の長さ（日+時間：分）です。その「セッション」は継続しました。つまり、システムがシャットダウンする前にシステムが起動していた時間です。
私の場合、最新の再起動エントリは現在の時刻を「ログオフ」時刻として表示し、そのエントリのセッション継続時間データは現在の稼働時間出力と一致しています。
したがって、この行では：
システムの再起動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分にシャットダウンされました。 （または、この出力はその時点で収集されたものであり、これは最新の再起動エントリであり、「再起動」は実際にはまだ「ログオフ」されていません。その場合、最後のコマンドを再度実行すると、出力が変更されます。）
4月3日の再起動ユーザーに2つのエントリがあり、どちらも9日間だったのはなぜか、私には謎です。私のシステムはそれをしません。
概要
- 最初のタイムスタンプは、再起動中にシステムがダウンした時刻のようです。
- 2番目のタイムスタンプと経過時間はあまり役に立ちません。
-xオプションをlastに渡すと、reboot行に表示されるタイムスタンプに影響を与えるシャットダウンと実行レベルの変更に関連する他のイベントを表示するのに役立ちます。別の回答で参照されているtuptimeツールは、これをより明確にするかもしれませんが、私はそれを見ていません。
細部
CentOS 6および7のlastマニュアルページには、次のように記載されています。
疑似ユーザー再起動は、システムが再起動されるたびにログインします。
ユーザーがいつログアウトするかについては何も言われておらず、以下に示す証拠は、ログアウト時間が明示的に記録されていないことを示唆しているようです。 rebootおよびshutdownのマニュアルページには、実行レベルの変更の記録に関する詳細があります。
テストから、ログイン時間はシャットダウンプロセスの後半からのようです-rebootコマンドが発行された時間からではありません。
したがって、ログアウト時間（2番目のタイムスタンプ）、および「再起動」がログインした時間（括弧内に表示）は、おそらく無視する必要があるように見えます。
-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には、次の「シャットダウンシステムブート」のログアウト時間を割り当てます。それに続く「シャットダウンシステムブート」。
「ランレベル（レベル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
特定の時間と日付の「02:56:47 AM 01/18/2018」にシステムのシャットダウン手順に従ってシャットダウンが行われたことは明らかです。ダウンタイムは「18分44秒」で、起動は「03:15:31 AM 01/18/2018」で、今のところまだ実行中です。