Makna kolom dalam perintah "terakhir"

14

Ketika saya sedang menyelidiki server yang me-reboot secara teratur, saya mulai mencari melalui utilitas "terakhir" tetapi masalahnya adalah saya tidak dapat menemukan apa arti kolom-kolom itu secara tepat. Saya, tentu saja, telah memeriksa pria itu tetapi tidak mengandung informasi ini.

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)   

Kolom pertama masuk akal hingga versi kernel disertakan. Apa tepatnya yang mewakili waktu ini? Yang terakhir tampaknya menjadi uptime.

Kedua, ini seharusnya menjadi server pada 24/7 kecuali waktu tampaknya tidak cocok yang bisa berarti bahwa itu mengalami downtime atau sesuatu yang serupa. Misalnya, jika kita melihat dua baris terakhir, apakah itu berarti server saya mati dari 2 April 09:17 hingga Apr3 02:31?

Adapun informasi latar belakang, ini adalah server Debian Squeeze.

EDIT

Jika kolom terakhir adalah waktu mulai, hentikan waktu dan uptime, bagaimana Anda bisa mengartikan dua baris ini:

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)   

Sesi kedua tampaknya berakhir setelah yang pertama dimulai yang tidak masuk akal bagi saya.

Antoine Benkemoun
sumber
Pertanyaan itu hanya mencakup kolom uptime.
Antoine Benkemoun

Jawaban:

11

Saya kira ini adalah posting yang berumur tiga tahun, tetapi saya tetap akan menjawabnya, untuk kepentingan siapa pun yang kebetulan melewatinya di masa depan, seperti yang baru saja saya lakukan.

Dari membaca posting lain dan memantau output sendiri selama periode waktu tertentu, sepertinya setiap baris mencantumkan tanggal mulai dan waktu sesi, waktu akhir sesi (tetapi bukan tanggal akhir), dan durasi sesi (berapa lama mereka login) dalam format seperti

(hari + jam: menit)

Pengguna reboot tampaknya dicatat telah masuk setiap kali sistem dimulai, dan mati ketika sistem dinyalakan kembali atau dimatikan, dan pada baris tersebut, informasi "durasi sesi" adalah lamanya waktu (hari + jam: menit) "sesi" itu berlangsung, yaitu, berapa lama sistem dinyalakan sebelum dimatikan.

Bagi saya, entri reboot terbaru menunjukkan waktu saat ini sebagai waktu "keluar", dan data durasi sesi untuk entri itu cocok dengan output uptime saat ini.

Jadi pada baris ini:

boot ulang sistem booting 3.2.13-grsec-xxx Sel 3 Apr 07:34 - 09:17 (9 + 01: 42)

Sistem dimulai pada hari Selasa, 3 April, pada jam 7:34 pagi, dan itu dimatikan 9 hari dan 1 jam dan 42 menit kemudian (pada tanggal 12 April), pada jam 9:17 pagi. (Atau, output ini dikumpulkan pada waktu itu, dan ini adalah entri reboot terbaru, dan "reboot" belum benar-benar "keluar". Dalam hal ini output akan berubah jika Anda menjalankan perintah terakhir lagi.)

Mengapa Anda memiliki 2 entri untuk pengguna reboot, pada 3 April, yang keduanya 9 hari panjang, adalah misteri bagi saya; sistem saya tidak melakukan itu.

Shavais
sumber
1

Ringkasan

  • Stempel waktu pertama tampaknya adalah waktu sistem mati selama reboot.
  • Stempel waktu kedua, dan waktu yang berlalu, tidak terlalu berguna.
  • Melewati -xopsi ke lastmungkin bermanfaat untuk menampilkan acara lain yang terkait dengan penutupan dan perubahan level run yang memengaruhi cap waktu yang ditunjukkan di rebootbaris. The tuptimealat seperti yang disebutkan dalam jawaban lain mungkin membuat ini lebih jelas, tapi saya belum melihat itu.

Detail

The lastman halaman di CentOS 6 dan 7 mengatakan:

Log pseudo user reboot di setiap kali sistem di-reboot.

Itu tidak mengatakan apa-apa tentang ketika pengguna logout, dan bukti yang ditunjukkan di bawah ini menunjukkan bahwa tidak ada waktu logout yang direkam secara eksplisit. The rebootdan shutdownhalaman manual memiliki lebih detail tentang rekaman perubahan tingkat run jika ada yang tertarik.

Dari pengujian, tampak bahwa waktu masuk adalah dari akhir dalam proses mematikan - itu bukan dari saat rebootperintah dikeluarkan.

Oleh karena itu akan terlihat bahwa waktu keluar (stempel waktu kedua), dan durasi "reboot" masuk (ditunjukkan dalam tanda kurung), mungkin harus diabaikan.

Jika Anda meneruskan -Fopsi ke last, itu akan menunjukkan Anda cap waktu penuh, yang membuatnya sedikit lebih jelas bahwa mesin tidak sedang reboot secara kebetulan pada saat yang sama, itu hanya menunjukkan cap waktu yang sama persis beberapa kali. Juga, jika Anda melewati -xflag, itu menunjukkan "entri shutdown sistem dan menjalankan perubahan level."

Di sini, saya menjalankannya pada CentOS 7, dan saya juga memberikan -Ropsi untuk menekan kolom versi hostname / kernel. Saya juga menghapus beberapa login root yang tidak menarik:

# 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 baris "reboot" di atas semuanya memiliki waktu logout yang sama dengan waktu saat ini.

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 jalur "reboot" di atas semuanya memiliki waktu logout yang sama dengan waktu "shutdown system down" yang mengikutinya.

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)

"reboot" waktu logout cocok dengan "shutdown system down" time lagi.

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)

Seperti di atas.

Saya berasumsi dari hasil di atas bahwa tidak ada waktu logout eksplisit yang dicatat untuk pengguna semu "reboot", jadi lastberikan waktu logout untuk "boot sistem shutdown" berikutnya, atau waktu saat ini jika tidak ada "boot sistem shutdown" "mengikutinya.

Entri "runlevel (to lvl 3)" tampaknya memiliki perkiraan waktu logout yang lebih masuk akal untuk mereka, tetapi entri itu tampaknya tidak memperhitungkan crash.

doshea
sumber
0

Dari halaman manual, kolom terakhir sepertinya adalah sesi awal, waktu berhenti dan durasi sesi.

Wojtek Rzepala
sumber
Ya, tetapi halaman manual tampaknya tidak menyarankan bahwa waktu berhenti sesi apa pun dicatat untuk pengguna semu "reboot", dan bukti tampaknya membuktikan bahwa tidak ada yang dicatat, sehingga waktu berhenti dan durasi tampaknya tidak masuk akal.
doshea
0

Saya sedang mencari ketika server di-reboot oleh penyedia server (tugas yang dijadwalkan untuk menambal kerentanan CPU Meltdown dan Specter baru-baru ini) dan apa yang sebenarnya merupakan downtime operasi.

Saya menggunakan alternatif untuk "reboot terakhir" karena saya merasa itu jelas karena Anda sudah melihat juga.

Menjalankan tuptime -lsaya dapat melihat daftar perilaku sistem berikut:

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

Yang jelas bahwa shudown dilakukan mengikuti prosedur shutdown sistem pada jam dan tanggal tertentu "02:56:47 01/18/2018". Waktu henti adalah "18 menit dan 44 detik" dan startup berada di "03:15:31 01/18/2018" dan masih berjalan untuk saat ini.

Rfraile
sumber
-1

Baris uptime terakhir seperti yang Anda katakan. Terakhir dua kolom waktu reboot dan waktu saat ini saya pikir. Karena ketika saya menjalankan perintah terakhir, kolom kedua dari belakang menunjukkan waktu saat ini dan selalu berubah.

alpert
sumber
Bukan itu karena ini diambil pada Apr12 dan garis berhubungan dengan Apr3.
Antoine Benkemoun