Значения столбцов в “последней” команде
Вы уверены свои чтения распределения /etc/inittab?
Например, Ubuntu теперь использует upstart, который использует другой набор конфигурационных файлов.
Другая мысль: поместите другую запись там, которая работает mount и перенаправляет вывод в файл. Это докажет если inittab читается, и если файловые системы находятся в ожидаемом состоянии в то время, когда Вы пытаетесь выполнить перемонтирование.
Я предполагаю, что это трехлетний пост, но я все равно отвечу, на благо тех, кто-либо еще, кто бывает по нему в будущем, как я только что сделал недавно.
От чтения других постов и мониторинга вывода самого в течение определенного периода времени, похоже, каждая строка перечисляет дату и время начала сеанса, время окончания сеанса (но не дату окончания), а также продолжительность Из сессии (как долго они вошли в систему) в формате, подобном формате
(дни + часы: минуты)
пользователь перезагрузки, кажется, отмечается как войти в систему, когда система запускается, и выключается, когда система Был перезапущен или выключен, и на этих строках информации «Длительность сеанса» - это продолжительность времени (дни + часы: минут), что «сеанс» продолжался, то есть как долго система была до того, как она была выключена.
Для меня самая последняя запись перезагрузки показывает текущее время в качестве времени «вытесняемого», а данные продолжительности сеанса для этой записи совпадают с текущим выходным выходом обновления.
Так что на этой строке:
Перезагрузка системы загрузки 3.2.13-GrSec-XXX Tue 3 07:34 - 09:17 (9 + 01: 42)
Система была начата во вторник, 3 апреля , в 7:34 утра, и он был отключен 9 дней и 1 час и 42 минуты спустя (12 апреля), в 9:17 утра. (Или этот выход был собран в то время, и это самая последняя запись перезагрузки, а «перезагрузка» еще не «входит в систему» еще. В этом случае вывод изменится, если вы снова запустите последнюю команду.)
Почему у вас будет 2 записи для пользователей перезагрузки, 3 апреля, которые были уже в 9 дней, это загадка для меня; Мои системы этого не делают.
Из страницы справочника последние столбцы, кажется, сессия, запускают, останавливают времена и продолжительность сессии.
Прошлое время работы строки, как Вы говорите. В прошлый раз перезагрузки на два столбца и текущее время я думаю. Поскольку, когда я прихожу последним, управляют, чтобы второй столбец от спины показал текущее время, и всегда изменяйтесь.
-
1Нет это не это, потому что это было взято, Apr12 и строки касаются Apr3. – Antoine Benkemoun 12.04.2012, 11:32
Резюме
- Первая временная метка — это время, когда система отключилась во время перезагрузки.
- Вторая метка времени и прошедшее время не очень полезны.
- Передача опции
-xвlastможет быть полезна для отображения других событий, связанных с остановами и изменениями уровня выполнения, которые влияют на метки времени, показанные в строкахreboot. Инструментtuptime, упомянутый в другом ответе, может прояснить это, но я не смотрел на него.
Детали
Справочная страница lastв CentOS 6 и 7 говорит:
The pseudo user reboot logs in each time the system is rebooted.
В нем ничего не говорится о том, когда пользователь выходит из системы, а данные, приведенные ниже, позволяют предположить, что время выхода из системы явно не записывается. На справочных страницах 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)
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назначает время выхода следующей «загрузки системы при завершении работы» или текущее время, если нет t последует «загрузка системы выключения».
Записи "runlevel (to lvl 3 )", по-видимому, имеют более разумное время выхода из системы, но, похоже, они не учитывают сбои.