У меня есть два сервера CentOS 5 с почти одинаковыми характеристиками. Когда я вхожу и делаю ulimit -u
, на одной машине я получаю unlimited
, а на другой я получаю 77824
.
Когда я запускаю cron вроде:
* * * * * ulimit -u > ulimit.txt
Я получаю те же результаты ( unlimited
, 77824
).
Я пытаюсь определить, где они установлены, чтобы я мог их изменить. Они не установлены ни в одном из моих профилей ( .bashrc
, /etc/profile
и т. Д.). Это никак не повлияет на cron) или in /etc/security/limits.conf
(который пуст).
Я покопался в гугле и даже зашел так далеко, что grep -Ir 77824 /
ничего не нашел. Я не понимаю, как эти машины могли предустановиться с разными ограничениями.
Я на самом деле задаюсь вопросом не об этих машинах, а о другой (CentOS 6) машине с ограничением 1024
, которое слишком мало. Мне нужно запускать задания cron с более высоким лимитом, и я знаю, как это сделать, в самом задании cron. Это нормально, но я бы предпочел установить систему в целом, чтобы она не была такой хакерской.
Спасибо за любую помощь. Кажется, это должно быть легко (НЕ).
РЕДАКТИРОВАТЬ - РЕШЕНО
Хорошо, я понял это. Кажется, это проблема с CentOS 6 или, возможно, с конфигурацией моей машины. В конфигурации CentOS 5 я могу установить /etc/security/limits.conf
:
* - nproc unlimited
и это будет эффективно обновлять счета и лимиты cron. Тем не менее, это не работает в моей коробке CentOS 6. Вместо этого я должен сделать:
myname1 - nproc unlimited
myname2 - nproc unlimited
...
И все работает как положено. Может быть, спецификация UID работает, но подстановочный знак (*) определенно НЕ здесь. Как ни странно, подстановочные знаки работают на nofile
пределе.
Я все еще хотел бы знать, откуда на самом деле берутся значения по умолчанию, потому что по умолчанию этот файл пуст, и я не мог понять, почему у меня были разные значения по умолчанию для двух ящиков CentOS, которые имели идентичное оборудование и были от одного и того же провайдера. ,
/etc/security/limits.d/
?Ответы:
Эти ограничения по умолчанию применяются:
init
процессе),fork(2)
время),setrlimit(2)
).Процессы обычных пользователей не могут превышать жесткие пределы.
Ядро Linux
Во время загрузки Linux устанавливает ограничения по умолчанию для
init
процесса, которые затем наследуются всеми другими (дочерними) процессами. Чтобы увидеть эти ограничения:cat /proc/1/limits
.Например, ядро по умолчанию для максимального количества дескрипторов файлов (
ulimit -n
) было 1024/1024 (мягкое, жесткое) и было повышено до 1024/4096 в Linux 2.6.39.Максимальное количество процессов, о которых вы говорите, по умолчанию ограничено примерно:
для архитектур х86 (по крайней мере), но распределений иногда меняет значение ядра по умолчанию, так что проверить ядро исходного кода для
kernel/fork.c
,fork_init()
. Ограничение на количество процессов там называется RLIMIT_NPROC.РАМ
Обычно для обеспечения аутентификации пользователя при входе в систему используется PAM вместе с некоторыми модулями (см.
/etc/pam.d/login
).В Debian, модуль PAM отвечает за установление ограничений здесь:
/lib/security/pam_limits.so
.Эта библиотека будет считывать свою конфигурацию из
/etc/security/limits.conf
и/etc/security/limits.d/*.conf
, но даже если эти файлы пусты, pam_limits.so может использовать жестко закодированные значения, которые вы можете проверить в исходном коде.Например, в Debian библиотека была исправлена так, что по умолчанию максимальное количество процессов (
nproc
) не ограничено, а максимальное количество файлов (nofile
) равно 1024/1024:Итак, проверьте исходный код модуля CentOS PAM (ищите RLIMIT_NPROC).
Однако обратите внимание, что многие процессы не проходят через PAM (обычно, если они не запускаются вошедшим в систему пользователем, например, демоны и, возможно, задания cron).
источник
/etc/initscript
«удобное место для настройки на пределы процесса», настраивается через/etc/sysconfig/ulimit
./proc/1/limits
) начиная с версии 1.1.4 (выпущенной в 2011 году).На RHEL6 (CentOS6) «максимальное количество пользовательских процессов» по умолчанию установлено на 1024.
Вы можете изменить это значение в файле:
Смотрите https://bugzilla.redhat.com/show_bug.cgi?id=432903, если вы хотите пожаловаться на это :)
источник
Когда вы проверили ограничения, использовали ли вы для этого пользователя root?
Из
limits.conf
справочной страницы:Использование явных имен пользователей решило бы проблему в этом случае.
источник
limits.conf
файл пуст (какlimits.d
каталог).Информация об этом ужасна в интернете, вот файл limit.conf, который я создал для Debian Linux, показывая все возможные опции и их максимальные «безопасные» ограничения, соответственно подправьте.
Это самые высокие значения, которые вы можете установить, некоторые вещи хэшируются, активация которых приводит к ошибкам и невозможности войти в вашу консоль, изменить закомментированные параметры на свой страх и риск, но вам это не нужно (по умолчанию неограниченно на большинство)
Я надеюсь, что это кому-то пригодится, поскольку я нигде не смог найти эту информацию, есть 4 часа на изучение этого файла.
источник
ядро / fork.c
На 64 бит Размер резьбы 8192
Теперь я получаю сумму в КБ в делении на 4
Теперь я получил количество страниц
Конечный результат
Таким образом, вы получили параметр thread-max, а предел пользовательского процесса по умолчанию равен половине
Ulimit от корня
источник
Похоже, что /etc/security/limits.conf
http://ss64.com/bash/limits.conf.html
источник
Есть еще одна возможность, что конфигурация для «noproc» не работает во время настройки в /etc/security/limits.conf.
Есть еще один файл, который переопределяет вашу конфигурацию /etc/security/limits.d/90-nproc.conf.
Здесь * config переопределит все, что вы установили в предыдущем файле конфигурации. Так что в идеале вы настраиваете свои настройки в этом файле.
источник