Reached target shutdown висит centos
Обновлено: 06.07.2024
Я знаю, что есть другие вопросы, похожие, но я расскажу подробнее об этой проблеме.
Когда я пытаюсь выключить / перезагрузить систему, она зависает навсегда. Это добавляется на Ubuntu 16.04 64 бит. Он добавляется на одном компьютере на обновленном Kubuntu (14.04 »16.04), на новом установленном Lubuntu 16.04 и событии на живом компакт-диске (iso загружается с жесткого диска с grml-rescue).
Он добавляет если я завершаю / перезагружаюсь из Desktop Enviroment, и если я делаю это с терминала.
Проблема не связана с Ubuntu 14.04, установленным на том же жестком диске.
Я попытался запустить fdisk в разделе, но ошибок не было найдено.
Я попытался добавить параметр irqpoll к системе boot
Кто-то разрешил, отключив поддержку устаревших usb3 на биосе, но моя материнская плата очень старая, у меня нет поддержки usb3 на bios
, но ни одна из тем не работает
, где есть вводный текст, который гласит:
Если вы столкнулись с зависанием, напишите файл отдельный отчет об ошибке и следуйте инструкциям отладки, описанным в разделе «Отладка проблем загрузки / выключения» в /usr/share/doc/systemd/README.Debian.gz, чтобы проверить, есть ли какие-либо зависания при завершении работы. Захват экранной фотографии «journalctl -b» в спасательной оболочке может быть просветляющим.
Итак, инструкции по debbuging говорят
, а затем, когда зависает зависание, у вас есть консоль на VT9 CTRL + ALT + F9, где вы можете сделать
, чтобы найти единицы с активным состоянием
, все заданные задания указаны в состоянии активным , единственным с запущенным состоянием является upower.service, который выделен жирным шрифтом.
Итак, я выключил компьютер и снова запустился, теперь на терминале, который я сделал
, поэтому я попытался выключите его и отключите его для будущего
Затем я снова попытался сбить с консоли отладки
, но выключение зависает, как обычно, плюс теперь я не может даже получить доступ к оболочке debug.
Загрузка без запуска параметров grub. Я вижу, что выключение зависает на выходной строке
Эти это строки syslog об отключении
Это мой вывод lshw
Может ли кто-нибудь мне помочь? Мне невероятно, что такая серьезная ошибка влияет на LTS.
Если я ставлю ShutdownWatchdogSec=0 то система зависает на заставке биоса и при этом куллер отключается.
июл 16 11:42:37 yan systemd[1]: Reached target Shutdown.июл 16 11:42:37 yan systemd[1]: lvm2-lvmetad.socket: Succeeded.
июл 16 11:42:37 yan systemd[1]: Closed LVM2 metadata daemon socket.
июл 16 11:42:38 yan systemd[1]: dev-disk-by\x2did-ata\x2dST500DM002\x2d1BD142_W3TFFWNL\x2dpart2.swap: Succeeded.
июл 16 11:42:38 yan systemd[1]: Deactivated swap /dev/disk/by-id/ata-ST500DM002-1BD142_W3TFFWNL-part2.
июл 16 11:42:38 yan systemd[1]: dev-disk-by\x2dpartuuid-c19b8459\x2d334e\x2d374c\x2db41f\x2d9f45587409f4.swap: Succeeded.
июл 16 11:42:38 yan systemd[1]: Deactivated swap /dev/disk/by-partuuid/c19b8459-334e-374c-b41f-9f45587409f4.
июл 16 11:42:38 yan systemd[1]: dev-disk-by\x2did-wwn\x2d0x5000c5007d5b7624\x2dpart2.swap: Succeeded.
июл 16 11:42:38 yan systemd[1]: Deactivated swap /dev/disk/by-id/wwn-0x5000c5007d5b7624-part2.
июл 16 11:42:38 yan systemd[1]: dev-disk-by\x2dpath-pci\x2d0000:00:13.0\x2data\x2d1\x2dpart2.swap: Succeeded.
июл 16 11:42:38 yan systemd[1]: Deactivated swap /dev/disk/by-path/pci-0000:00:13.0-ata-1-part2.
июл 16 11:42:38 yan systemd[1]: dev-sda2.swap: Succeeded.
июл 16 11:42:38 yan systemd[1]: Deactivated swap /dev/sda2.
июл 16 11:42:38 yan systemd[1]: dev-disk-by\x2duuid-dc9a8826\x2d4922\x2d4db7\x2d96ef\x2d63f24361b061.swap: Succeeded.
июл 16 11:42:38 yan systemd[1]: Deactivated swap /dev/disk/by-uuid/dc9a8826-4922-4db7-96ef-63f24361b061.
июл 16 11:42:38 yan systemd[1]: Reached target Unmount All Filesystems.
июл 16 11:42:38 yan systemd[1]: Reached target Final Step.
июл 16 11:42:38 yan systemd[1]: systemd-poweroff.service: Succeeded.
июл 16 11:42:38 yan systemd[1]: Finished Power-Off.
июл 16 11:42:38 yan audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=systemd-poweroff comm=>
июл 16 11:42:38 yan audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 subj==unconfined msg='unit=systemd-poweroff comm=">
июл 16 11:42:38 yan systemd[1]: Reached target Power-Off.
июл 16 11:42:38 yan systemd[1]: Shutting down.
июл 16 11:42:38 yan audit: BPF prog-id=6 op=UNLOAD
июл 16 11:42:38 yan audit: BPF prog-id=5 op=UNLOAD
июл 16 11:42:38 yan audit: BPF prog-id=4 op=UNLOAD
июл 16 11:42:38 yan audit: BPF prog-id=3 op=UNLOAD
июл 16 11:42:38 yan systemd-shutdown[1]: Syncing filesystems and block devices.
июл 16 11:42:39 yan systemd-shutdown[1]: Sending SIGTERM to remaining processes…
июл 16 11:42:39 yan systemd-journald[276]: Journal stopped
В чем проблема и как решить?
Решено
Добавил в /etc/defaul/grub:
GRUB_CMDLINE_LINUX_DEFAULT=«reboot=bios»
GRUB_CMDLINE_LINUX=«acpi=force»
И так-же в BIOS изменил securiti boot -> disable и boot model -> UEFI only.
Что там так долго стартует и останавливается?
Гляньте на всякий случай - какие сервисы у вас активированы и какие завершились с ошибками (systemctl --failed). Все с правами рута конечно.
@ind.indeviral, спасибо, ваш совет помог избавиться от ошибок типа
, но проблему, к сожалению, не решил :-((
Ладно, всем огромнейшее спасибо, кто помогал и направлял, на сегодня хватит, через сутки возобновлю искания. Быстрее было бы переустановить систему, но мы же не ищем лёгких путей :-) Просто удивительно, почему в режиме debug всё равно так мало информации в журнале! Знать бы, что он делает между
вот тогда бы всё и выяснилось! Ещё раз всем спасибо, тему не закрываю, но, видимо придётся самому копать; о результатах отпишусь.
Sheykhnur
Просто удивительно, почему в режиме debug всё равно так мало информации в журнале!
Для этого нужно использовать debug-shell + добавить в параметрах запуска systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
UPD. но это полезно в том случае, если зависание произошло после приветствия ArchLinux (то есть после запуска systemd).
PS. хотя, возможно, я и не прав - никогда не сравнивал информативность логов с использованием debug-shell в работающей системе. Поэтому, думаю, достаточно просто опции systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
Попробовал добавить информативности в логи. Вот что получил.
1. Обычная загрузка
$ journalctl -b | grep 'Got D-Bus'
…. ничего нет.
2. Загрузка с увеличением информативности
$ journalctl -b | grep 'Got D-Bus'
янв 07 17:29:12 arch systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Agent.Released() on /org/freedesktop/systemd1/agent
янв 07 17:29:12 arch systemd[1]: Got D-Bus request: org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/Dbus/Local
…. много повторений.
янв 07 17:29:13 arch systemd[1]: Got D-Bus request: org.freedesktop.DBus.Properties.Get() on /org/freedesktop/systemd1
….
янв 07 17:29:36 arch systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Manager.StartUnit() on /org/freedesktop/systemd1
….
Так что попробовать стоит. Будет увеличение информативности и в логе завершения работы.
Sheykhnur
. сервис не может завершить корректно работу, т.к. не получает сигнал d-bus.
Мой Ubuntu 16.04 зависает при выключении /перезагрузке, требуя от меня нажать и удерживать клавишу питания, чтобы выключить компьютер . Я не знаю, как сообщить об этом как об ошибке и о том, какие команды запускать, чтобы показать необходимое оборудование /sys log info? Любая помощь была бы чрезвычайно оценена!
У меня тоже была эта проблема. Кажется, это ошибка в нескольких дистрибутивах.
Мое простое исправление заключалось в редактировании строки /etc/default/grub :
Работает каждый раз сейчас. Я использую ноутбук Lenovo G50. Я почти уверен, что изменил эту строку в Grub с предыдущими (другими) дистрибутивами linux на этом ноутбуке.
Как только вы завершили свою работу и завершили закрытие всех своих приложений, чтобы завершить работу или перезагрузить ОС, выполните следующие действия, чтобы облегчить разочарование.
- Попробуйте sudo swapoff -a && systemctl poweroff в настоящее время.
- Существует потенциальное исправление в Xenial, предложенное в пакете systemd 229-4ubuntu5. Перейдите на вкладку «Параметры системы -> Программное обеспечение и обновления ->», затем нажмите кнопку «Рядом» с «Предварительная публикация» (предложенная для xenial). введите ваш root pwd, обновите кеш. На вкладке «Обновления» сразу же нажмите «Дисплейные обновления», закройте «Настройки системы». Запустите программу обновления программного обеспечения и установите ее сейчас.
- Если у вас все еще есть проблема, попробуйте прочитать эти ошибки: https: //bugs.launchpad.net/ubuntu/+source/systemd/+bug/1464917 для получения информации о том, как получить данные журнала, и, как было предложено, там будет опубликован новый отчет об ошибке. Также читайте ошибку: https://bugs.debian.org/cgi- бен /bugreport.cgi? ошибка = 788303 .
- Следуйте инструкциям отладки, описанным в разделе «Отладка проблем загрузки /выключения» в /usr/share/doc/systemd/README.Debian.gz , чтобы проверить, есть ли какие-либо зависающие задания при завершении работы , Вам нужно будет запустить оболочку отладки перед каждым завершением работы или перезагрузкой, введя: systemctl start debug-shell Захват снимка экрана journalctl -b в командной оболочке ctl+alt+F9 может быть просветляющим. Также вывод systemctl list-jobs и systemctl --failed Помимо экрана, вы можете выгрузить вывод этих команд и добавить их в один и тот же файл "filename.text" в корне / , добавив >>filename.text в конце команд, например journalctl -b >>filename.text journalctl -xe >>filename.text systemctl list-jobs >>filename.text systemctl --failed >>filename.text lsblk >>filename.text Все они будут находиться в том же файле, который прилагается вместе для анализа при следующей загрузке, и если вы делаете файл отчета об ошибке, может быть полезно прикрепить файл к вашему отчету об ошибке.
Обновление
У меня были эти Hangs довольно долгое время, но в конце концов я узнал, что мой жесткий диск начинает терпеть неудачу в секторах и т. д. Таким образом, пришло время для нового жесткого диска и переустановки. Я переустановил ОС на одном загрузочном жестком диске с Swap как 1-й, Root как 2-й и Home 3-й логический раздел согласно рекомендациям Ubuntu. Технически, sda1 - Grub, sda2 - Extended, sda5, sda6, sda7 - swap, root и home соответственно; sda3 и sda4 отсутствуют. С тех пор эта проблема не присутствовала на недавно установленной ОС на жестком диске, примерно на 9 месяцев. Я запускаю 16.04.02 LTS в этот момент без каких-либо зависаний при перезагрузке или завершении работы. Предыдущей ОС была двойная установка Win7 /Ubuntu, а раздел подкачки был в конце жесткого диска.
Я не утверждаю, что эта проблема связана с системой двойной загрузки, сбойным жестким диском или порядком, в котором я размещал разделы, но в моем случае один, два или все эти факторы существовали. Теперь я не страдаю от усугубления «Reached Target Shutdown».
У меня была проблема с зависанием при выключении, вот что я сделал:
Удалив quiet и splash позволяет текст во время выключения, помогает увидеть, где находится зависание.
GRUB_CMDLINE_LINUX_DEFAULT = "тихий всплеск" Удаление "тишины" здесь будет отображать текстовый вывод во время загрузки, тогда как удаление "всплеска" будет отображать черный экран вместо изображения всплеска.
Сохранить и закрыть Gedit
Затем обновите Grub в терминале:
Я заметил, что у меня тоже была «STOP JOB», поэтому я сокращаю тайм-аут в /etc/systemd/system.conf :
Это сработало для меня.
Tdenham. У меня такая же ситуация. Я только что обновил систему с 14.04 по 16.04 с помощью do-release-upgrade -d .
, который делает трюк. Вероятно, вы должны запустить sync прямо перед второй командой.
reboot -f может помочь, но я не пробовал, так как я не могу получить доступ к серверу, если он снова зависает.
Вы можете проверить файл /var /log /syslog. Найдите место, где вы включаете компьютер и проверяете строки прямо перед этим. Вы можете вставить его здесь.
Похоже, что dhclient пытается достичь ip-адреса, даже когда требуется перезагрузка.
Если это аппаратно-зависимая проблема, я вставил вывод lspci , чтобы помочь устранить ее.
Я пробовал несколько методов, включая: редактирование /etc/default/grub , запуск sudo swapoff -a перед выключением и т. д. . Но никто из них не работал для меня .
Отключение USB 3.0 legacy mode в BIOS работало для меня.
Я попробовал почти все предложения здесь. Единственным действием, которое разрешило мою проблему с shutdown /reset, было изменение DefaultTimeoutStartSec & DefaultTimeoutStopSec в /etc/systemd/system.conf до '10':
, а затем отредактируйте
Я просто переживал одну и ту же проблему, перезагрузка приведет меня к черному экрану или иногда к черному экрану с мигающим курсором, и это никогда не будет выполнено, я должен отметить, что у меня не было проблемы с закрытием.
Итак, что я сделал, я открыл Диспетчер Диска, и я установил прошивку Intel-Microcode для CPU, я выключил компьютер, а затем я устал перезапускать ОС, и он, наконец, работал.
Я на Linux Mint Cinnamon 18.3, основанный на Ubuntu Xenial Xerus 16.04 LTS.
Читайте также: