☰

「最後」コマンド出力の一部の項目を解釈できません。

tag-icon • tag-icon ubuntu
「最後」コマンド出力の一部の項目を解釈できません。

以下は、「最終」端末出力のいくつかの項目です。

alex     tty2         tty2             Sun May 29 14:34 - down  (20+15:14)
reboot   system boot  5.13.0-44-generi Sun May 29 14:34 - 05:48 (20+15:14)
alex     tty2         tty2             Sun Mar 27 11:54 - down  (63+02:38)
reboot   system boot  5.13.0-35-generi Sun Mar 27 10:29 - 14:33 (63+04:03)
alex     tty2         tty2             Sat Mar 12 19:21 - crash (14+14:08)
reboot   system boot  5.13.0-35-generi Sat Mar 12 19:20 - 14:33 (77+18:12)
alex     tty2         tty2             Wed Feb 23 08:34 - crash (17+10:46)
reboot   system boot  5.13.0-30-generi Mon Jan 10 05:07 - 14:33 (139+08:25)
alex     tty2         tty2             Sun Feb 20 15:42 - crash (-41+10:34)
reboot   system boot  5.13.0-28-generi Sun Feb 20 15:42 - 14:33 (97+21:51)
alex     tty2         tty2             Sun Feb 20 15:36 - crash  (00:05)

エイリアンに加えて、次のような場合にどのような他のシナリオを提案できますか？

  • これは私のコンピュータではありませんが、今持っています。

    システム再起動 boot 5.13.0-35-generi 3月12日 土曜日 19:20 - 14:33 (77+18:12)

is the date and time when I opened the laptop lid for the first time, I had a password, since I am a relative of the owner of the computer. Please pay attention to line

reboot system boot 5.13.0-30-generi Mon Jan 10 05:07 - 14:33 (139+08:25)

そこに奇妙なデートがあります。私の主な関心は、そのような記録と日付がどのように起こったかです（エイリアンを除く）。認証されたログインなしでこの奇妙な日付をどのように説明できますか？結局のところ、「reboot」ユーザーの後、常に次の行は認証されたログインです。それとも私が何かを見逃しているのでしょうか？コンピュータの所有者が眠っている間にコンピュータの所有者や隣人が関係している場合など、他のすべてのシナリオが許可されます。私はコンピュータの所有者ではなく、利害関係者、つまり所有者の親戚であることを思い出させます。 ps両方のバッテリー（メインバッテリーとBIOS）は正常で、コンピュータにインストールされている唯一のオペレーティングシステムはUbuntuです。どんな意見でも歓迎します。

答え1

これらの日付はすべて2022年のカレンダーに合うようです。

この(dd+hh:mm)値は、対応するログインセッションの長さ、または再起動から最後のログインまでの時間です。ラップトップは頻繁に使用されず、セルフ放電によってバッテリが放電され、一時停止状態が消えるまでRAM一時停止モードに切り替えることができるようです。この状態から復元すると、以前のログイン履歴はすべて閉じますcrash。

すべてのシステム起動は通常、rebootエントリを生成します。システムが制御された方法で正常にシャットダウンすると、reboot実際のシャットダウン時に以前のエントリが閉じられます。down (uptime)以前に制御されたシャットダウンなしでシステムが起動した場合、以前のエントリはreboot現在のシステム開始時刻より前にクラッシュしたと見なされます（このロジックは元のサーバー用に開発されたため、サーバーが稼働していると仮定します）。

alex     tty2         tty2             Wed Feb 23 08:34 - crash (17+10:46)
reboot   system boot  5.13.0-30-generi Mon Jan 10 05:07 - 14:33 (139+08:25)
alex     tty2         tty2             Sun Feb 20 15:42 - crash (-41+10:34)
reboot   system boot  5.13.0-28-generi Sun Feb 20 15:42 - 14:33 (97+21:51)
alex     tty2         tty2             Sun Feb 20 15:36 - crash  (00:05)

システム時間が2月20日日曜日以降に変更され、再起動エントリの稼働時間が約「97日ほぼ22時間」になり、次にユーザーのログインセッション時間が「マイナス41日」になったようですalex。 「1月10日」と2月20日の差は約41日です。 「衝突」エントリは、システムが正常にシャットダウンされていないが強制的にシャットダウンされた可能性があることを示します（または単にバッテリーが放電されるまで一時停止します）。

ただし、最新のオペレーティングシステムは可能な限りインターネット上で時刻を同期しようとするため、システムが「1月10日」（偽の時刻になる可能性があります）に一度起動し、ユーザーがログインすると、時刻はalex2月23日はすでにResyncです。 。

2022 年 1 月 10 日から 2022 年 2 月 24 日までの期間が法的に重要な場合 (たとえば、ノートブックにその範囲内の日付の故人の最後の遺言の最新バージョンが含まれていることがわかります)。お勧めします。インターネットに浮かぶよりも信頼性が高く公正な専門家の適切なフォレンジック調査でシステムを評価してください。

関連情報