Значення стовпців у команді "остання"

Коли я досліджував сервер, який регулярно перезавантажується, я почав переглядати "останню" утиліту, але проблема полягає в тому, що я не в змозі знайти, що саме означають стовпці. Я, звичайно, переглядав людину, але ця інформація не містить.

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/7, за винятком випадків, коли вони не збігаються, що може означати, що він перебуває в простої або щось подібне. Наприклад, якщо ми подивимось на два останніх рядки, чи означає це, що мій сервер був відключений з 2 квітня 09:17 до квітня 02:31?

Щодо довідкової інформації, то це сервер Debian Squeeze.

EDIT

Якщо останні стовпчики - це час початку, час зупинки та час безперервної роботи, як ви можете інтерпретувати ці два рядки:

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)   

Здається, другий сеанс закінчується після початку першого, що для мене не має сенсу.

Я здогадуюсь, що це трирічна посада, але я все одно відповім, на користь тому, хто трапляється в майбутньому, як це я нещодавно робив.

Якщо читати інші публікації та відстежувати результати роботи протягом певного періоду часу, схоже, що кожен рядок перераховує дату початку та час сеансу, час закінчення сеансу (але не кінцеву дату) та тривалість сеансу (як довго вони входили) у такому форматі

(днів + годин: хвилин)

Здається, що користувач перезавантаження відзначається як вхід у систему під час запуску системи, і вимкнення її при перезавантаженні або закритті, а в цих рядках інформація про тривалість сеансу - це тривалість часу (дні + години: хвилини) той "сеанс" тривав, тобто скільки часу система працювала до завершення роботи.

Для мене найновіша запис перезавантаження показує поточний час як час "виходу з системи", а дані про тривалість сеансу для цього запису відповідають поточному результату роботи без перерви.

Отже, по цій лінії:

перезавантажте систему завантаження системи 3.2.13-grsec-xxx Вт 3 квітня 07:34 - 09:17 (9 + 01: 42)

Система була запущена у вівторок, 3 квітня, о 7:34 ранку, її було закрито через 9 днів та 1 годину 42 хвилини (12 квітня), о 9:17 ранку. (Або цей вихід був зібраний у той час, і це остання запис перезавантаження, і "перезавантаження" насправді ще не "вийшла з системи". У цьому випадку результат зміниться, якщо ви повторно запустите останню команду.)

Чому ви мали б 2 записи для користувача перезавантаження, 3 квітня, які тривали обоє 9 днів, для мене загадка; мої системи цього не роблять.

Підсумок

• Першою часовою позначкою видається час, коли система вийшла з ладу під час перезавантаження.
• Друга мітка часу та час, що минув, не дуже корисні.
• Передача цієї -xопції lastможе бути корисною для показу інших подій, пов’язаних із відключеннями та змінами рівня запуску, які впливають на часові позначки, показані у rebootрядках. tuptimeІнструмент як зазначено в іншу відповідь може зробити це більш ясним, але я не дивився на неї.

Деталі

Сторінка lastлюдини на CentOS 6 і 7 говорить:

Псевдокористувач перезавантажує журнали під час кожного перезавантаження системи.

Він нічого не говорить про те, коли користувач виходить із системи, а показані нижче дані свідчать про те, що час виходу з програми явно не записується. rebootІ shutdownсторінки мають більш докладно про реєстрацію зміни рівня запуску , якщо хто - то зацікавлений.

З тестування виявляється, що час входу в систему - з запізненням у процесі вимкнення - це не з моменту, коли rebootкоманда була видана.

Тому, здавалося б, час виходу (друга часова марка) та тривалість, протягом якого "було перезавантажено", увійшов (у круглих дужках), ймовірно, слід ігнорувати.

Якщо ви передасте цей -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)

П'ять рядків "перезавантаження", перш за все, мають час виходу, рівний часу "системи вимкнення", яка слідувала за ними.

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 (до 3 рівня)", здається, мають більш розумний час виходу з них, але, схоже, вони не враховують збоїв.

На сторінці сторінки останні стовпці здаються початком сеансу, часом зупинки та тривалістю сеансу.

Я дивився, коли сервер був перезавантажений провайдером сервера (заплановане завдання виправити останні вразливості процесора Meltdown і Spectre) і який був справжній час простою операції.

Я використовую альтернативу "останньої перезавантаження", тому що я відчуваю, що їй не вистачає ясності, як ви вже помітили.

Виконуючи, 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 18.01.2018". Час простою тривав "18 хвилин 44 секунди", а запуск був у "03:15:31 18.01.2018", і він досі працює.

Останнє продовження строку, як ви говорите. Час перезавантаження останніх двох стовпців і поточний час, на який я думаю. Тому що коли я запускаю останню команду, другий стовпець іззаду показує поточний час і завжди змінюється.