Посещая наш сайт, вы соглашаетесь с нашей политикой конфиденциальности в отношении файлов cookie, статистики отслеживания и т. д.

Главная » Вопросы и ответы » Убунту

systemd[1]: apport-autoreport.service: Не удалось запустить, результат ‘достигнут лимит запуска’

На чтение 8 мин Опубликовано
Содержание
  1. Вопрос или проблема
  2. Ответ или решение
  3. Решение проблемы с apport-autoreport.service: Failed with result 'start-limit-hit' в Ubuntu
  4. Введение
  5. Описание проблемы
  6. Возможные причины
  7. Рекомендованные решения
  8. Временное решение
  9. Долгосрочные решения
  10. Заключение

Вопрос или проблема

systemd использует 100% непрерывно … вот top

top - 19:47:09 up 13 min,  1 user,  load average: 3.26, 2.62, 1.69
Tasks: 306 total,   4 running, 294 sleeping,   0 stopped,   8 zombie
%Cpu(s): 35.5 us, 12.6 sy,  0.0 ni, 51.9 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :  11858.2 total,   5183.4 free,   3433.2 used,   3241.6 buff/cache
MiB Swap:   2048.0 total,   2048.0 free,      0.0 used.   7913.7 avail Mem 

    PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND                                                                                    
      1 root      20   0  268660 110536   8532 R 100.0   0.9  11:39.36 systemd                                                                                    
    772 message+  20   0   10988   6768   4116 R  46.0   0.1   5:16.01 dbus-daemon                                                                                
    259 root      19  -1  496536 327492 325464 S  16.8   2.7   2:16.95 systemd-journal                                                                            
    796 syslog    20   0  221104   5832   4052 S  13.9   0.0   1:38.00 rsyslogd                                                                                   
    804 root      20   0  103380  93880   7784 S  13.1   0.8   1:34.41 systemd-logind                                                                             
     18 root      20   0       0      0      0 S   0.7   0.0   0:00.55 ksoftirqd/1                                                                                
   1733 root      20   0  352968 130376  83760 S   0.7   1.1   0:25.47 Xorg                                                                                       
   1916 ava       20   0 4008000 272576 117864 S   0.7   2.2   0:32.40 gnome-shell                                                                                
   3877 ava       20   0 2629148 269672 162688 S   0.7   2.2   0:09.53 Web Content

вот системный журнал

 sudo tail -n 100 /var/log/syslog
Авг 13 19:46:11 киев systemd[1]: Не удалось запустить отчеты об ошибках процесса, когда автоматическая отчетность включена.
Авг 13 19:46:11 киев systemd[1]: apport-autoreport.service: Запрос на запуск повторился слишком быстро.
Авг 13 19:46:11 киев systemd[1]: apport-autoreport.service: Не удалось с результатом 'start-limit-hit'.
Авг 13 19:46:11 киев systemd[1]: Не удалось запустить отчеты об ошибках процесса, когда автоматическая отчетность включена.
Авг 13 19:46:11 киев systemd[1]: apport-autoreport.service: Запрос на запуск повторился слишком быстро.
Авг 13 19:46:11 киев systemd[1]: apport-autoreport.service: Не удалось с результатом 'start-limit-hit'.
Авг 13 19:46:11 киев systemd[1]: Не удалось запустить отчеты об ошибках процесса, когда автоматическая отчетность включена.
Авг 13 19:46:11 киев systemd[1]: apport-autoreport.service: Запрос на запуск повторился слишком быстро.
Авг 13 19:46:11 киев systemd[1]: apport-autoreport.service: Не удалось с результатом 'start-limit-hit'.
Авг 13 19:46:11 киев systemd[1]: Не удалось запустить отчеты об ошибках процесса, когда автоматическая отчетность включена.
Авг 13 19:46:11 киев systemd[1]: apport-autoreport.service: Запрос на запуск повторился слишком быстро.
Авг 13 19:46:11 киев systemd[1]: apport-autoreport.service: Не удалось с результатом 'start-limit-hit'.
Авг 13 19:46:11 киев systemd[1]: Не удалось запустить отчеты об ошибках процесса, когда автоматическая отчетность включена.
Авг 13 19:46:11 киев systemd[1]: apport-autoreport.service: Запрос на запуск повторился слишком быстро.
Авг 13 19:46:11 киев systemd[1]: apport-autoreport.service: Не удалось с результатом 'start-limit-hit'.
Авг 13 19:46:11 киев systemd[1]: Не удалось запустить отчеты об ошибках процесса, когда автоматическая отчетность включена.
Авг 13 19:46:11 киев systemd[1]: apport-autoreport.service: Запрос на запуск повторился слишком быстро.
Авг 13 19:46:11 киев systemd[1]: apport-autoreport.service: Не удалось с результатом 'start-limit-hit'.
Авг 13 19:46:11 киев systemd[1]: Не удалось запустить отчеты об ошибках процесса, когда автоматическая отчетность включена.
Авг 13 19:46:11 киев systemd[1]: apport-autoreport.service: Запрос на запуск повторился слишком быстро.
Авг 13 19:46:11 киев systemd[1]: apport-autoreport.service: Не удалось с результатом 'start-limit-hit'.

вот некоторые сообщения dmesg

[    3.942656] systemd[1]: Вставлен модуль 'autofs4'
[    4.005635] systemd[1]: systemd 246-2ubuntu1 работает в системном режиме. (+PAM +AUDIT +SELINUX +IMA +APPARMOR +SMACK +SYSVINIT +UTMP +LIBCRYPTSETUP +GCRYPT +GNUTLS +ACL +XZ +LZ4 +ZSTD +SECCOMP +BLKID +ELFUTILS +KMOD +IDN2 -IDN +PCRE2 default-hierarchy=hybrid)
[    4.025381] systemd[1]: Обнаружена архитектура x86-64.
[    4.046020] systemd[1]: Установлено имя хоста <киев>.
[    4.132974] systemd[1]: /lib/systemd/system/docker.socket:6: ListenStream= ссылается на путь ниже устаревшего каталога /var/run/, обновление /var/run/docker.sock → /run/docker.sock; пожалуйста, обновите единицу файла соответственно.
[    4.137916] systemd[1]: /lib/systemd/system/dbus.service:12: Юнит настроен на использование KillMode=none. Это небезопасно, так как отключает управление жизненным циклом процессов systemd для сервиса. Пожалуйста, обновите ваш сервис, чтобы использовать более безопасный KillMode=, такой как 'mixed' или 'control-group'. Поддержка KillMode=none устарела и в конечном итоге будет удалена.
[    4.164397] systemd[1]: /lib/systemd/system/plymouth-start.service:17: Юнит настроен на использование KillMode=none. Это небезопасно, так как отключает управление жизненным циклом процессов systemd для сервиса. Пожалуйста, обновите ваш сервис, чтобы использовать более безопасный KillMode=, такой как 'mixed' или 'control-group'. Поддержка KillMode=none устарела и в конечном итоге будет удалена.
[    4.193000] systemd[1]: /lib/systemd/system/gdm.service:30: Стандартный тип вывода syslog устарел, автоматически обновление на журнал. Пожалуйста, обновите ваш единичный файл и рассмотрите возможность полного удаления настройки.

это произошло после моего последнего обновления системы … то же самое после перезагрузки и/или другого обновления системы … какие идеи?

ubuntu 20.04

В качестве временного обходного пути:
Удалите все файлы в /var/crash/
Это не долгосрочное или даже среднесрочное решение, но лучше, чем ничего для начала.

старая устаревшая решение см. ниже ОБНОВЛЕНИЕ для лучшего подхода

просто отключите неконтролируемый сервис apport

sudo systemctl disable apport-autoreport 
#  sudo apt-get purge apport    #  избегайте, это сработает, но слишком грубо
sudo apt-get purge apport-noui

затем после перезагрузки использование CPU systemd стало нормальным

tracker-miner-fs

использовал 100% CPU даже после другой перезагрузки, поэтому я выполнил

gsettings set org.freedesktop.Tracker.Miner.Files crawling-interval -2  
gsettings set org.freedesktop.Tracker.Miner.Files enable-monitors false
echo y | LANG=en tracker reset --hard

теперь все в порядке

ОБНОВЛЕНИЕ

отредактируйте файл /usr/lib/systemd/system/apport-autoreport.path

#  PathExistsGlob=/var/crash/*.crash  #  <-- старая плохая закомментируйте

PathChangedGlob=/var/crash/*.crash    #  хорошая новая замена вышеуказанной строки

сохраните, затем выполните

sudo systemctl daemon-reload

для деталей см. https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1891657

Вот мы спустя несколько месяцев после того, как эта проблема была решена, ниже содержимое с нормально работающего компьютера (Ubuntu 20.04 на 20210812)

cat /usr/lib/systemd/system/apport-autoreport.path 

[Unit]
Description=Обработка отчетов об ошибках, когда автоматическая отчетность включена (поиск файла)
ConditionPathExists=/var/lib/apport/autoreport

[Path]
PathExistsGlob=/var/crash/*.crash

[Install]
WantedBy=paths.target

У меня была аналогичная проблема совсем недавно. Сервис “apport” не удалось запустить.
Эта проблема была вызвана изменением каталога “/etc/cron.daily”.
Файл “apport” должен иметь разрешение на выполнение (по крайней мере) для root.
Проблема была исправлена. Теперь нет никаких проблем.

Команда может подтвердить решение:
$> systemctl -t service

Все активные сервисы, включая “apport.service”, должны отображаться как “loaded active exited.”

Урок, который я извлек: “Не изменяйте оригинальные разрешения файлов.” Удаление или перемещение этого файла в другое место привело бы к тому же эффекту.

Эта проблема и решение действительны для Ubuntu Server 24.04 LTS.

Ссылки

страница man systemctl для Noble Numbat LTS

Ответ или решение

Решение проблемы с apport-autoreport.service: Failed with result 'start-limit-hit' в Ubuntu

Введение

В последнее время многие пользователи Ubuntu сталкиваются с проблемой, связанной с системой управления службами systemd. В частности, ошибка apport-autoreport.service: Failed with result 'start-limit-hit' может привести к высокому потреблению ресурсов CPU, что, в свою очередь, вызывается частыми попытками перезапуска службы apport. Данная статья предлагает подробный анализ ситуации, возможные причины и проверенные решения.

Описание проблемы

Как видно из вывода команды top, процесс systemd использует 100% CPU, что может указывать на проблемы с запуском зависимых сервисов. Логи сообщают о том, что служба apport-autoreport.service не может стартовать и повторные запросы на её запуск происходят слишком быстро:

Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Start request repeated too quickly.
Aug 13 19:46:11 kiev systemd[1]: apport-autoreport.service: Failed with result 'start-limit-hit'.

Возможные причины

  1. Ошибки после обновления системы: Проблемы с сервисом apport часто возникают после обновления системы, когда изменения в конфигурации или зависимостях могут привести к сбоям.

  2. Проблемы с правами доступа: Если файл скрипта или сервисной единицы потерял права доступа или был изменен, это может вызвать сбои при запуске.

  3. Переполненная директория /var/crash: Высокое количество файлов в данной директории может привести к тому, что служба apport не сможет корректно обработать ошибки, что и станет причиной её постоянного перезапуска.

Рекомендованные решения

Временное решение

  1. Очистка каталога /var/crash:
    Выполните следующую команду, чтобы временно устранить проблему: 
    sudo rm -rf /var/crash/*

Долгосрочные решения

  1. Отключение службы apport:
    Если проблема сохраняется, вы можете отключить службу apport:

    sudo systemctl disable apport-autoreport

  2. Изменение конфигурации apport:
    В некоторых случаях помогает изменение конфигурационного файла /usr/lib/systemd/system/apport-autoreport.path. Откройте файл в текстовом редакторе и закомментируйте строку:

    # PathExistsGlob=/var/crash/*.crash

    Затем добавьте новую строку:

    PathChangedGlob=/var/crash/*.crash

    После внесения изменений не забудьте перезагрузить демон systemd:

    sudo systemctl daemon-reload

  3. Проверка прав доступа:
    Убедитесь, что права доступа на файлы и директории в /etc/cron.daily/ правильные и что скрипты могут исполняться от имени root.

  4. Сброс индексации файлов (если задействован Tracker):
    В случае если индикатор файлов создает нагрузку на систему, выполните следующие команды для настройки и сброса:

    gsettings set org.freedesktop.Tracker.Miner.Files crawling-interval -2
gsettings set org.freedesktop.Tracker.Miner.Files enable-monitors false
echo y | LANG=en tracker reset --hard

Заключение

Устранение проблемы с apport-autoreport.service требует комплексного подхода. Если описанные решения не помогают, следует обратиться к системному администратору или на форумы сообщества Ubuntu для более глубокой диагностики ситуации. Бережное отношение к конфигурации системы после обновлений и контроль за системными службами помогут значительно снизить вероятность возникновения таких проблем в будущем.

apport systemd
Оцените материал
Добавить комментарий

Капча загружается...

© 2024 IZ6.RU
*В материалах сайта упоминаются социальные сети Фейсбук / Инстаграм, принадлежащие Meta Platforms Inc., деятельность которой запрещена на территории РФ в части реализации данных социальных сетей на основании осуществления ею экстремистской деятельности