Systemd 29

Очевидно - мержить ихний git одинаковой ревизии и грепать.

>Это неправильно. Должно и так работать.
мир жесток и криво собран. В нем еще много вещей, которые не работают или работаю криво.

Вот когда я иду в суспенд, я выключаю,

руками? А программно вырубить или просто выгрузить модуль не вариант? Зачем лишать себя полезной фичи из-за каких-то криворуких индусов

Событийное управление, кстати, неплохо.
Вот усть у меня, например, съёмный bluetooth-адаптер. В случае с традиционным SysV если я «включил» (добавил в автозагрузку, по-простому) демон bluetooth, то он так и будет висеть в памяти, не зависимо от того, подключен адаптер или нет. В случае с systemd, если включить bluetooth.service, bluez будет стартовать только после подключения адаптера и завершаться по его вытаскиванию. Весьма удобно.

> BIOS не нужен.

Так чего, нечего ответить на это? Так и скажи: «по теме ``systemd на серверах`` слился».

Use coreboot, luke.

Да? Расскажи мне как его водрузить на упомянутый выше блейд и как посмотрит на это Dell в плане продолжения предоставления мне 3-х летней onsite next business day гарантий, посмотрю.

Событийное управление --- это просто прекрасно, лучше не было ещё. Особенно замечательно оно когда грузишь систему через nfsroot и upstart каждый второй раз уходит в race condition. Баги эти между прочим висят уже который год. Ubuntu Server такая Ubuntu Server.

sys-apps/systemd/systemd-29.ebuild

Я уже обновился

> Предположим, я хочу оставить корень и /usr в read-only. Пусть, например, это - дополнительная защита сервера. Или, может, у меня SSD-диск и я хочу избежать лишних операций записи. Для этого мне нужно выполнить несколько действий, смонтировать некоторые каталоги в tmpfs или mount-bind-ом на другие разделы.

Надо сказать, что эта задача выполнялась в 1996 году безо всяких дополнительных сервисов или скриптов. /etc/mtab -> /proc/mounts (да, я в курсе, что они чуть-чуть различаются), tmpfs на /tmp - и всё остальное живёт совершенно прозрачно. А /usr на RO - для этого даже особенных приседаний сделать. Ну, разве что /usr/tmp засимлинкать/за-маунт-биндить на /var/tmp...

А вот ТАКУЮ опцию хваленый systemd распарсит?

LIRCD_OPTIONS="-H devinput -d "/dev/input/`grep bttv /sys/class/input/event*/device/name | cut -f 5 -d /`

Ы-ы-ы, - сказали Суровые Сибирские Мужики...

> упразднение загрузочных bash-скриптов и замена схожим по функциональности кодом на C для управления консолью, установки локали, запуска fsck, монтирования файловых систем и др.;

Не, не нравится мне эта херь. В случае отказа заи.ешься искать причину, распарсивая логику связей и распараллеливания.

при неудачном запуске сервиса попытаться перезапустить его.

а это, вообще, не нужно. Отвалится диск или какое еще железо и можно пол-часа курить ожидая просветления в хардварных таймаутах, чтоб отработали элементарные диагностические команды. Или добьет все нафиг, без шанса восстановить.

Ну вот и причастился.

>руками? А программно вырубить или просто выгрузить модуль не вариант?

Даже не так получается. Его даже если вырубить, то потом нельзя включать, иначе будет фриз. Если он был врублен, то NM рвёт соединение перед суспендом, восстанавливает после резюма, получаю фриз. Модуль выгружать ещё не пробовал, но не думаю, что поможет. Фриз ловится при попытке подключиться после резюма. Так что суспенд или вайфай отменяется.

Какое бы отношение upstart имел к systemd?

>Модуль выгружать ещё не пробовал, но не думаю, что поможет.

Ух ты, чудесно! Выгружать модуль таки помогает.

> Какое бы отношение upstart имел к systemd?

Такая же новая событийная не нужная фигня. Уверен, с ним наделают аналогичных граблей, а потом огребать их будет не Леннарт. Руки прочь от sysvinit!

>> Какое бы отношение upstart имел к systemd?

Такая же новая событийная не нужная фигня.

systemd не событийный. У upstart, кстати, событийная модель какая-то мутная.

> systemd не событийный.

в новости написано:

событийно-ориентированная система параллельного запуска сервисов;

>В случае отказа заи.ешься искать причину, распарсивая логику связей и распараллеливания.

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

Отвалится диск или какое еще железо и можно пол-часа курить ожидая просветления в хардварных таймаутах, чтоб отработали элементарные диагностические команды. Или добьет все нафиг, без шанса восстановить.

Если диск отвалится - как можно убить то что уже убилось ? или у тебя волшебные диски сами приклеятся через пол-часа если сервисы не восстанавливать ? Автовосстановление сервисов - это вообще самая нужная вещь для надежных систем, в случае чего - аппаратный ватчдог проблему должен решать.

>> systemd не событийный.

в новости написано:

Новость писал человек, который не читал документацию к systemd.

http://0pointer.de/blog/projects/systemd.html

<Ъ>

One could say that this way the actual logical dependency tree that exists and is understood by the admin or developer is translated and encoded into event and action rules: every logical «a needs b» rule that the administrator/developer is aware of becomes a «start a when b is started» plus «stop a when b is stopped». In some way this certainly is a simplification: especially for the code in Upstart itself. However I would argue that this simplification is actually detrimental. First of all, the logical dependency system does not go away, the person who is writing Upstart files must now translate the dependencies manually into these event/action rules (actually, two rules for each dependency). So, instead of letting the computer figure out what to do based on the dependencies, the user has to manually translate the dependencies into simple event/action rules.

...

Finally, I fail to see the actual usefulness of the event logic.

</Ъ>

>systemd не событийный

Ещё и как он событийный, потому что сервис активируется сразу, как только активировались зависимости, а если появился запрос на активацию сервиса, то пойдёт запрос к зависимостям.

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

Отчего же не посмотреть? Можно и посмотреть. Это если посмотреть можно. А если посмотреть не получается?

Если диск отвалится - как можно убить то что уже убилось ?

Возьми БД и прогони цикл по старту и убиению так и не не стартовавшего экзепляра. Чем сложнее система, тем больше вероятность получить неконсистентность. Это при том, что, возможно вначале, на момент отказа данные (или даже работоспособность) еще можно было бы восстановить.

или у тебя волшебные диски сами приклеятся через пол-часа если сервисы не восстанавливать ?

и не должны.

Автовосстановление сервисов - это вообще самая нужная вещь для надежных систем, в случае чего - аппаратный ватчдог проблему должен решать.

Теоретик хренов. Для криво-писанных поделок - хороший костыль. Для надежных систем - бесполезная или даже вредная херь.

> А вот ТАКУЮ опцию хваленый systemd распарсит?

Нет, но можно вместо нее использовать правило udev, которое создает симлинк. Более того, оно уже есть. Пиши что-то такое:

LIRCD_OPTIONS="-H devinput -d by-id/usb-Chicony_Electronics_Co.__Ltd._FJ_Camera-event-if00"

>Для криво-писанных поделок - хороший костыль.

Если твои перделки прямые - чего же ты развонялся ? они же в принципе не должны отваливаться.

Для надежных систем - бесполезная или даже вредная херь.

Чего ты вообще можешь знать о надежных системах если несешь такую околесицу.

>LIRCD_OPTIONS="-H devinput -d «/dev/input/`grep bttv /sys/class/input/event*/device/name | cut -f 5 -d /`

Да, я же ещё и не читал это, тут есть узкое место в 'grep bttv'. Не боишься, что отгрепает что-то не то? Лучше написал бы не bttv, а '^точное_название$', если уже такие костыли городишь вместо /dev/input/by-id.

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

Посмотри лог загрузки и скажи, кто и в какой момент в systemd создает /var/lock/subsys?

>Посмотри лог загрузки и скажи, кто и в какой момент в systemd создает

Ты Вангу чтоли во мне увидел ? тут тебе никто не поможет если ты в своем софте не разбираешься.

>Посмотри лог загрузки и скажи, кто и в какой момент в systemd создает /var/lock/subsys?

Этот каталог не создаётся при загрузке, он лежит на ФС с момента распаковки stage.

>> Посмотри лог загрузки и скажи, кто и в какой момент в systemd создает /var/lock/subsys?

Этот каталог не создаётся при загрузке, он лежит на ФС с момента распаковки stage.

Неверно после переезда /var/lock в /run/lock (который на tmpfs). Создается, скорее всего (точно сказать не могу, так как каталог специфичен для RedHat-подобных систем), через /etc/tmpfiles.d, который читается из systemd-tmpfiles-setup.service. Как это видно из лога - не представляю, там «Starting Recreate Volatile Files and Directories».

>Неверно после переезда /var/lock в /run/lock (который на tmpfs). Создается, скорее всего (точно сказать не могу, так как каталог специфичен для RedHat-подобных систем), через /etc/tmpfiles.d, который читается из systemd-tmpfiles-setup.service.

Как раз сегодня не переехал на /run/lock, т.к. он не создавался. Буду копать /etc/tmpfiles.d, юнит systemd-tmpfiles-setup.service у меня присутствует.

ура, появилась новая тема для срача: systemd vs sysvinit.
Лор снова торт!

>Не нужно в init-е. Есть ulatencyd.

который течет, как реки нашей родины

> Лор снова торт!

Ну да, злые модеры потерли over100 сообщений из этого треда, а срач-то как следует ещё не начался!

>Ну да, злые модеры потерли over100 сообщений из этого треда, а срач-то как следует ещё не начался!

Вот блин, а тема-то была 5-ая в топе, а теперь шестая =(

Это для кассира торгующего памперсами.

По существу - например для чего автозапуск сервисов может быть полезен. Возьмем Linux запущенный на гипервизоре

    1 root     init
    2 root     [kthreadd]
    3 root     [ksoftirqd/0]
    4 root     [kworker/0:0]
    5 root     [kworker/u:0]
    6 root     [rcu_kthread]
    7 root     [khelper]
    8 root     [sync_supers]
    9 root     [bdi-default]
   10 root     [kblockd]
   11 root     [khubd]
   12 root     [kswapd0]
   13 root     [fsnotify_mark]
   14 root     [aio]
   15 root     [kworker/u:1]
   21 root     [kworker/0:2]
   26 root     [mmcqd/0]
   27 root     [kjournald]
   71 root     /sbin/getty 38400 tty1 linux
   72 root     -sh
   73 root     /sbin/syslogd -n -m 0
   74 root     /sbin/klogd -n
   98 root     [flush-179:0]
  101 root     Xfbdev :0 -nolisten tcp -mouse tslib,,device=/dev/event0 -screen
  107 root     matchbox-window-manager
  108 root     matchbox-desktop
  109 root     matchbox-panel --orientation south
  111 root     mb-applet-menu-launcher
  112 root     mb-applet-launcher -o -1 -l mbterm.png mb-applet-xterm-wrapper.s
  113 root     mb-applet-clock
  114 root     ps

это обычный Linux бинарно совместимый с любым ранее собранным кодом, но все процессы жестко изолированы микроядром и общение идет через синхронное IPC - падение процесса никак не влияет на другие - микроядро просто не пропустит сообщение в никуда, вся физическая память гарантировано в сохранности, можно спокойно перезапустить поток микроядра а все процессы Linux - это потоки микроядра

[Objects]
       1 f004d62c [Task   ] {KERNEL} R=2
       6 f11e9f78 [Task   ] {sigma0          } R=3
       8 f11e9f30 [Task   ] {moe             } R=3
      1b f11e9ee8 [Task   ] {ned             } R=5
      33 f11e9ea0 [Task   ] {io              } R=3
      3a f11e9e58 [Task   ] {vmlinuz.arm     } R=15
      66 f11e9e10 [Task   ] {init            } R=2
     109 f11e9dc8 [Task   ] {getty           } R=2
     10f f11e9d38 [Task   ] {syslogd         } R=2
     112 f11e9cf0 [Task   ] {klogd           } R=2
     116 f11e9d80 [Task   ] {sh              } R=2
     15d f11e9c18 [Task   ] {Xfbdev          } R=2
     177 f11e9c60 [Task   ] {matchbox-windo  } R=2
     179 f11e9ca8 [Task   ] {matchbox-deskt  } R=2
     17b f11e9bd0 [Task   ] {matchbox-panel  } R=2
     183 f11e9b40 [Task   ] {mb-applet-menu  } R=2
     187 f11e9b88 [Task   ] {mb-applet-laun  } R=2
     18b f11e9ab0 [Task   ] {mb-applet-cloc  } R=2

можно вообще заморозить вызов ядра Linux в планировщике микроядра так как он такой же поток как и его юзерспейсные процессы.

>автозапуск сервисов может быть полезен

В этом как раз и кроется опасность остаться без данных, как впрочем, не узнать вовремя о кривом сервисе.

ЗЫЖ кому удобно пусть используют. Добивает как раз именно политика навязывания ненужны мне фич.

> после переезда /var/lock в /run/lock (который на tmpfs). Создается, скорее всего (точно сказать не могу, так как каталог специфичен для RedHat-подобных систем), через /etc/tmpfiles.d, который читается из systemd-tmpfiles-setup.service.

Среди /etc/tmpfiles.d его тоже нет. И дело в том, что если грузиться с systemd, то он создается, а если с upstart - то нет. Вопрос - какая часть systemd его создает, как найти, куда копать? Блин, как же без systemd было просто...

>Лучше бы вместо этих «возможностей» назвали бы хотя бы несколько задач, которые systemd решает лучше, чем то, что было до него. Такие вообще есть?

Задача у него одна - стартовать и останавливать систему. Лучше или хуже он ее выполняет? Я пока на 100% не уверен, надо больше тестировать.

Но некоторые моменты выглядят в systemd заметно лучше.

1) вопросы последовательности запуска сервисов, вернее, зависимости друг от друга. В системд реализовано самое грамотное на мой взгляд
решение.

2) описание сервисов. В системд сервис, это конфиг, а не скрипт. На мой взгляд, это сранимо с введением менеджера пакетов вместо инсталляторов.

Для сранения один и тот же rsyslog:

systemd:


cat /lib/systemd/system/rsyslog.service
[Unit]
Description=System Logging Service

[Service]
EnvironmentFile=-/etc/sysconfig/rsyslog
ExecStartPre=/bin/systemctl stop systemd-kmsg-syslogd.service
ExecStart=/sbin/rsyslogd -n $SYSLOGD_OPTIONS
Sockets=syslog.socket

[Install]
WantedBy=multi-user.target

init.d:

cat /etc/init.d/rsyslog
#!/bin/bash
#
# rsyslog Starts rsyslogd/rklogd.
#
#
# chkconfig: 2345 12 88
# description: Syslog is the facility by which many daemons use to log \
# messages to various system log files. It is a good idea to always \
# run rsyslog.
### BEGIN INIT INFO
# Provides: $syslog
# Required-Start: $local_fs
# Required-Stop: $local_fs
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: Enhanced system logging and kernel message trapping daemons
# Description: Rsyslog is an enhanced multi-threaded syslogd supporting,
# among others, MySQL, syslog/tcp, RFC 3195, permitted
# sender lists, filtering on any message part, and fine
# grain output format control.
### END INIT INFO

# Source function library.
. /etc/init.d/functions

RETVAL=0

start() {
   [ -x /sbin/rsyslogd ] || exit 5

   # Source config
if [ -f /etc/sysconfig/rsyslog ] ; then
. /etc/sysconfig/rsyslog
   fi
   umask 077

echo -n $«Starting system logger: »
daemon rsyslogd $SYSLOGD_OPTIONS
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/rsyslog
return $RETVAL
}
stop() {
echo -n $«Shutting down system logger: »
killproc rsyslogd
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/rsyslog
return $RETVAL
}
reload() {
RETVAL=1
syslog=`cat /var/run/syslogd.pid 2>/dev/null`
echo -n «Reloading system logger...»
if [ -n «${syslog}» ] && [ -e /proc/«${syslog}» ]; then
   kill -HUP «$syslog»;
   RETVAL=$?
fi
if [ $RETVAL -ne 0 ]; then
   failure
else
   success
fi
echo
return $RETVAL
}
rhstatus() {
status rsyslogd
}
restart() {
stop
start
}

case «$1» in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
reload|force-reload)
   reload
   ;;
status)
rhstatus
;;
condrestart)
[ -f /var/lock/subsys/rsyslog ] && restart || :
;;
*)
echo $«Usage: $0 {start|stop|restart|reload|force-reload|condrestart}»
exit 2
esac

exit $?



Есть разница?



3) Заметное расширение общей кодовой базы для всех сервисов позволило значительно улучшить качество и удобство управления системой. Утилита systemctl оставила далеко позади утилиту service.


service rsyslog status
rsyslogd (pid 1727) is running...


systemctl status rsyslog.service
rsyslog.service - System Logging Service
    Loaded: loaded (/lib/systemd/system/rsyslog.service)
    Active: active (running) since Wed, 15 Jun 2011 15:32:00 +0400; 4 days ago
   Main PID: 788 (rsyslogd)
    CGroup: name=systemd:/system/rsyslog.service
       └ 788 /sbin/rsyslogd -n -c 5


Ну есть же разница?

Синтаксис systemd-tmpfiles-setup.service поражает воображение:

ExecStart=/bin/systemd-tmpfiles --create --remove

>В этом как раз и кроется опасность остаться без данных, как впрочем, не узнать вовремя о кривом сервисе.

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

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

Кстати - ты же говорил что у тебя все идеально написано ;-)

>Раньше покопался бы, пока это были баш-скрипты. А что делать теперь? Как вообще искать причину того или иного действия? Как мне сейчас найти, какой скрипт, бинарник или юнит создает каталог /var/lock/subsys?

Точно также. И потом, ты же пользуешься идром, хотя оно написано не на баше...

> Задача у него одна - стартовать и останавливать систему.

Именно. Стартовать и останавливать. И больше ничего. Он не должен управлять приоритетами, он не должен следить за устройствами, он не должен проверять файловые системы, он не должен создавать и удалять файлы и каталоги, он не должен менять метки selinux, не должен монтировать файловые системы. Он должен запускать программы, которые сделают это.

А поскольку это - init-демон, он должен быть максимально простым и понятным.

> вопросы последовательности запуска сервисов, вернее, зависимости друг от друга. В системд реализовано самое грамотное на мой взгляд решение.

Три способа задания этих зависимостей (Before, After и Wants, если я ничего не забыл) плюс симлинки в файловой системе (something.service.wants/something.service). Это и есть самое грамотное решение?

> описание сервисов. В системд сервис, это конфиг, а не скрипт.

И это - ужасно. Пока это был скрипт можно было легко ответить на вопрос, что он делает. А когда это - конфиг, ответить на него просто не возможно.

> Есть разница?

Есть, безусловно. И она - в худшую сторону. С таким же успехом там могло быть:

#!/bin/bash
CHKCONFIG=2345 12 88
PROVIDES=syslog
REQUIRED_START=local_fs
REQUIRED_STOP=local_fs
DESCRIPTION=Enhanced system logging and kernel message trapping daemons
ENVIRONMENT=/etc/sysconfig/rsyslog
EXEC_START='/sbin/rsyslogd -n $SYSLOGD_OPTIONS'
. /etc/init.d/defaultservice

Только в случае скрипта я мог бы открыть этот /etc/init.d/defaultservice и найти там ответы на свои вопросы. А в systemd смотреть некуда.

> Утилита systemctl оставила далеко позади утилиту service

Да? Тогда что видно из такого вывода:

polipo.service - LSB: start and stop Polipo caching web proxy
          Loaded: loaded (/etc/rc.d/init.d/polipo)
          Active: inactive (dead)
          CGroup: name=systemd:/system/polipo.service

>Он не должен управлять приоритетами, он не должен следить за устройствами, он не должен проверять файловые системы, он не должен создавать и удалять файлы и каталоги, он не должен менять метки selinux, не должен монтировать файловые системы. Он должен запускать программы, которые сделают это.

Он и запускает программы, которые это делают. Они лежат в /lib/systemd/systemd-* и делают вышеперечисленное. Эти тоже в свою очередь могут запускать, например, fsck.ext4.

>> Как мне сейчас найти, какой скрипт, бинарник или юнит создает каталог /var/lock/subsys?

> Точно также.

Также это как? Раньше бы я сделал:

grep subsys /etc/rc*

echo '# chkconfig: 2345 50 50' > /etc/init.d/wtf
echo '[ -d /var/lock/subsys ] && echo FOUND IT' >> /etc/init.d/wtf
chkconfig --add wtf
chkconfig wtf on

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

Убит кем и как? Я говорю про сегфолт и попытку поднять при активации сокета.

Кстати - ты же говорил что у тебя все идеально написано ;-)

Вообще-то, я другой анонимус. А вот неудачный старт сервиса вроде mysql - это уже серьёзная проблема, которую надо решать на месте ручками. Перезапусками можно вообще испортить базу.

> Эти тоже в свою очередь могут запускать, например, fsck.ext4.

Неужели не очевидно, что это маразм? Зачем эта лишняя прослойка Почему вместо того, чтобы запустить fsck.ext4, нужно запустить скрипт, который запустит программу, которая запустит fsck.ext4?

Или прослойки это круто? Тогда давайте уже не мелочиться. Будем запускать скрипт, который будет запускать программу, которой запишем в конфиг плагин, который будет в виде скрипта и запустит из себя fsck. Можно еще design patterns сюда добавить, чтоб уж по всем правилам. Будет примерно как тут: http://www.phppatterns.com/docs/design/hello_world_in_patterns

>Он и запускает программы, которые это делают. Они лежат в /lib/systemd/systemd-* и делают вышеперечисленное. Эти тоже в свою очередь могут запускать, например, fsck.ext4.

А что, напрямую пускать fsck.ext4 он не умеет? Обязательно заворачивать этот запуск в свой велосипед?

>Почему вместо того, чтобы запустить fsck.ext4, нужно запустить скрипт, который запустит программу, которая запустит fsck.ext4?

Не знаю, почему. Наверное, потому что там всё происходит не так.

systemd запускает systemd-fsck. systemd-fsck запускает fsck.ext4. Все 3 файла - бинарники.

SysVinit запускает скрипт. Скрипт порождает кучу процессов, лагает, запускает fsck. fsck запускает fsck.ext4. 3 бинарника и 1 скрипт.

И какой из этих вариантов лучше? И там, и там 3 бинарника. С SysVinit нужен ещё и скрипт. В systemd не нужны лишние сущности.

>systemd запускает systemd-fsck. systemd-fsck запускает fsck.ext4.

А сразу запустить fsck.ext4 с нужными опциями он не может? Или будет лагать и тормозить? Или надо сначала придумать проблему, а потом её героически решать?

SysVinit запускает скрипт. Скрипт порождает кучу процессов, лагает, запускает fsck. fsck запускает fsck.ext4. 3 бинарника и 1 скрипт.

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

>Именно. Он не должен управлять приоритетами,

Фигасе. Установка приоритета, это часть процедуры запуска.

он не должен следить за устройствами,

Если эти устройства нужны для запуска, то кто же будет за ними следить?

он не должен проверять файловые системы

Это раньше делали rc скрипты. Не вижу разницы.

он не должен создавать и удалять файлы и каталоги, он не должен менять метки selinux, не должен монтировать файловые системы. Он должен запускать программы, которые сделают это.

Он в достаточной степени модулен. В чем разница между внешней программой и модулем, непонятно.

>А что, напрямую пускать fsck.ext4 он не умеет? Обязательно заворачивать этот запуск в свой велосипед?

то есть, перенести код из модуля обратно в основное жирное тело?