Created attachment 3185 [details] Исправление порядка выставления лимитов в limited Если попытаться задать для некоторой программы (в моём случае это был pulseaudio, но это не имеет значения) через /etc/sysconfig/limits.d/ и мягкий, и жёсткий лимиты, то легко создать ситуацию, при которой /sbin/limited ломается на первом же вызове ulimit. Последовательность действий у меня была следующая: 1. Прописываем в /etc/sysconfig/limits.d/pulseaudio два лимита: допустим, RLIMIT_SOFT_RTPRIO=7 и RLIMIT_HARD_RTPRIO=9. 2. service pulseaudio start Вместо запущенного pulseaudio получаем ругань на Invalid argument при выставлении real-time priority. 3. Выполняем ulimit -H -r 9 4. service pulseaudio start проходит без проблем. А всё потому, что /sbin/limited сначала выставляет все мягкие лимиты, а потом все жёсткие. А если сделать ulimit -S -r 7 при жёстком лимите 0 (по умолчанию), то будет тот же самый invalid argument. Очевидный патч на limited прилагается.
0.5.18-alt1-2-ge6f5138
Да, проспали. Если просто поменять местами порядок установки лимитов, то они не будут выставляться в других случаях. Вот пример: # (ulimit -Hn; ulimit -Sn) 1024 1024 # (ulimit -Hn 1023; ulimit -Sn 1022) -bash: ulimit: open files: cannot modify limit: Invalid argument # (ulimit -Sn 1025; ulimit -Hn 1026) -bash: ulimit: open files: cannot modify limit: Invalid argument Т.е. повышение лимита нужно начинать с hard, а понижать -- начиная с soft.
Тогда нужно несколько иначе выставлять лимит. set_ulimits() должна обрабатывать сразу оба типа лимитов.
(In reply to comment #3) > Тогда нужно несколько иначе выставлять лимит. set_ulimits() должна обрабатывать > сразу оба типа лимитов. Она должна обрабатывать сразу оба типа лимитов, но самое главное -- она должна читать текущие значения лимитов для того, чтобы определить порядок их установки.
Я сейчас попробую.
Created attachment 3213 [details] limited v1 На самом деле, сразу определить правильный порядок весьма хлопотное занятие. Вот одно из возможных вариантов. Его плюс он маленький и простой.
Dmitry, please pull the latest git tree from: git.alt:/people/legion/packages/service.git I think we can close this bug. Suggest: Resolve => Fixed.
Hopefully fixed in 0.5.19-alt1
