Значения столбцов в «последней» команде

Когда я исследовал сервер, который регулярно перезагружался, я начал просматривать «последнюю» утилиту, но проблема в том, что я не могу определить, что именно означают столбцы. Я, конечно, просмотрел человека, но он не содержит этой информации.

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 до 3 апреля 02:31?

Что касается справочной информации, то это сервер Debian Squeeze.

РЕДАКТИРОВАТЬ

Если последними столбцами являются время начала, время окончания и время безотказной работы, как вы можете интерпретировать эти две строки:

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)   

Второй сеанс заканчивается после первого, что для меня не имеет смысла.

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

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

(дни + часы: минуты)

Похоже, что пользователь перезагрузки вошел в систему при каждом запуске системы и выключен, когда система была перезагружена или выключена, и в этих строках информация о «продолжительности сеанса» представляет собой продолжительность времени (дни + часы: минуты) эта «сессия» продолжалась, то есть сколько времени система работала, прежде чем она была выключена.

Для меня самая последняя запись перезагрузки показывает текущее время как время выхода из системы, а данные о продолжительности сеанса для этой записи соответствуют текущему выводу времени безотказной работы.

Итак, на этой линии:

перезагрузка системы boot 3.2.13-grsec-xxx вт 3 апр. 07:34 - 09:17 (9 + 01: 42)

Система была запущена во вторник, 3 апреля, в 7:34 утра, и была отключена через 9 дней и 1 час и 42 минуты (12 апреля), в 9:17 утра. (Или, этот вывод был собран в то время, и это самая последняя запись перезагрузки, и «перезагрузка» еще не «вышла из системы». В этом случае выходные данные изменятся, если вы снова запустите последнюю команду.)

Почему у вас есть 3 записи для пользователя перезагрузки, 3 апреля, которые длились 9 дней, для меня загадка; мои системы этого не делают.

Резюме

• Первая временная метка - это время, когда система вышла из строя во время перезагрузки.
• Вторая временная метка и прошедшее время не очень полезны.
• Передача -xопции lastможет быть полезна для отображения других событий, связанных с отключениями и изменениями уровня запуска, которые влияют на временные метки, показанные в rebootстроках. tuptimeИнструмент как указано в другой ответ может сделать это более ясным, но я не смотрел на нее.

Детали

lastСтраница на CentOS 6 и 7 говорит:

Псевдопользовательская перезагрузка регистрируется каждый раз при перезагрузке системы.

В нем ничего не говорится о том, когда пользователь выходит из системы, и приведенные ниже доказательства, по-видимому, указывают на то, что время выхода из системы явно не записывается. rebootИ shutdownстраницы имеют более подробно о регистрации изменения уровня запуска , если кто - то заинтересован.

В результате тестирования выяснилось, что время входа в систему истекло с момента завершения работы - это не время, когда rebootбыла введена команда.

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

Если вы передадите эту -Fопцию last, она покажет вам полные метки времени, что немного прояснит, что машина не перезагружается по совпадению в одно и то же время, а просто показывает одну и ту же метку времени несколько раз. Кроме того, если вы передадите -xфлаг, он покажет «записи о выключении системы и изменения уровня выполнения».

Здесь я запустил его на CentOS 7 и передал -Rопцию подавления столбца hostname / version version. Я также удалил некоторые неинтересные 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)

Как указано выше.

Исходя из приведенных выше результатов, я предполагаю, что для псевдопользователя «перезагрузка» не записывается явное время выхода из системы, поэтому lastприсваивает ему время выхода из системы при следующей «загрузке системы выключения» или текущее время, если нет «загрузки системы выключения» "следуя за этим.

Кажется, что записи "runlevel (to lvl 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 AM 01/18/2018". Время простоя составляло «18 минут и 44 секунды», а запуск был в «03:15:31 AM 01/18/2018», и он все еще работает на данный момент.

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