dump-sessions и rc.local shutdown

[Pro]

существующий rc.local shutdown  вобще непонятен, в нем выполняется dump-session и сразу выход из скрипта, это правильно, но зачем еще какой-то код ниже тоже связанный с changes=EXIT ?

скрипт dump-session: зачем делался костыль, если в секции #handle whiteouts properly как раз и должно делаться удаление меток .wh.
Так ли уж нужна секция удаления всего из памяти? (Clear tmpfs) ведь при выключении компьютера это и так удалится должно.

[sfs]

1я проблема - выполнение чего-то при выходе
Кстати тут можно отмонтировать сквоши. То что не может сделать systemd... и тормозит и сыплет ошибки
Где-то нарыл исходное решение - дальше экспериментировал
В результате:
/etc/systemd/system/multi-user.target.wants/rc-local-sh.service
В нем

Код

ExecStart=/etc/rc.local.shutdown-
ExecStop=/etc/rc.local.shutdown

Только так у меня rc.local.shutdown- выполнился в нужное время
Чувствую - здесь я накрутил
Ты из manjaro скрипты не анализировал?

Далее в rc.local.shutdown- можно дописать что-то для выполнения при выключении
В rc.local.shutdown - запуск dump-session (скрипт из porteus, возможно что-то переделывал)
В портеус нет systemd - наверное надо понять как там это работает и работает ли
То - что ниже (после exit) - как делал сначала, пока не разобрался

Главный вопрос. То почему я больше к этому не возвращался: Это кому-нибудь нужно?
С rc-local-sh.service надо по любому разобраться

[Pro]

я незнаю к чему эти подробности, но они пригодятся, спасибо.

По моим вопросам есть информация?

[sfs]

существующий rc.local shutdown  вобще непонятен, в нем выполняется dump-session и сразу выход из скрипта, это правильно, но зачем еще какой-то код ниже тоже связанный с changes=EXIT ?

Чтобы не повторять этих ошибок. Можно удалить

скрипт dump-session: зачем делался костыль, если в секции #handle whiteouts properly как раз и должно делаться удаление меток .wh.
Так ли уж нужна секция удаления всего из памяти? (Clear tmpfs) ведь при выключении компьютера это и так удалится должно.

Я с тех пор туда не лазил. Таких деталей уже не помню. Что-то писал на форуме про это
Тут надо -
1. посмотреть как в портеус
2. посмотреть - изменял ли я dump-session

Ты точно уверен что этим EXIT надо заниматься вообще и именно сейчас?
Это не последняя проблема...

[Pro]

Почему то нигде не расписано что такое target на самом деле, таргет это контрольные точки которые наступаю только тогда когда заканчивается запуск предыдущей точки.

Внутри target ты указываешь после какой точки она наступает и возможно еще, какая точка будет следующей.
Все эти точки конечно можно создавать самим и распределять выполняемые процессы на требуемые уровни. Что я и хотел сделать введя точку wm.target после которой считается что запущен xorg и запускается (или уже запущен) оконный менеджер и можно спокойно грузить всякие gxneur и parcellite

Чтобы не повторять этих ошибок. Можно удалить

Это ты мне разрешаешь удалить?

1. посмотреть как в портеус
2. посмотреть - изменял ли я dump-session

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

Это не последняя проблема...

последняя проблема 063 - поправить кнопки в программах, заняться этим?

[sfs]

кто-то оставил рядом старую версию, конечно там твои правки есть, даже подписано Костыль.

Я и оставил  знал что ты "пойдешь по следу"

Это не последняя проблема...

последняя проблема 063 - поправить кнопки в программах, заняться этим?

Так со стандартом не определились. Пока двое за почти то как было
Думаю - trim первоочередное. Займусь в 1ю очередь

61 закрыл
Попробуй  30 

чего-то при выходе
Кстати тут можно отмонтировать сквоши. То что не может сделать systemd... и тормозит и сыплет ошибки

закрыть

Далее актуально 38
По 60 надо определиться

[Pro]

..ять до тех пор пока не будет нормального списка проблем, буду ждать.

Или вести список или не вести ничего уж тогда, нахрен это метание постоянное доставляет ппц. Всякие тут на форуме жужжали "Я захожу, хочу знать за что мне браться и чем помогать" НЕТУ теперь этих пионеров, умотали в даль, а остальным на**ать на этот список, в том числе и мне.

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

[sfs]

Что не так со списком проблем?
Некоторые пункты - просто склерозник для себя
Расплывчатость некоторых пунктов из-за необходимости их предварительного обсуждения
Что сейчас и делаем
Сортировка - по мере поступления , а не по важности

[DdShurick]

 Вы про какой rc.shutdown? Если "классический", то там большая часть это создание сохранёнки. Лично я обхожусь busybox poweroff.

[sfs]

Вы про какой rc.shutdown? Если "классический", то там большая часть это создание сохранёнки.

Не классический, systemd, но основной функционал такой же

Лично я обхожусь busybox poweroff.

Вот поэтому мой 1й вопрос и был : нужен ли кому EXIT. Я тоже не юзаю

[DdShurick]

 Если создание сохранёнки делать отдельным скриптом, то ИМХО не нужен.

[sfs]

Разговор идет об этом функционале
С оговоркой (проблема 35) и костылями работает
Есть подозрение что никто это не юзает.
Поэтому я откладывал проблему на потом. Когда появится опыт с системд и те кто это юзает

[Pro]

товарищ sfs, а ты в курсе что по по принципу "никто не юзает" весь этот дистриб отложить скоро можно будет?

Ты вобще видишь как оно в конечном итоге должно выглядеть? что должно делать уметь, а что не должно, и все такое? конечная цель всех наших телодвижений какая?

[DdShurick]

конечная цель всех наших телодвижений какая?

ИМХО интерес, как это всё будет работать (или не будет)
Вот мнение о systemd и добавлю своё - в "нестандартных" дистрибутивах Linux systemd скорее всего будет вреден, так как написан для "плоских" дистрибутивов и имеет явно серверный уклон.

[sfs]

Я как раз всегда (если знаний и опыта хватает) стараюсь сформулировать цель, а потом к ней идти
http://wiki.puppyrus.org/puppyrus/pra

Модульный frugal, совместимый с Arch Linux (Замороженный Rolling_release) для домашнего использования. Оптимизирован для полной загрузки в RAM. Маленький (<100mb без софта) и быстрый
3 уровня использования PRA

Чем может реализация невостребованных фич привлечь юзеров?
Судя по реакции на sgnfile - имеющийся функционал еще не освоен. Лучше его доводить документировать и шлифовать

А на ближайшую перспективу (раз в пол-года надо обновлять) надо думать о пересборе на свежем срезе ARollbackM и ядре 3.13
К этому моменту надо обобщить и обсудить имеющуюся структуру дистра и т.п
Это скоро надо будет делать. Надо готовиться. Поэтому в масштабные задачи сейчас бы лучше не лезть
Количество полностью своих разработок и так большое. Посмотри тот же runtu и т.п. - все просто собирают чуть свое на стандартных пакетах. У нас же идея изменена.