Bug 32964

https://yadi.sk/i/tYqr0L2X36iDAL

Вот видео установки батлы... В Реальном времени, под конец отрубилось из-за нехватки места на смарте... Длится около получаса, еще столько-же, если не дольше, продолжало ставится после отруба... Это откровенно ненормально...

Грузился с разными ядрами... SDF, UDF, и всякой "экзотикой"... Но проблему это не исправило...

glib это не тот Glib, которым пользуются ваши графические приложения.
Перевешиваю на пакет, который принято использовать в случаях, когда нет идей, на что лучше повесить баг.

(В ответ на комментарий №3)
> Перевешиваю на пакет, который принято использовать в случаях, когда нет идей,
> на что лучше повесить баг.

ОК.. Про такие тонкости буду знать. :)

По поводу же сабжа, то ситуация с вкладками хорошо на ridus.ru видна, коли что, например, коли там ссылки, во вкладках, открывать...

Это про лимит на кол-во процессов на пользователя, скорее всего.

Попробуйте-ка в /etc/security/limits.d/50-defaults.conf поднять * soft nproc с 512 до 2048 и посмотреть, поможет ли; если да -- перевешивайте на pam.

(В ответ на комментарий №5)
> Это про лимит на кол-во процессов на пользователя, скорее всего.
> 
> Попробуйте-ка в /etc/security/limits.d/50-defaults.conf поднять * soft nproc с
> 512 до 2048 и посмотреть, поможет ли; если да -- перевешивайте на pam.

Простите за задержку... Как руки дошли...

Сделал. Причем выставил 4096 (как, для данной позиции, в подобном файле Росы)...

Никакого эффекта. Как минимум заметного без ядерного микроскопа...

Подмена на Росиный (так лимиты по другому выставлены) также ничего не дали...

Аналогично, в общем, с предложенными, в свое время, Андреем Черепановым (в беседе через личку форума), изменениями /etc/security/limits.conf и /etc/chromium/default (которые, конфиги в дефолтном для Альта виде, вообще, в целом, соответствуют Росиным)...

Вотс... Фиг его зна в чем причина такой аномальщины... Но pam если и вносит свою долю, то явно минимальную...

Кстати говоря... Мне вот что в голову пришло...

Оба примера с явнозамеченными проблемами (хромированные браузеры, и близардовая софта и игры) это интернет приблуды, пускай и разноговида, формы, и расцветки...

Посему, "сетивизмы", разные, виноваты не могут быть?..

Скажем той-же батле могут быть проблемы с "рекламными картинками", ссылками на новости из клиента, и прочее подобное...

В Росе их (этих проблем) нет...

Вот мне, сейчас, и, внезапно, пришло в голову следующие... Может что-то из сетивизмов и рядом с ними прыгающим (там сертиыикатами-шмертиыикатами, и т. п.) поломали-перепатчили? Ну или, наоборот, давно не обновляли, и оно протухло и глючит столкнувшись с изменившимися внешними реалиями?..

Но pam, боюсь, точно не шибко причем...

(В ответ на комментарий №7)
> Но pam, боюсь, точно не шибко причем...
Покажите-ка вывод команды ulimit -a от этого пользователя.

(В ответ на комментарий №8)
> (В ответ на комментарий №7)
> > Но pam, боюсь, точно не шибко причем...
> Покажите-ка вывод команды ulimit -a от этого пользователя.

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 47962
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

(В ответ на комментарий №9)
> > > Но pam, боюсь, точно не шибко причем...
> > Покажите-ка вывод команды ulimit -a от этого пользователя.
> max user processes              (-u) 1024
Это именно про pam_limits.

(В ответ на комментарий №5)
> Это про лимит на кол-во процессов на пользователя, скорее всего.
Собственно, стоило сразу запросить этот вывод -- теперь видно точно.

> Попробуйте-ка в /etc/security/limits.d/50-defaults.conf поднять * soft nproc
> с 512 до 2048 и посмотреть, поможет ли; если да -- перевешивайте на pam.
И ещё "* hard nproc" -- он-то ограничивает жёстко ту же величину.

(В ответ на комментарий №10)
> И ещё "* hard nproc" -- он-то ограничивает жёстко ту же величину.

Поднял.

Вот доказательство:

[andrey@comp-core-i7-603a30 ~]$ ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 47962
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 4096
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

И... Правильно. Никакого эффекта. Как минимум заметного без ядерного микроскопа.

Либо есть еще "хитрые процессы"...

Гляну еще с unlimited (для "гарантированной надежности результата"), конечно... Но, боюсь, эффект будет тот-же...

Так обещанный unlimited.

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 47962
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Во общем вы меня поняли...

Как, честно говоря, уже и ожидалось, никаких "улучшений ситуации" не замечено...

В чем причина фиг его зна... Но pam, походу, не шибко при лелах... Либо есть еще какие "хитрые лимиты"...

Проблема только на Альте... В других дистрах все нормально... Было нормально, повторяю, и на Кентавре (как минимум в первые годы, до выхода Windows 8). В туже Дьяблу играл на ура... И никаких проблем и аномальных дикостей не было...

В чем проблема фиг его зна... В чем-то общесистемном точно. Но в чем непонятно (может в glib, может в "сетевизмах, может еще в чем)"... Выставление лимитов проблему не решают...

ulimit тут правда не при чём.
попробуйте так:
apt-get install tuned
systemctl start tuned
systemctl enable tuned
tuned-adm profile desktop

А что за конфигурация системы ? ядро, железо ?
присоединяйте system-report

Created attachment 6943 [details]
Системный рапорт

(В ответ на комментарий №13)
> ulimit тут правда не при чём.
> попробуйте так:
> apt-get install tuned
> systemctl start tuned
> systemctl enable tuned
> tuned-adm profile desktop

Сделал. Никаких улучшений.

Системный рапорт в атаче.

Мои идеи о том, что это может быть, выше... Но, однозначно, что-то серьезно слолмали в общесистемном. Ибо софт не виноват точно (смотрим выше).

Возможно стоит сравнить, детально, первые кентавры (если сохранились архивы образов и репов того времени (первые годы Кентавра до выхода W8, когда точно все работало нормально...)) и нынешнее...

В Росе на SSD планировщик bfq. У вас (вы Андрей с конем на аватарке?) SSD?

И попробуйте сравнивать
su -
sysprof

в двух дистрибутивах на одинаовых операциях.