Как в Альте правильно создать swap ?

[Speccyfighter]

Юмор в том, что альты в сизифе линкуют не только /var/run, но и /var/lock:
https://bugzilla.altlinux.org/show_bug.cgi?id=32358#c5

А что плохого в /var/lock на tmpfs?

Ты не видишь всё это в целом. Это всё теория.
А это уже не теория

К сожалению, эксперимент с L+ в tmpfiles закончился неудачно.
Так что остаётся только один способ мигрировать - в initrd.
Как оставить существующие системы жить по-старому (с mount -o bind), а новые
установки на симлинках я не знаю.

И Михаил, на мой взгляд, слишком оптимистичен

2 ldv@ и shaba@: коллеги, исправьте всё-таки сломанное в августе.

У нас всё это время http://altlinux.org/rescue грузится так, что я бы сам
испугался и поискал какой-нибудь менее сломанный на вид инструмент.

Ещё один костыль

В rescue свой rc.sysinit.rescue, который совсем не использует cleanup, и
соответственно не запускает systemd-tmpfiles.
Для rescue тебе надо где-то самостоятельно создать симлинки.

А как результат, sysv в сизифе вдребезги разломан.

Я впервые за последние 11 лет установил себе на usb-hdd другой линукс на посмотреть: devuan-2.0.0-ascii. И это не случайность.

[asy]

Ты не видишь всё это в целом. Это всё теория.

Даже теряюсь с ответом. :)

Если решено /var/lock выносить на tmpfs, надо просто выносить /var/lock на tmpfs. И всё. Остальное - лирика.

А это уже не теория

Это - попытка сделать при обновлении. Но это можно и не делать по большому счёту.

А как результат, sysv в сизифе вдребезги разломан.

Значит надо просто починить.

[Speccyfighter]

Остальное - лирика.

Я бы не сказал:

К сожалению, эксперимент с L+ в tmpfiles закончился неудачно.
Так что остаётся только один способ мигрировать - в initrd.
Как оставить существующие системы жить по-старому (с mount -o bind), а новые
установки на симлинках я не знаю.

В rescue свой rc.sysinit.rescue, который совсем не использует cleanup, и
соответственно не запускает systemd-tmpfiles.

Насколько увидел в devuan, дебианисты этот фарш выкручивали через функцию run_migrate из /lib/init/mount-functions.sh на 676 строк, который в пакете initscripts.

[asy]

Я бы не сказал:

Ещё раз: это про миграцию. Но можно и не мигрировать, а оставить, как есть. И симлинк делать только в новой инсталляции. Вот resque надо чинить будет, да. Хотя там, напротив, никто симлинк и не заставляет делать.

[Speccyfighter]

Я бы не сказал:

Ещё раз: это про миграцию. Но можно и не мигрировать, а оставить, как есть.

А-а... Ну успехов:

Код: [Выделить]

# rpm -qf /lib/tmpfiles.d/{var,legacy}.conf
systemd-utils-239-alt2.i586
systemd-utils-239-alt2.i586


Код: [Выделить]

# apt-get remove systemd-utils -s | grep ^Remv | wc -l
109

Или предлагаешь altlinux::ppa ?

[asy]

А-а... Ну успехов:

Код: [Выделить]

# rpm -qf /lib/tmpfiles.d/{var,legacy}.conf
systemd-utils-239-alt2.i586
systemd-utils-239-alt2.i586


Код: [Выделить]

# apt-get remove systemd-utils -s | grep ^Remv | wc -l
109
Или предлагаешь altlinux::ppa ?

А при чём это тут ? Обработку tmpfiles.d добавить в хоть rc.sysinit - это проблема?

[Speccyfighter]

А-а... Ну успехов:

Код: [Выделить]

# rpm -qf /lib/tmpfiles.d/{var,legacy}.conf
systemd-utils-239-alt2.i586
systemd-utils-239-alt2.i586


Код: [Выделить]

# apt-get remove systemd-utils -s | grep ^Remv | wc -l
109
Или предлагаешь altlinux::ppa ?

А при чём это тут ?

При том что линковка отрабатывает безусловно.

Обработку tmpfiles.d добавить в хоть rc.sysinit - это проблема?

Проблема что нужно делать проверку на /sbin/init, до того как стартанёт хоть один сервис: если systemd, то линкуем, если init, то не линкуем. При этом, /var/{lock,run} уже призраки, в filesystem их нет. И желательно сделать так, чтобы не трогать rc.sysinit.rescue.

[Speccyfighter]

При этом, то что есть с L, эта линковка не сработает для мигрантов p6>p9. /var/{lock,run} у них уже есть и это каталоги. А как писал shaba@, "с L+ в tmpfiles закончился неудачно". А без L+, облом на миграции с systemd на sysv:
https://forum.altlinux.org/index.php?topic=36177.msg330384#msg330384
https://forum.altlinux.org/index.php?topic=36177.msg330414#msg330414

[Speccyfighter]

При этом, то что есть с L, эта линковка не сработает для мигрантов p6>p9. /var/{lock,run} у них уже есть и это каталоги. А как писал shaba@, "с L+ в tmpfiles закончился неудачно". А без L+, облом на миграции с systemd на sysv:
https://forum.altlinux.org/index.php?topic=36177.msg330384#msg330384
https://forum.altlinux.org/index.php?topic=36177.msg330414#msg330414

Проблема в том, что в sysv, subsys ничто не создаёт

Код: [Выделить]

+%attr(0755,root,root) %dir /run/lock %ghost
+%attr(0755,root,root) %dir /var/lock %ghost
+%attr(0770,root,uucp) %dir /var/lock/serial %ghost
+%attr(0700,root,root) %dir /var/lock/subsys %ghost
+%attr(0770,root,uucp) %dir /var/lock/uucp %ghost
+%attr(0755,root,root) %dir /var/run %ghost

в sysv он уже есть

Код: [Выделить]

$ rpm -qvl filesystem | grep 'var/lock\|var/run'
drwxr-xr-x    2 root    root                0 фев 11  2016 /var/lock
drwxrwx---    2 root    uucp                0 фев 11  2016 /var/lock/serial
drwx------    2 root    root                0 фев 11  2016 /var/lock/subsys
drwxrwx---    2 root    uucp                0 фев 11  2016 /var/lock/uucp
drwxr-xr-x    2 root    root                0 фев 11  2016 /var/run

а без subsys, sysv поперхнётся на старте.

[S3R_sqrT]

пока что не смог найти приоритет/время, что бы серьезно этим занятся, так что продолжу с простого:
1. Чтото лежит в свапе.
2. Оно было вытянуто оттуда в RAM.
3. Оно должно было удалиться из свапа, но этого НИКОГДА не случается {проблема}.
как это исправить? (т.е. свап просто захламляется до полноты и системан намертво виснет)

[Speccyfighter]

как это исправить?

Костылём для пингвина:
Самописным скриптом повешенным в cron, который будет анализировать /proc/meminfo и выполнять действия по ситуации.
Но помните: есть риск повышения нагрузки по I/O, а это не лучшим образом сказывается на производительности системы.

Можно смотреть на zswap и zram,
https://wiki.archlinux.org/index.php/swap#Using_zswap_or_zram
но zram  решает вопрос производительности, но не свободной памяти.

[S3R_sqrT]

самописный скрипт - жуть прямо! это ведб настолько логично, чтоб по умолчанию такая функция была... какой смысл в свапе, что бы только забивать его до отказа..?
наверно, месяц-3й пройдет, пока доберусь до написания такого скрипта...

[asy]

Обработку tmpfiles.d добавить в хоть rc.sysinit - это проблема?

Проблема что нужно делать проверку на /sbin/init, до того как стартанёт хоть один сервис: если systemd, то линкуем, если init, то не линкуем. При этом, /var/{lock,run} уже призраки, в filesystem их нет. И желательно сделать так, чтобы не трогать rc.sysinit.rescue.

Так... А у нас rc.sysinit в startup, а не в sysvinit, оказывается. Что-то не задумывался. Ну сделать проверку, в конце концов.

[asy]

3. Оно должно было удалиться из свапа, но этого НИКОГДА не случается {проблема}.

А кто сказал, что это проблема? Ну валяется мустор в свопе, и пусть валяется. Понадобится место - удалится.

(т.е. свап просто захламляется до полноты и системан намертво виснет)

А вот это вот уже совсем другое дело. Это значит, что там не мусор, а реально своп используется. Надо выяснять, кто память так потребляет. Вроятно, что у какого-то приложения течёт.

Кстати, есть такой костыль - https://github.com/Tookmund/Swapspace. Как раз своп добавлять на лету для протекающих приложений, а-ля FireFox. Только в ALT не собрано. Хотя, может, есть в autoimports.

[S3R_sqrT]

Понадобится место - удалится.

Это значит, что там не мусор, а реально своп используется.

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