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

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

一般的な方法でサーバーの再起動を調べると、「最後の」ユーティリティを見始めましたが、問題は、この列が正確に何を意味するのかを見つけることができないことです。もちろん、この内容を探しましたが、この情報は含まれていません。

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番目のセッションは最初のセッションの開始後に終了するようですが、私は理解していません。

答え1

この記事は3年も経っているようですが、最近そうしたように、今後この記事を見ることになる他の人のためにとにかく返信します。

他の投稿を読み、時間の経過とともに出力を直接監視した結果、各行にはセッションの開始日時、セッション終了時刻(終了日ではない)、セッション期間(終了日ではない)がリストされているように見えます。ログインしている)形式は次のとおりです。

(日+時間:分)

再起動したユーザーは、システムの起動時にログインしており、システムの再起動またはシャットダウン時にログオフされているように見えます。この行の「セッション期間」情報は、「セッション」が持続した時間(日+時:分)です。つまり、システムがシャットダウンする前に開始するのにかかる時間です。

私にとって、最新の再起動項目は現在の時間を「ログオフ」時間として表示し、その項目のセッション期間データは現在の稼働時間出力と一致します。

だからこの行では:

システム再起動 boot 3.2.13-grsec-xxx Tue 03 Apr 07:34 - 09:17 (9+01:42)

4月3日(火)午前7時34分からシステムが稼働し、9日1時間42分後の4月12日午前9時17分にシステムが終了した。 (または、この出力は最後の再起動項目である時点で収集されており、「再起動」はまだ実際に「ログオフ」されていません。この場合、最後のコマンドが再度実行されると出力は変更されます。)

4月3日にユーザーを再起動するための2つの項目(両方とも9日)がある理由は、私のシステムでそうしない理由です。

答え2

一般化する

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

詳細

lastCentOS 6と7のマニュアルページは次のように言います。

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

ユーザーがいつログアウトしたかはわかりません。以下の証拠を見ると、ログアウト時間が明示的に記録されていないことがわかります。誰もが興味がある場合はreboot、マニュアルページでshutdownランレベルの変更ログの詳細について説明します。

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行の「restart」ログアウト時間は現在の時刻と同じです。

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がない場合は、現在の時間が割り当てられていると仮定します。 「これに従ってください。

「runlevel(to lvl 3)」エントリは、ログアウト時により合理的な推測をするように見えますが、競合を考慮していないようです。

答え3

マンページでは、最後の列はセッションの開始、停止時間、およびセッション期間であることが示されます。

答え4

あなたが言ったように、最後の行は稼働時間です。最後の2つの列は、再起動時間と現在の時間だと思います。最後のコマンドを実行すると、次の2番目の列に現在の時刻が表示され、常に変更されるためです。

関連情報