Оценка плюсов и минусов при переходе Debian на systemd или upstart

[SeHELLioN]

Лично я с SysV init не слезу до последнего, пока уже совсем не прижмет, так как не вижу смысла менять его на что-либо

[sunny_side]

Адаптация Upstart для работы в Debian GNU/kFreeBSD и Debian GNU/Hurd выглядит вполне реальной задачей, что нельзя сказать о systemd.

если принять во внимание ВСЕ зависимости systemd и так скажем "эмоциональный настрой" Поттеринга, то портирование systemd выглядит невыполнимой задачей.
разве что форкнуть его сразу и развивать не синхронизируя с оригинальным systemd, но где тогда найти разработчика со сходным мировозрением, который согласиться развивать такой "комбайн", а главное как придать этому разработчику столько уверенности что бы он также самоотверженно отстаивал(иначе такому монолиту не протянуть долго) его .

Но по нему по крайней мере есть нормальная документация

http://upstart.ubuntu.com/cookbook/ - вроде бы вполне нормальная дока


субъективно systemd мне кажется более жизнеспособным, но вот как его "породнить" с другими системами, это конечно вопрос.
кроме того systemd попроще в использовании  - https://wiki.archlinux.org/index.php/systemd, а это тоже может стать существенным аргументом

[sandaksatru]

Полностью согласен с аргументами Яна Джексона. А вот аргументы Расса Олбери мне кажется излишне поверхностными и предвзятыми. Позвольте прокомментировать некоторые.

вместо запуска всех требуемых зависимостей при старте заданного сервиса, запуск службы в Upstart осуществляется при поступлении события о готовности к работе зависимостей ...

- У меня сразу сложилось такое чувство, что Расс не рассмотрев систему как следует, старается найти любые доводы лишь бы в пользу systemd. Потому как стартовый скрипт в upstart может и ждать запуска зависимостей, и самостоятельно запускать что ему надо. В ней есть гибкая реализация событий и зависимостей, в том числе и от обращения к сокетам.

На systemd уже перешли Fedora, openSUSE, Sabayon, Mandriva, Arch Linux...

- Взывание к стадному рефлексу - разве достойный аргумент от опытного разработчика? Унификация, конечно, упростит процессы поддержки пакетов, но в таком случае зачем тянуть лямку на себя? Если унифицироваться, так около чего-то более классического, типа sysvinit. И upstart по логике более приближен к ней.

Единственное, с чем не могу не согласиться, это его опасения насчет Canonical. Сообщество Debian занимает правильную позицию, что до последнего не вступает в информационные войны между коммерческими компаниями. Хотя с другой стороны никто не мешает, в случае каких-либо финтов Canonical, взять и форкануть upstart, благо кодовая база у него не такая уж и большая (в отличие, кстати, от systemd).

Насчет своего опыта перехода на upstart: вот вам для сравнения два init скрипта из пакета ifupdown для сервиса networking (во вложении).

1) sysvinit: /etc/init.d/networking

#!/bin/sh -e
### BEGIN INIT INFO
# Provides:          networking ifupdown
# Required-Start:    mountkernfs $local_fs urandom
# Required-Stop:     $local_fs
# Default-Start:     S
# Default-Stop:      0 6
# Short-Description: Raise network interfaces.
# Description:       Prepare /run/network directory, ifstate file and raise network interfaces, or take them down.
### END INIT INFO

PATH="/sbin:/bin"
RUN_DIR="/run/network"
IFSTATE="$RUN_DIR/ifstate"

[ -x /sbin/ifup ] || exit 0
[ -x /sbin/ifdown ] || exit 0

. /lib/lsb/init-functions

CONFIGURE_INTERFACES=yes
EXCLUDE_INTERFACES=
VERBOSE=no

[ -f /etc/default/networking ] && . /etc/default/networking

[ "$VERBOSE" = yes ] && verbose=-v

process_exclusions() {
    set -- $EXCLUDE_INTERFACES
    exclusions=""
    for d
    do
   exclusions="-X $d $exclusions"
    done
    echo $exclusions
}

process_options() {
    [ -e /etc/network/options ] || return 0
    log_warning_msg "/etc/network/options still exists and it will be IGNORED! Please use /etc/sysctl.conf instead."
}

check_ifstate() {
    if [ ! -d "$RUN_DIR" ] ; then
   if ! mkdir -p "$RUN_DIR" ; then
       log_failure_msg "can't create $RUN_DIR"
       exit 1
   fi
    fi
    if [ ! -r "$IFSTATE" ] ; then
   if ! :> "$IFSTATE" ; then
       log_failure_msg "can't initialise $IFSTATE"
       exit 1
   fi
    fi
}

check_network_file_systems() {
    [ -e /proc/mounts ] || return 0

    if [ -e /etc/iscsi/iscsi.initramfs ]; then
   log_warning_msg "not deconfiguring network interfaces: iSCSI root is mounted."
   exit 0
    fi

    while read DEV MTPT FSTYPE REST; do
   case $DEV in
   /dev/nbd*|/dev/nd[a-z]*|/dev/etherd/e*)
       log_warning_msg "not deconfiguring network interfaces: network devices still mounted."
       exit 0
       ;;
   esac
   case $FSTYPE in
   nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs|pvfs|pvfs2|fuse.httpfs|fuse.curlftpfs)
       log_warning_msg "not deconfiguring network interfaces: network file systems still mounted."
       exit 0
       ;;
   esac
    done < /proc/mounts
}

check_network_swap() {
    [ -e /proc/swaps ] || return 0

    while read DEV MTPT FSTYPE REST; do
   case $DEV in
   /dev/nbd*|/dev/nd[a-z]*|/dev/etherd/e*)
       log_warning_msg "not deconfiguring network interfaces: network swap still mounted."
       exit 0
       ;;
   esac
    done < /proc/swaps
}

ifup_hotplug () {
    if [ -d /sys/class/net ]
    then
       ifaces=$(for iface in $(ifquery --list --allow=hotplug)
             do
                link=${iface##:*}
                link=${link##.*}
                if [ -e "/sys/class/net/$link" ] && [ "$(cat /sys/class/net/$link/operstate)" = up ]
                then
                   echo "$iface"
                fi
             done)
       if [ -n "$ifaces" ]
       then
      ifup $ifaces "$@" || true
       fi
    fi
}

case "$1" in
start)
   if init_is_upstart; then
      exit 1
   fi
   process_options
   check_ifstate

   if [ "$CONFIGURE_INTERFACES" = no ]
   then
       log_action_msg "Not configuring network interfaces, see /etc/default/networking"
       exit 0
   fi
   set -f
   exclusions=$(process_exclusions)
   log_action_begin_msg "Configuring network interfaces"
   if ifup -a $exclusions $verbose && ifup_hotplug $exclusions $verbose
   then
       log_action_end_msg $?
   else
       log_action_end_msg $?
   fi
   ;;

stop)
   if init_is_upstart; then
      exit 0
   fi
   check_network_file_systems
   check_network_swap

   log_action_begin_msg "Deconfiguring network interfaces"
   if ifdown -a --exclude=lo $verbose; then
       log_action_end_msg $?
   else
       log_action_end_msg $?
   fi
   ;;

reload)
   process_options

   log_action_begin_msg "Reloading network interfaces configuration"
   state=$(cat /run/network/ifstate)
   ifdown -a --exclude=lo $verbose || true
   if ifup --exclude=lo $state $verbose ; then
       log_action_end_msg $?
   else
       log_action_end_msg $?
   fi
   ;;

force-reload|restart)
   if init_is_upstart; then
      exit 1
   fi
   process_options

   log_warning_msg "Running $0 $1 is deprecated because it may not re-enable some interfaces"
   log_action_begin_msg "Reconfiguring network interfaces"
   ifdown -a --exclude=lo $verbose || true
   set -f
   exclusions=$(process_exclusions)
   if ifup -a --exclude=lo $exclusions $verbose && ifup_hotplug $exclusions $verbose
   then
       log_action_end_msg $?
   else
       log_action_end_msg $?
   fi
   ;;

*)
   echo "Usage: /etc/init.d/networking {start|stop|reload|restart|force-reload}"
   exit 1
   ;;
esac

exit 0

# vim: noet ts=8

[свернуть]

2) upstart: /etc/init/networking.conf

# networking - configure virtual network devices
#
# This task causes virtual network devices that do not have an associated
# kernel object to be started on boot.

description   "configure virtual network devices"

emits static-network-up
emits net-device-up

start on (local-filesystems
      and (stopped udevtrigger or container))
stop on unmounted-remote-filesystems

pre-start script
    mkdir -p /run/network
    ifup -a
end script

post-stop script
    log_warning_msg() {
        echo $*
    }

    # These checks were taken from the Debian ifupdown.networking.init script
    check_network_file_systems() {
        [ -e /proc/mounts ] || return 0

        if [ -e /etc/iscsi/iscsi.initramfs ]; then
            log_warning_msg "not deconfiguring network interfaces: iSCSI root is mounted."
            exit 0
        fi

        while read DEV MTPT FSTYPE REST; do
            case $DEV in
            /dev/nbd*|/dev/nd[a-z]*|/dev/etherd/e*)
                log_warning_msg "not deconfiguring network interfaces: network devices still mounted."
                exit 0
                ;;
            esac
            case $FSTYPE in
            nfs|nfs4|smbfs|ncp|ncpfs|cifs|coda|ocfs2|gfs|pvfs|pvfs2|fuse.httpfs|fuse.curlftpfs)
                log_warning_msg "not deconfiguring network interfaces: network file systems still mounted."
                exit 0
                ;;
            esac
        done < /proc/mounts
    }

    check_network_swap() {
        [ -e /proc/swaps ] || return 0

        while read DEV MTPT FSTYPE REST; do
            case $DEV in
            /dev/nbd*|/dev/nd[a-z]*|/dev/etherd/e*)
                log_warning_msg "not deconfiguring network interfaces: network swap still mounted."
                exit 0
                ;;
            esac
        done < /proc/swaps
    }

    check_network_file_systems
    check_network_swap
    ifdown -a
end script

[свернуть]

Как мы видим, upstart гораздо проще, предоставляет больше свобод и меньше трудозатрат при поддержки пакетов. Мне нравится.

А вот systemd я боюсь. Реально боюсь. Я боюсь, что через пару лет, если Debian всё же перейдёт на него по дефолту, эту зверюгу уже не выпилишь из него. Он может просто подгрести под себя выполнение всех важных системных функций и будет не GNU/Linux, а Systemd/Linux.

З.Ы.: Вопрос к уже перешедшим на systemd: И как вам бинарные логи?
Сообщение объединено: 06 января 2014, 02:51:18

кроме того systemd попроще в использовании

Проще чего и чем?

[Malaheenee]

Хотя с другой стороны никто не мешает, в случае каких-либо финтов Canonical, взять и форкануть upstart

А кто будет этим заниматься? Вообще, есть список успешных форков, поддерживаемых именно сообществом Debian?

Я боюсь, что через пару лет, если Debian всё же перейдёт на него по дефолту

Гном в нестабильной ветке уже без systemd жить не может (вообще-то не новость). dbus и gvfs-daemons уже зависят libsystemd-login0, причем зависимость не ИЛИ, а жесткая.

[Brainey]

Хотя с другой стороны никто не мешает, в случае каких-либо финтов Canonical, взять и форкануть upstart, благо кодовая база у него не такая уж и большая (в отличие, кстати, от systemd).

И городить ещё один велосипед...

З.Ы.: Вопрос к уже перешедшим на systemd: И как вам бинарные логи?

Логи как логи. Разве что просматриваются systemd'ёвой же утилиткой systemd-journalctl (емнип, конечно).
Ещё в systemd мне не понравилась одна вещь: иксы + DE могут запуститься раньше, чем, например, сетевые службы. В итоге, система грузится вроде бы быстрее (на глаз), однако, на деле демоны подгружаются как бы "в фоне" и их всё равно приходится ждать.

PS: страницы по systemd и upstart на debian-wiki для интересующихся: 1, 2.

[vladimir_ar]

Journald в связке с классическим демоном syslog

Совместимость с классической реализацией syslog обеспечивается сокетом /run/systemd/journal/syslog, в который перенаправляются все сообщения. Чтобы дать возможность демону syslog работать вместе с журналом systemd, следует привязать данный демон к указанному сокету вместо /dev/log (официальное сообщение). Пакетом syslog-ng в репозиториях автоматически предоставляется необходимая конфигурация.

# systemctl enable syslog-ng

[sandaksatru]

А кто будет этим заниматься? Вообще, есть список успешных форков, поддерживаемых именно сообществом Debian?

Я не слышал о таком списке. Обычно наоборот, форкают Debian и его отдельные компоненты    В сообществе Debian огромное количество разработчиков, опытных программистов, не думаю, что могут возникнуть проблемы с форком чего-либо, тем более системы инициализации, если вдруг возникнет такая необходимость. И не стоит забывать ещё о Mint сообществе. У них то как раз большой опыт форкания  К тому же они уже сидят на upstart. Кто будет этим заниматься? Да кто угодно! Или кто-то внутри сообщества, или отдельная независимая группа заработчиков, как это случилось c форками Gnome, например (Cinnamon и Mate).

Гном в нестабильной ветке уже без systemd жить не может (вообще-то не новость). dbus и gvfs-daemons уже зависят libsystemd-login0, причем зависимость не ИЛИ, а жесткая.

Да, я в курсе этой проблемы. В ответ хочу привести комментарий с ЛОРа в теме о том, как разработчики Debian обсуждали о перехеоде на Upstart/Systemd, в нём вольный перевод отдельных моментов из дискуссии разработчиков:

Почитал:

- Давайте поставим Xfce как DE по умолчанию.
- Нет. Это повредит имиджу проекта GNOME. Давайте лучше у нас вообще не будет дефолтного DE, а будет предлагаться список DE на выбор.
- Но все DE не влезут на один CD. Мы и так GNOME туда еле запихали.
- Давайте откажемся от CD-образов.

Куча перлов:

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

- Разработчики GNOME всё правильно делают, а вы как дети малые - пусть systemd ставится для удовлетворения зависимостей, но не используется как система инициализации.
- У нас и так полно бесполезных пакетов притянутых по зависимостям. Те же udisks и PolicyKit.
- Какая срань тащит с собой udisks и PolicyKit?
- GNOME
- А... Ну тогда тем более не вижу проблем чтобы тянуть ещё и systemd.

[Malaheenee]

Форк форком, но надо исходить из уже имеющихся в наличии деталей конструктора Debian. А пока реально светит sysv ("Essential package") и systemd (этот тянется по зависимостям dbus и GNOME). Пока идут разговоры, мэйнтейнеры усердно пилят пакеты для поддержки последнего (список в вики изрядно уже устарел, для интереса что есть у вас, выполните dpkg -S systemd - удивитесь).

[Brainey]

Немножко побояню. 

[vic5710]

вроде как в lists.debian.org прошло сообщение о включении в experimental openrc. Прям таки разрыв шаблона, что-же реально будет?

[sandaksatru]

вроде как в lists.debian.org прошло сообщение о включении в experimental openrc. Прям таки разрыв шаблона, что-же реально будет?

Кстати, ни разу не связывался с openrc. Есть кто его юзал/щупал/пробовал? Кто что может сказать о нём, кроме инфы из гугла и вики?

[Malaheenee]

вроде как в lists.debian.org прошло сообщение о включении в experimental openrc

Еще на первой странице об этом писали.

[gardarea51]

Выскажу свое скромное мнение. Если RedHat переходит на systemd, то для Debian такой переход был бы вполне логичным решением. Поддерживать нужно то, что идет в мэйнстрим.

[sandaksatru]

Поддерживать нужно то, что идет в мэйнстрим.

Debian и есть мэйнстрим

[gardarea51]

Debian конечно мэйнстримовый дистрибутив, но раз он пока не определился, а RedHat и Ubuntu уже, то лучше мне кажется поддержать поцизию RedHat. И если Ubuntu может себе позволить сделать финт ушами и что-либо резко поменять, то RedHat мне кажется придерживается более консервативного и обдуманного пути.

Я даже почитал небольшую рошюрку по systemd от автора (на работе ArchLinux), мне показалось удобным и понятным. Конечно есть спорные моменты, но в целом - впечатления положительные.