Когда я исследовал сервер, который регулярно перезагружался, я начал просматривать «последнюю» утилиту, но проблема в том, что я не могу определить, что именно означают столбцы. Я, конечно, просмотрел человека, но он не содержит этой информации.
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-логины:Прежде всего 6 строк «перезагрузки» имеют время выхода из системы, равное текущему времени.
Прежде всего, 5 строк «перезагрузки» имеют время выхода из системы, равное времени «выключения системы», которое последовало за ними.
время выхода из системы «перезагрузки» снова совпадает со временем выключения системы.
Как указано выше.
Исходя из приведенных выше результатов, я предполагаю, что для псевдопользователя «перезагрузка» не записывается явное время выхода из системы, поэтому
lastприсваивает ему время выхода из системы при следующей «загрузке системы выключения» или текущее время, если нет «загрузки системы выключения» "следуя за этим.Кажется, что записи "runlevel (to lvl 3)" имеют более разумное время выхода из системы, но они, по-видимому, не учитывают сбои.
источник
На странице руководства последние столбцы - это начало сеанса, время окончания и продолжительность сеанса.
источник
Я смотрел, когда сервер был перезагружен провайдером сервера (запланированное задание для исправления недавних уязвимостей процессора Meltdown и Spectre) и каковы были реальные простои операции.
Я использую альтернативу «последней перезагрузке», потому что чувствую, что она теряет ясность, как вы уже заметили.
Выполнение
tuptime -lя могу увидеть следующий список поведения системы:В котором ясно, что отмена была сделана после процедуры выключения системы в определенный час и дату "02:56:47 AM 01/18/2018". Время простоя составляло «18 минут и 44 секунды», а запуск был в «03:15:31 AM 01/18/2018», и он все еще работает на данный момент.
источник
Последнее время работы, как вы говорите. Последние два столбца перезагрузить время и текущее время, я думаю. Потому что, когда я запускаю последнюю команду, второй столбец сзади показывает текущее время и всегда меняется.
источник