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~~

Ссылка

←	Гуглопереводчик недостаточно офигенен

виниловый проигрыватель.

→

при логине по ссш работают?

bl ★★★
(16.12.15 13:13:18 MSK)

Ответ на: комментарий от bl 16.12.15 13:13:18 MSK

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

shahid ★★★★★
(16.12.15 13:14:51 MSK) автор топика

Ссылка

Ретроград!

Shadow ★★★★★
(16.12.15 13:41:33 MSK)

Ссылка

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

intelfx ★★★★★
(16.12.15 14:25:13 MSK)
Последнее исправление: intelfx 16.12.15 14:26:06 MSK (всего исправлений: 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 ★★★★★
(16.12.15 14:25:31 MSK)

Ответ на: комментарий от d_a 16.12.15 14:25:31 MSK

+1. Видимо, нужно глянуть в /etc/pam.d/gdm.

intelfx ★★★★★
(16.12.15 14:26:40 MSK)
Последнее исправление: intelfx 16.12.15 14:29:15 MSK (всего исправлений: 1)

Ссылка

ТОЛЬКО ВЫИГРАЛИ

~~Spoofing~~ ★★★★★
(16.12.15 14:27:21 MSK)

Ссылка

> 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 ★★★★★
(16.12.15 14:49:28 MSK)

Ответ на: комментарий от saahriktu 16.12.15 14:49:28 MSK

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

intelfx ★★★★★
(16.12.15 14:57:16 MSK)

Ответ на: комментарий от intelfx 16.12.15 14:57:16 MSK

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

saahriktu ★★★★★
(16.12.15 15:24:14 MSK)

Ответ на: комментарий от intelfx 16.12.15 14:25:13 MSK

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

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

shahid ★★★★★
(16.12.15 16:28:01 MSK) автор топика

Ответ на: комментарий от saahriktu 16.12.15 15:24:14 MSK

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

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

shahid ★★★★★
(16.12.15 16:30:21 MSK) автор топика

Ссылка

Ответ на: комментарий от d_a 16.12.15 14:25:31 MSK

Службы 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 ★★★★★
(16.12.15 16:39:50 MSK) автор топика

Ссылка

Ответ на: комментарий от shahid 16.12.15 16:28:01 MSK

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

intelfx ★★★★★
(16.12.15 16:41:38 MSK)
Последнее исправление: intelfx 16.12.15 16:42:15 MSK (всего исправлений: 1)

Ответ на: комментарий от intelfx 16.12.15 16:41:38 MSK

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

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

shahid ★★★★★
(16.12.15 16:45:28 MSK) автор топика
Последнее исправление: shahid 16.12.15 16:48:08 MSK (всего исправлений: 1)

Ответ на: комментарий от shahid 16.12.15 16:45:28 MSK

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

intelfx ★★★★★
(16.12.15 16:51:06 MSK)
Последнее исправление: intelfx 16.12.15 16:51:43 MSK (всего исправлений: 1)

Ответ на: комментарий от intelfx 16.12.15 16:51:06 MSK

Да, что-то всё намного сложнее получается.

shahid ★★★★★
(16.12.15 16:52:13 MSK) автор топика

Ответ на: комментарий от shahid 16.12.15 16:52:13 MSK

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

intelfx ★★★★★
(16.12.15 16:54:35 MSK)

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

zloelamo ★★★★
(16.12.15 16:56:18 MSK)

Ссылка

Ответ на: комментарий от intelfx 16.12.15 16:54:35 MSK

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

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

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

shahid ★★★★★
(16.12.15 17:27:24 MSK) автор топика