Форк завершается с ошибкой, ресурс временно недоступен. Какой ресурс?

Я унаследовал Perl-скрипт, который, в зависимости от конфигурации машины, дает сбой при вызове fork с $? == 11.

Согласно errno.h и различным posts, 11 равно EAGAIN, т.е. "попробовать еще раз", так как какой-то ресурс был временно недоступен.

Есть ли способ определить, какой ресурс вызвал сбой ветки, кроме увеличения различных системных ограничений по одному (дескрипторы открытых файлов , пространство подкачки, или количество допустимых потоков)?


fork perl ulimit
person phonybone    schedule 20.05.2017    source источник
comment
Разветвленный процесс — это полный клон исходного процесса. Профилирование вашего процесса перед разветвлением даст вам представление о том, сколько ресурсов он использует.   -  person alvits    schedule 20.05.2017
comment
Вы имеете в виду $!=11?   -  person ikegami    schedule 20.05.2017
comment
Do you mean $!=11?. На самом деле, я немного оговорился. Я должен был сказать, что форк прошел успешно, но сразу же заканчивается кодом состояния 11, как сообщает wait.   -  person phonybone    schedule 21.05.2017
comment
Итак, ваш вопрос не имеет ничего общего с вилкой, так почему вы приняли мой ответ, который полностью посвящен ошибке, установленной вилкой при сбое???   -  person ikegami    schedule 21.05.2017

Ответы (2)


arrow_upward
3
arrow_downward

Предполагая, что вы имеете в виду, что $! является EAGAIN, справочная страница fork в моей системе говорит:

EAGAIN: fork() не может выделить достаточно памяти для копирования таблиц родительских страниц и выделения структуры задачи для дочернего.

EAGAIN: Не удалось создать новый процесс, так как было достигнуто ограничение ресурсов вызывающей стороны RLIMIT_NPROC. Чтобы превысить это ограничение, процесс должен иметь возможность CAP_SYS_ADMIN или CAP_SYS_RESOURCE.

Вы пытаетесь создать массу процессов? Вы пожинаете своих детей, когда они сделаны?

person ikegami    schedule 20.05.2017
comment
См. мой комментарий выше для разъяснения первоначального вопроса, который был чрезмерным упрощением с моей стороны. Реальная последовательность событий такова: после инициализации программа предварительно обрабатывает большой (8Gb) файл с помощью некоторых вызовов system(). Затем программа разветвляет один процесс для каждого ядра процессора на машине. Таким образом, программа может пытаться продублировать очень большой объем памяти при разветвлении (но Linux поддерживает копирование и запись, так что это должно быть нормально?). Оперативной памяти большой объем (184Gb), и я поднял количество допустимых открытых файлов и увеличил пространство подкачки. - person phonybone; 21.05.2017
comment
Некоторые ответвления выполняются успешно, а некоторые терпят неудачу, и если я ограничу общее количество ответвлений, то часто смогу заставить программу работать нормально. - person phonybone; 21.05.2017
comment
Относительно разветвления успешно и некоторые из разветвлений успешны, а некоторые терпят неудачу, какой из них? Какой звонок не работает? Почему вы не проверяете, с какой ошибкой происходит сбой? - person ikegami; 21.05.2017

arrow_upward
0
arrow_downward

Ошибка связана с тем, что у пользователя закончились свободные стеки. Проверьте файл конфигурации безопасности на сервере RHEL [root@server1 webapps]# cat /etc/security/limits.d/90-nproc.conf.

# Default limit for number of user's processes to prevent

# accidental fork bombs.

# See rhbz #432903 for reasoning.

* soft nproc 1024

root soft nproc unlimited

[root@server1 webapps]# vi /etc/security/limits.d/90-nproc.conf

[root@server1 webapps]#

В моем случае «тестовый» пользователь получал сообщение «-bash: fork: retry: ресурс временно недоступен».

Решена проблема путем добавления пользовательских ограничений для ограничения стека.

[root@server1 webapps]# vi/etc/security/limits.d/90-nproc.conf

# Default limit for number of user's processes to prevent

# accidental fork bombs.

# See rhbz #432903 for reasoning.

* soft nproc 1024

test soft nproc 16384

root soft nproc unlimited

[root@server1 webapps]#

person Ishaq Khan    schedule 28.05.2020