Linux логи при выключении

Is there a log that records shutdowns in Linux?

I was wondering if there is a log file in Linux which records every time the computer is shut down? The reason I am asking is I am doing some tests involving how long my laptop battery lasts under certain conditions. My laptop is configured to automatically shut down when there is about 10 minutes of battery power left, so if there is a log file somewhere that records when the computer is shut down, this will make my testing much easier. I’m running Ubuntu 10.04. Thanks!

11 Answers 11

The /var/log/messages file really should have something relating to shutdowns in it, for instance mine (CentOS 5) has lines like this:

Jul 18 23:00:13 nero shutdown[2649]: shutting down for system halt . Jul 18 23:00:27 nero kernel: Kernel logging (proc) stopped. Jul 18 23:00:27 nero kernel: Kernel log daemon terminating. 

Check your /etc/syslog.conf or /etc/rsyslog.conf or equivalent to make sure logs are going there. You’ll probably need root privileges to read the log files.

Also, while it’s not shutdowns per se, the «last» command should report reboots.

Is there really nothing at all in the logs around the time you last shut down?

For your testing, bear in mind that your computer only knows it has 10 minutes left because of the information the battery is reporting, which may or may not be accurate. Rather than waiting for shutdowns you could look at the ACPI information directly. On my laptop it’s here:

In there, the «state» and «info» files look interesting. You could watch the remaining capacity in the state file while you’re running your laptop under various conditions to see how quickly it drops.

Unless I’m missing it, I don’t see any sort of «shutting down» message in /var/log/messages. The message «Kernel logging (proc) stopped» sometimes appears, but not always. However, running last -x works. This command displays a line that looks like the following: shutdown system down 2.6.32-23-generi Sun Jul 25 09:12 — 19:00 (-14815+-13: Thanks for the battery info tip. My system also has this, so I will have to check this out! It seems to update these files every 5 seconds or so. Thanks!

How about command last -x shutdown ?

First, let me start by saying I know this is an older thread. I only comment so that others that find this while poking around the net (as I did today) will have a clear answer.

Second, please note that the following command is bad practice and falls under the «useless uses of cat» (google search for it) category.

cat /var/log/messages | grep "`LC_ALL=en_en.utf8 date +"%b %e"`" 

That line should be changed to:

grep "`LC_ALL=en_en.utf8 date +"%b %e"`" /var/log/messages 

grep, and most unix/linux commands (sed, awk, etc. ) for that matter do not require cat to read a files contents. It is sufficient to place the file path and name after the command to pass it as an argument. Adding a pipe and another external command (cat) is just wasted time and resources.

Finally, As to where to find a record of system shutdowns and/or reboots, use the last command as that is exactly what it is meant for. It reads the /var/log/wtmp log file for all login/logout entries. Because shutdowns and reboots are actually a system level login/logout event, they are recorded here. The same applies for root console shutdown, it is a logout event.

last -5 reboot shutdown root 

This will give you the last 5 reboot, shutdown, and root (console shutdown included) entries in the wtmp log.

reboot ~ Mon Mar 23 14:51 shutdown ~ Mon Mar 23 14:49 root console Mon Mar 23 14:49 - shutdown (00:00) reboot ~ Mon Mar 16 09:54 shutdown ~ Thu Mar 12 17:41 

I hope this helps anyone that stumbles across this thread. 🙂

Источник

Журнал выключений

В ос M$ есть журнал событий и с помощью проспотра которого можно выяснить — на сколько корректно выключался компьютер. В логах Linux не силён, но долгий гуглёж подсказал мне только утилиту last, по выхлопу которой история выключений стсиемы вообще не видна.

Поэтому хочу спросить — как встроенными средствами ОС можно посмотреть историю выключений Linux системы? В особенности меня интересует статус выключения — корректное завершение работы или система «упала».

Например, гипервизор не дождался выключения гостя и по таймауту брякнул песочницу с Linux. Необходимо в Linux-госте при загрузке выяснить статус предыдущего завершения работы (например, чтобы отправить email администратору).

гипервизор не дождался выключения гостя и по таймауту

А на гипервизоре не проще эту инфу собрать?

А на гипервизоре не проще эту инфу собрать?

Нет, Я привёл пример с гипервизором в качестве примера. Приведу другой — погас свет. При загрузке ОС должна определить что предыдущее выключение было некорректным и сформировать лог.

Вот не могу я поверить в то, что нет в Linux способа прочитать информацию о статусе предыдущих выключений ОС.

Чем корректное завершение работы от некорректного отличается? Смею предположить, что при «некорректном» завершении работы какой-то критичный демон не завершает свою работу как надо. Вот логи этого демона и смотри.

last -x reboot shutdown journalctl --list-boots 

man systemd-journald
systemd-journald writes entries to files in /run/log/journal/machine-id/ or /var/log/journal/machine-id/ with the «.journal» suffix. If the daemon is stopped uncleanly, or if the files are found to be corrupted, they are renamed using the «.journal~» suffix, and systemd-journald starts writing to a new file.

Почему?
Дайте вывод этой команды:

Как в этом логе можно найти 8 падений питания в день «Mon Jan 11»?

reboot system boot 2.6.32-45-server Fri Jan 15 12:14 - 12:15 (00:00) reboot system boot 2.6.32-45-server Tue Jan 12 10:57 - 12:15 (3+01:17) reboot system boot 2.6.32-45-server Mon Jan 11 17:50 - 12:15 (3+18:25) reboot system boot 2.6.32-45-server Mon Jan 11 17:38 - 12:15 (3+18:37) reboot system boot 2.6.32-45-server Mon Jan 11 17:36 - 12:15 (3+18:39) reboot system boot 2.6.32-45-server Mon Jan 11 17:34 - 12:15 (3+18:40) reboot system boot 2.6.32-45-server Mon Jan 11 17:32 - 12:15 (3+18:42) shutdown system down 2.6.32-45-server Mon Jan 11 17:32 - 10:19 (00:00) reboot system boot 2.6.32-45-server Mon Jan 11 17:30 - 11:12 (00:01) reboot system boot 2.6.32-45-server Mon Jan 11 17:29 - 11:12 (00:03) shutdown system down 2.6.32-45-server Mon Jan 11 17:29 - 10:19 (00:00) shutdown system down 2.6.32-45-server Mon Jan 11 17:29 - 10:19 (00:00) reboot system boot 2.6.32-45-server Mon Jan 11 17:07 - 19:04 (00:21) shutdown system down 2.6.32-45-server Mon Jan 11 17:07 - 09:49 (00:00) reboot system boot 2.6.32-45-server Mon Jan 11 17:04 - 19:02 (00:02) reboot system boot 2.6.32-45-server Mon Jan 11 17:03 - 19:02 (00:04) shutdown system down 2.6.32-45-server Tue Jul 21 19:19 - 13:59 (173+21:44) shutdown system down 2.6.32-45-server Thu Jul 21 19:19 - 10:19 (00:00) reboot system boot 2.6.32-45-server Tue Jul 21 19:17 - 13:58 (00:01) shutdown system down 2.6.32-45-server Tue Jul 21 19:17 - 13:38 (00:00)

Ну например, у тебя на сервере крутится mysql. Чем критично некорректное выключение сервера? Тем, что могут появиться проблемы в работе субд. Вот и смотри логи mysql, корректно оно легло или нет.

mysql

Есть сервера и без SQL. Разводить зоопарк методов для определения корректности выключения — не вариант, ровно как и установка SQL только ради мониторинга. Я задал сюда вопрос именно потому что не смог найти в чистой системе чего-то подобного логам SQL.

Какая тебе разница, как выключилась система? Тебе важно то, как «выключился» софт.

Источник

Не выключается Linux

Сразу после установки, как правило, любая операционная система будет работать очень хорошо и быстро. Но со временем ошибки могут накапливаться и вызывать различные проблемы с использованием ОС.

В сегодняшней статье мы рассмотрим такую ошибку, как «не выключается Linux». Разберём, почему может возникнуть такая проблема, методы её отладки и исправления.

Почему не выключается компьютер Linux?

Инициализацией и завершением работы сервисов в системе Linux занимается system, и если компьютер не может выключиться, это означает, что systemd не может справиться с каким-либо процессом и ждёт его завершения. По умолчанию система даёт каждому сервису одну минуту и тридцать секунд, а затем отправляет сигнал экстренного завершения. Но таких сервисов может быть несколько, и завершение работы Linux может затянуться.

Есть несколько путей решения этой проблемы:

• Во первых, нам необходимо понять в чём именно проблема, какой сервис её вызывает и попытаться её решить;
• Во вторых, мы можем уменьшить время ожидания от 90 до пяти секунд, для большинства сервисов этого будет вполне достаточно.

А теперь давайте рассмотрим пути решения проблемы.

Как исправить ошибку «не выключается Linux»

Чтобы понять, почему система не может выключиться, нам сначала необходимо посмотреть лог её выключения. И тут у нас тоже есть два пути: либо отключить заставку и выводить лог в реальном времени, либо записывать лог выключения с помощью journalctl.

1. Лог выключения в реальном времени

Первый способ не настолько информативный, но всё же может быть полезным. Для отключения заставки откройте /etc/default/grub и в строке GRUB_CMDLINE_LINUX_DEFAULT замените слова quiet splash на verbose:

Затем перезагрузите компьютер. Сначала вы будете видеть полный лог загрузки, а при выключении вы увидите полный лог выключения. Преимущество этого пути в том, что вы увидите, на какой команде загрузка зависает, и сможете понять, куда копать дальше. Например, часто бывает, что Linux не может выключиться из-за ошибки «a stop job is running for Session c2 of user», т.е. мы не можем завершить сессию пользователя. Ещё выключению могут препятствовать примонтированные удалённые файловые системы.

2. Лог выключения в journalctl

Утилита journalctl занимается обработкой логов в Linux, но есть одна проблема: она записывает журналы только из текущей сессии, при перезагрузке всё стирается. Но это можно исправить. Для этого окройте конфигурационный файл /etc/systemd/journald.conf и замените в нём значение строки Storage=auto на Storage=persistent:

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

Опция —b позволяет вывести лог загрузки, -1 говорит, что нужно брать не текущую загрузку, а предыдущую, а —n300 отображает только последние 300 строк. Здесь вы можете видеть, что по таймауту была завершена именно сессия session-c1. Мы можем отфильтровать сообщения только по ней:

sudo journalctl -b -1 -u session-c1.scope

Если вы увидели ошибку и смогли её решить, то ваша система будет выключаться уже мгновенно, если же нет, то всё ещё есть несколько путей решения.

3. Настройка таймаутов в systemd

Если никакое из предыдущих решение не помогло, и в системе просто баг, который не позволяет ей адекватно выключиться, то вы всё ещё можете уменьшить время ожидания до того, как процессу будет отправлен сигнал экстренного завершения. Для этого откройте файл /etc/systemd/system.conf и добавьте туда такие строки:

sudo vi /etc/systemd/system.conf

Теперь система будет ждать только 5 секунд перед тем, как завершить проблемный процесс. Также на некоторых форумах рекомендуют установить сервис watchdog, чтобы он следил за правильностью работы системного таймера. Это тоже делается очень просто:

sudo apt install watchdog
sudo systemctl enable watchdog
sudo systemctl start watchdog

Выводы

Может быть огромное количество причин, по которым ваша система не сможет включиться, и чтобы их найти и исправить, необходимо анализировать логи, искать по форумах и настраивать свою систему. Надеюсь, информация из этой статьи сделает вашу работу в Linux более комфортной.

Обнаружили ошибку в тексте? Сообщите мне об этом. Выделите текст с ошибкой и нажмите Ctrl+Enter.

Источник