Как узнать, какой процесс потребляет ожидающие сигналы?

При попытке запустить определенную программу пользователь получает следующее сообщение.

timer_create: ресурс временно недоступен

Из этого вопроса и ответа StackOverflow под названием: timer_create (): -1 EAGAIN (ресурс временно недоступен) , я обнаружил, что это связано с нехваткой места для ожидающих сигналов. Я подтвердил это с помощью отдельной учетной записи пользователя, выполнив следующую команду:

$ ulimit -i 0 

и проверить, что я получаю ту же ошибку, что и я. С помощью этой команды:

 $ ulimit -i 1 

или любой более высокой суммы нет ошибки.

Когда исходный пользователь запускает ulimit -i он получает 127368. Таким образом, я пришел к выводу, что они как-то вышли из пространства для ожидающих сигналов.

Что происходит? Означает ли это, что одна или несколько запущенных программ потребляют их? Если да, то как узнать, какие из них?

  • Как сигналы обрабатываются в ядре
  • Ошибка фиксации сигнала 13 (SIGPIPE) для поиска и grep-конвейера
  • HURD: Почему удаленный процесс не убит?
  • `EINTR`: есть ли обоснование?
  • как уловить приостановку резюме из сценария bash
  • Отправка sigaction / sigqueue через оболочку
  • Есть ли утилита Linux для остановки всех пользовательских процессов, включая виртуальную машину?
  • Можно ли игнорировать сигнал (потерять)?
  • One Solution collect form web for “Как узнать, какой процесс потребляет ожидающие сигналы?”

    Ну, это не очень хорошее решение, но, по крайней мере, это может быть решение.

    В /proc/[pid]/status есть запись для SigPnd и ShdPnd. Они описываются как,

    SigPnd, ShdPnd: количество ожидающих обработки потоков и процесса в целом (см. Pthreads (7) и сигнал (7)).

    Существует также SigQ, который,

    SigQ: это поле содержит два разделенных косой чертой числа, которые связаны с сигналами в очереди для реального идентификатора пользователя этого процесса. Первым из них является количество в настоящее время поставленных в очередь сигналов для этого реального идентификатора пользователя, а второе – ограничение ресурсов на количество сигналов в очереди для этого процесса (см. Описание RLIMIT_SIGPENDING в getrlimit (2)).

    (Все это от man 5 proc ).

    Таким образом, вы можете искать все pid in /proc , проверять их status файлы и находить один с любыми ожидающими сигналами.

    Попробуй это,

    cd /proc

    find . -name "status" | xargs grep SigPnd 2> /dev/null | grep -v "0000000000000000"

    а также

    find . -name "status" | xargs grep ShdPnd 2> /dev/null | grep -v "0000000000000000"

    Interesting Posts

    Сохранять вывод из одной команды и обрабатывать ее для другого

    Может ли Xmonad лечить и править по-другому?

    Звук прекратил работу после обновления Ubuntu с 14.04 по 16.04

    Почему мой xfdesktop автоматически настраивает папки?

    Как восстановить grub2 (не) загрузку 32-разрядной EFI на 64-битной машине?

    Xorg игнорирует применение вина

    Каковы некоторые достойные замены альт-табу для Gnome?

    Нужно ли указывать подстановки команд при назначении их вывода переменной?

    Когда обнаружена уязвимость, влияющая на ядро ​​Linux, что мне делать с Docker?

    Как найти / перечислить все файлы в файловой системе с определенным SELinux «fcontext»

    Как создать мультизагрузочный USB с помощью инструментов livecd?

    Я хочу скопировать удаленный файл txt через SSH, но без использования корневого доступа

    Может ли сценарий bash рассказать, какой каталог пользователь, когда он запускает скрипт?

    Debian – сеть не работает при загрузке

    Подключитесь к экземпляру KVM, используя virsh, когда изображение запущено через Eucalyptus?

    Linux и Unix - лучшая ОС в мире.