Управление пользовательской сессией из systemd

И чо? В sysvinit есть этих special: boot, bootwait, off, ondemand, initdefault, sysinit, powerwait, powerfail, powerokwait, powerfailnow, ctrlaltdel, kbreques

Итого: 12. У systemd: 38.

Наверное, ты еще и считаешь, что у sysvinit и systemd размер кода одного порялка?

Я считаю что у sysvinit и systemd разница в возрасте одного порядка. Еще я считаю что sysvinit в нынешнем виде бесполезен,, даже с его 12ю специальными таргетами :D, и что давно пора написать новый. systemd? Пусть будет он.

s/IPC/IPS/g

я считаю что sysvinit в нынешнем виде бесполезен

У меня всё крепнет уверенность, что ты просто не умеешь считать ;)

У меня всё крепнет уверенность, что ты меня постоянно тголлишь :D

Это баг, который надо фиксить, а не приводить в качестве «аргумента».

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

Во вторых в том и состоит роль системы инициализации, что она должна переносить решение стандартных задач на свой уровень, а не требовать повторных самореализаций в каждом скрипте.

я её ощущаю в другом месте, не у себя на машинах %)

Я её ощущаю только на лоре в срачах. А так за полтора года, что её использую, ну... разве только пару раз юз-флаги у ебилда поменял.

не луддиты, но скептики, ибо профита от юзания оной в адекватных и массовых юзеркейсах не наблюдается, а гибкость, увы, сокращается(даже если systemd и работала бы идеально, чего не наблюдается)

Может быть и скептики, но это явно не местный случай. К тому же скрипты ни у кого не отнимали. Ставь systemd-sysvinit и радуйся костыл^Wгибкости.

С учетом всех этих гвоздями прибитых таргетов я подобное реализовать в рамках systemd смогу?

А в чем трудность?

[Unit] Description=Мой жирный сетевой сервис After=syslog.target network.target

[Service] Type=forking PIDFile=/run/mrtg.pid ExecStart=/etc/init.d/mrtg start ExecStop=/etc/init.d/mrtg stop

[Install] WantedBy=multi-user.target

Имеет ли смысл на него мигрировать, если нет необходимости в разруливании проблем при очередном обновлении системы?

Нет. Смысла мигрировать не имеет. Потому как если работает текущая система инициализации без учка и задоринки, то и пусть работает.

У меня всё крепнет уверенность, что ты меня постоянно тголлишь :D

Нет ты. sysvinit бесполезен, афигеть. Бесполезен, например, loadlin - его время просто прошло. А sysvinit работает себе и есть не просит. У него есть проблемы - ну так и у systemd они есть, и Рейзер гарантирует, что появится еще больше.

А вообще прикольная идея - сделать интерпретатор юнитов systemd и гонять их через #!/bin/sdunit :)

Думаю, что php для этого подойдёт идеально.

Самая надежная система для десктопа — ОС Windows! WAIT... OH SHI~

Была бы она открытая, или хотя бы открытый бактрекер, да хотя бы просто нружна своим разработчикам, она была бы прилично надёжней, чем она есть сейчас.

PS Я, кстати не слышал, чтобы инит винды часто отваливался.

Функционал, которым не пользуются, потому что реализовали по другому (или на который вообще забили, привет respawn) - дурной признак. Разумеется, оно успешно выполняет действия, которые должен выполнять init, как процесс с pid=1. Но как штука, которая стартит сервисы он действительно бесполезен. Хватает только на запуск rc и getty

С учетом всех этих гвоздями прибитых таргетов я подобное реализовать в рамках systemd смогу?

Да. Внезапно в таргете ты можешь использовать любой свой костыль.

rm -rf /* в функцию старта в любом инит скрипте.

Скорее всего можно даже в конфиги что-нибудь прописать, ибо проверок в инит-скриптах никаких.

Жопа в том, что НИКАКИХ процессов не порождается. Создали ramdisk, смонтировали, развернули файлы. Все. При стопе - все наоборот.

как штука, которая стартит сервисы он действительно бесполезен

А еще он кофе варить не умеет.

Разжую:

1) pid-ов и процессов не порождается (systemd.service - в топку)

2) По сути - это специальное монтирование файловой системы. Но systemd.mount несколько дебилен, чтоб это реализовать.

И что мешает делать это bash-скрипта, пускающего демоны в арче, например?

Например то, что этого никто не сделал? Или то, что майнтайнерам нафиг не уперлось городить очередные костыли на bashе, когда есть уже готовое решение напиши простой конфиг.

Хрен с ним с кофе. Пусть бы сервисы стартил ^_^

Я ничего не понял. В чем суть проблемы?

У меня сервисы вполне стартуют. Наверное, божественное вмешательство - sysvinit же этого не умеет.

Да я тут мануал по этому убожеству почитал. Ну и посмотрел на свои init-скрипты. Теперь вот думаю - сразу на (Free|Net|Open)BSD или помучаться?

Задача: написать systemd.unit, который создает ramdisk и разворачивает в него бэкап с жесткого при старте. Создает бэкап на жесткий и прибивает ramdisk при стопе. Стартует ДО cron-а (потому-как MRTG из крона запускается).

Пока просветов не вижу.

Нашел.

systemd.service: Type=oneshot

Создай юнит на монтирование\размонтирование.

Создай юнит на бэкап, укажи что он запускаетсятолько после монтирования

Запускай крон после них.

«Не преумножай сущностей сверх необходимого» - не?

2) По сути - это специальное монтирование файловой системы. Но systemd.mount несколько дебилен, чтоб это реализовать.

Можно. Посмотри любой .service который должен сделать однократное действие без демонизации чего-либо для образца. Впиши в ExecStart свой скрипт монтирования/копирования. А в ExecStop размонитирование.

А как же православный юникс-вей, каждый юнит делает своё дело, но делает это хорошо?

Тебе шашечки, или на форуме ныть?

Мне - ехать ;-).

Нашел уже.

А оно и делает ОДНО действие - разворачивает пригодную для работы MRTG файловую систему.

Как раз таки нет, ибо каждый из них выполняет свою функцию, не вмешиваюсь в остальные. Инит на баше может загнуться где-нибудь посередине и всё встанет

Сервисы у тебя стартуются набором костылей, скорее всего дебиановским :]

Мне - ехать ;-).

Мне сначала так не показалось, но я рад, что ошибся.

Нашел уже.

Напиши, получилось в результате то, что ты хотел, или нет.

Формально монтирование+копирование это всё-таки два действия.

Таки одну. Фенька - а я сервис иногда руками перезапускаю. С попутным расширением рамдиска.

А инит не на баше и не загнется. Ибо отлажен и отрабатывает коды возвратов.

Напиши, получилось в результате то, что ты хотел, или нет.

Неначем проверять - пока только «соломки подстелить». Хоть у меня и большие сомнения в скором переходе Debian на systemd, но сани готовить надо таки летом.

Таки одну. Фенька - а я сервис иногда руками перезапускаю. С попутным расширением рамдиска.

http://0pointer.de/public/systemd-man/systemd.target.html

А инит не на баше и не загнется. Ибо отлажен и отрабатывает коды возвратов.

Если руки растут откуда надо, можно и из ... конфетку сделать:)

Ну вот пример моего костыля классического:

$ cat /etc/systemd/system/zswap.service 
[Unit]
Description=zRam based swap
DefaultDependencies=no
Before=shutdown.target local-fs.target

[Service]
Type=oneshot
RemainAfterExit=yes
ConditionPathExists=/dev/zram0
EnvironmentFile=-/etc/conf.d/zswap
ExecStart=/bin/sh -c "echo -n $SIZE > /sys/class/block/zram0/disksize"
ExecStart=/sbin/mkswap /dev/zram0
ExecStart=/sbin/swapon /dev/zram0
ExecStop=/sbin/swapoff /dev/zram0
ExecStop=/bin/sh -c "echo -n 1 > /sys/class/block/zram0/reset"

[Install]
WantedBy=sysinit.target

Только за уродский ini Поцеринга следовало бы сжечь.

Да, я тоже жалею что там не xml :(

Для сравнения - BSD-шный rc-ng:

#!/bin/sh
#
# Add additional swap files
#
# $FreeBSD: src/etc/rc.d/addswap,v 1.7.12.1 2010/02/10 00:26:20 kensmith Exp $
#

# PROVIDE: addswap
# REQUIRE: FILESYSTEMS
# BEFORE: sysctl
# KEYWORD: nojail

. /etc/rc.subr

name="addswap"
start_cmd="addswap_start"
stop_cmd=":"

addswap_start()
{
        case ${swapfile} in
        [Nn][Oo] | '')
                ;;
        *)
                if [ -w "${swapfile}" ]; then
                        echo "Adding ${swapfile} as additional swap"
                        mdev=`mdconfig -a -t vnode -f ${swapfile}` && swapon /dev/${mdev}
                fi
                ;;
        esac
}

load_rc_config $name
run_rc_command "$1"

Вполне наглядно и компактно, есть лучшие варанты?

Никакой формализации, да

Это не проблема. Все-равно ее используют через Putty, так-что какая разница, как там все работает?

Учитывая, что об этом трындят только линуксоиды, то становится даже интересно - а знают ли BSD'шники про putty и не банальный ли это перенос своего опыта делают Linux'оиды?

Все обсуждается по открытым каналам, задолго до начала работы. Когда одни переспорили других, это не насилие.

А мне вот интересно, теперь если systemd почему-то упадет, мы получим аналог BSOD? :)

Да.

Kernel panic - not syncing: Attempted to kill init!

Стабильно. Надёжно. Ынтырпрайзно.

Зато нормальный shell-синтакс. С дополнительными значимыми переменными. И никаких win.ini-like свистелок и перделок.

Только за уродский ini Поцеринга следовало бы сжечь.

Да, я тоже жалею что там не xml :(

Ну с тобой-то всё ясно, а кто еще жалеет?