LINUX.ORG.RU
решено Форум — Talks  

limits.conf не нужен?

 , ,


1

1

Обнаружилось, что /etc/security/limits.conf не нужен в связке systemd:

  • Для демонов уже давно не работает. Systemd имеет свои LimitNFILE=123456 в секции [Service]
  • Для юзеров оно практически* не работает: не пробрасывается в gdm session начиная с какого-то апдейта.
     См. комменты [1], [2]. Код ниже просто меняет лимиты для user-level процесса systemd + дочерних ему. 
    mkdir -p /etc/systemd/system/user@1000.service.d/
cat > /etc/systemd/system/user@1000.service.d/limits.conf << EOF
[Service]
LimitNFILE=131072
EOF
systemd daemon-reload
systemd restart user@1000
  • Для пользовательских приложений (запускаемых вне gnome-terminal) и пользовательских сеансов (в т.ч. ssh) действуют обычные законы limits.conf.


Всё правильно написал? Пора переписывать все %DISTR% wiki?

-----
* Однако, работает при логине через голую консоль (ctrl+alt+f3). UPD И через ssh при UsePAM=true

★★★★★

Последнее исправление: shahid (всего исправлений: 3)

Ответ на: комментарий от bl

Пока да, но это зависит от UsePAM=.

shahid ★★★★★
() автор топика

Про юзеров неправда. Лимиты на user@ — это для самого процесса systemd (пользовательского; и дочерних, видимо, т. е. в лучшем случае, начиная с dbus 1.10, ещё и дбас-активируемых кусков DE, но не более того).

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1) 
LIMITS.CONF(5)                                            Linux-PAM Manual                                            LIMITS.CONF(5)

NAME
       limits.conf - configuration file for the pam_limits module


Я конечно не эксперт, но мне кажется, что настройки из этого файла никто не читает, если мы не проходили AAA через PAM (с правилом pam_limits). Службы systemd очевидно, не проходят AAA через PAM на машине, на которой они работают. Почему gdm при AAA не использует правило pam_limits не знаю, возможно это баг.

d_a ★★★★★
() 
> ls /etc/security/limits.conf
ls: невозможно получить доступ к /etc/security/limits.conf: Нет такого файла или каталога
> find /etc/ -iname '*limits*' -type f
/etc/limits
> find /usr/ -iname '*systemd*'
>

Так тоже бывает. Ни systemd, ни /etc/security/limits.conf.

saahriktu ★★★★★
()
Ответ на: комментарий от saahriktu

Давай я снесу линукс, накачу оффтопик, а потом приду и скажу — смотрите, так тоже бывает, никакого баша и файнда!11

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Ну и где здесь логика? Автор темы подаёт вопрос так, что, якобы, до прихода systemd сабжевый файл был нужен, а с приходом systemd он стал бесполезен. В заголовке темы вопрос именно про нужность сабжевого файла как без systemd, так и при наличии systemd. В одном случае, якобы, нужен, а в другом - когда в системе уже есть systemd - уже нет. А я уточняю, что можно и без systemd и без сабжевого файла. Само по себе наличие или отсутствие systemd ещё не указывает на то, нужен этот файл в системе или нет.

saahriktu ★★★★★
()
Ответ на: комментарий от intelfx

Лимиты на user@ — это для самого процесса systemd (пользовательского; и дочерних, видимо, т. е. в лучшем случае, начиная с dbus 1.10, ещё и дбас-активируемых кусков DE, но не более того).

Т.е. лимиты для всего пользовательского в DE, что мы и наблюдаем в свежем арче.

shahid ★★★★★
() автор топика
Ответ на: комментарий от saahriktu

В заголовке темы вопрос именно про нужность сабжевого файла как без systemd, так и при наличии systemd.

Я в заголовке не стал теги дублировать.

shahid ★★★★★
() автор топика
Ответ на: комментарий от d_a

Службы systemd очевидно, не проходят AAA через PAM на машине, на которой они работают. Почему gdm при AAA не использует правило pam_limits не знаю, возможно это баг.

gdm действительно дергает pam_limits через цепочку inlude'ов.
В логах при включенном debug это видно:

дек 16 12:28:59 pekarnya gdm-password][7362]: pam_limits(gdm-password:session): reading settings from '/etc/security/limits.conf'
дек 16 12:28:59 pekarnya gdm-password][7362]: pam_limits(gdm-password:session): reading settings from '/etc/security/limits.d/10-gcr.conf'
дек 16 12:28:59 pekarnya gdm-password][7362]: pam_limits(gdm-password:session): checking if user is in group users
дек 16 12:28:59 pekarnya gdm-password][7362]: pam_limits(gdm-password:session): process_limit: processing - memlock 1024 for GROUP
дек 16 12:28:59 pekarnya gdm-password][7362]: pam_limits(gdm-password:session): reading settings from '/etc/security/limits.d/50-user.conf'
дек 16 12:28:59 pekarnya gdm-password][7362]: pam_limits(gdm-password:session): process_limit: processing - nofile 131072 for USER
дек 16 12:28:59 pekarnya gdm-password][7362]: pam_unix(gdm-password:session): session opened for user user by user(uid=0)
дек 16 12:28:59 pekarnya systemd-logind[677]: New session c4 of user user.

Но эти выставленные лимиты сбрасываются systemd, т.е. оно не работает ни разу в gnome-terminal:
$ ulimit -n
1024

Усугубляет, что весь инет завален документацией по старыми лимитам, которые не работают.

shahid ★★★★★
() автор топика
Ответ на: комментарий от shahid

Нет, далеко не для всего. Терминал — это исключение: у GNOME эмулятор терминала клиент-серверный на манер urxvtd, и сервер как раз дбас-активируемый.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

Мне нужно было limit'ы расширить для intellij idea, у неё inotify сбоил из-за max open files. После выставления лимитов через systemd — косяк вроде бы исчез, но надо ещё понаблюдать.

upd: хотя потыкал ещё раз, есть сомнения некоторые на этот счет.

shahid ★★★★★
() автор топика
Последнее исправление: shahid (всего исправлений: 1)
Ответ на: комментарий от shahid

Сейчас проэкспериментировал: выставил LimitNOFILE= у user@, рестартнул всё, запустил терминал — в нём новое значение, запустил xterm через Alt+F2 — в нём старое значение. Арч-тестинг, везде плюс-минус дефолт.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от shahid

Да вроде как раз наоборот: systemd в чужих процессах ничего не сбрасывает, лимиты из pam_limits применяются везде, где должны...

intelfx ★★★★★
()

Это же гут! Можно выставлять для отдельных сервисов. Раньше такие танцы через скрипты делались.

zloelamo ★★★★
()
Ответ на: комментарий от intelfx

Не, я согласен что это правильно: можно одним взмахом и демонами, и docker-контейнерами овладевать.

«Сложно» получилось с точки зрения systemd-обывателя. Если idea запускаю из gnome-terminal, то одни лимиты, если напрямую — то другие.

Добавлю в шапку инфу-опровержение. Спасибо за то, что указали на мой косяк.

shahid ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Talks