В systemd скрипты? Подробнее, пожалуйста. Что такое усложнённость и зачем её концентрировать?

>В итоге, упрощается работа мэйнтейнеров пакетов по написанию сервисных файлов

Чем упрощается? Каким образом? И вообще, с чего ты взял, что она упрощается?

>целостные и надёжные средства для управления сервисами

В чём заключается целостность и надёжность управления? И почему все другие реализации стали ненадёжные?

#cat /lib/systemd/system/nginx.service

[Unit]
Description=The nginx HTTP and reverse proxy server
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
Type=forking
PIDFile=/run/nginx.pid
ExecStartPre=/usr/sbin/nginx -t
ExecStart=/usr/sbin/nginx
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s QUIT $MAINPID
PrivateTmp=true

[Install]
WantedBy=multi-user.target

......................................

#cat /etc/init.d/nginx

#!/bin/sh
#
# nginx - this script starts and stops the nginx daemon
#
# chkconfig:   - 85 15
# description:  Nginx is an HTTP(S) server, HTTP(S) reverse \
#               proxy and IMAP/POP3 proxy server
# processname: nginx
# config:      /etc/nginx/nginx.conf
# config:      /etc/sysconfig/nginx
# pidfile:     /var/run/nginx.pid

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

# Source networking configuration.
. /etc/sysconfig/network

# Check that networking is up.
[ "$NETWORKING" = "no" ] && exit 0

nginx="/usr/sbin/nginx"
prog=$(basename $nginx)

sysconfig="/etc/sysconfig/$prog"
lockfile="/var/lock/subsys/nginx"
pidfile="/var/run/${prog}.pid"

NGINX_CONF_FILE="/etc/nginx/nginx.conf"

[ -f $sysconfig ] && . $sysconfig

start() {
    [ -x $nginx ] || exit 5
    [ -f $NGINX_CONF_FILE ] || exit 6
    echo -n $"Starting $prog: "
    daemon $nginx -c $NGINX_CONF_FILE
    retval=$?
    echo
    [ $retval -eq 0 ] && touch $lockfile
    return $retval
}

stop() {
    echo -n $"Stopping $prog: "
    killproc -p $pidfile $prog
    retval=$?
    echo
    [ $retval -eq 0 ] && rm -f $lockfile
    return $retval
}

restart() {
    configtest_q || return 6
    stop
    start
}

reload() {
    configtest_q || return 6
    echo -n $"Reloading $prog: "
    killproc -p $pidfile $prog -HUP
    echo
}

configtest() {
    $nginx -t -c $NGINX_CONF_FILE
}

configtest_q() {
    $nginx -t -q -c $NGINX_CONF_FILE
}

rh_status() {
    status $prog
}

rh_status_q() {
    rh_status >/dev/null 2>&1
}

# Upgrade the binary with no downtime.
upgrade() {
    local oldbin_pidfile="${pidfile}.oldbin"

    configtest_q || return 6
    echo -n $"Upgrading $prog: "
    killproc -p $pidfile $prog -USR2
    retval=$?
    sleep 1
    if [[ -f ${oldbin_pidfile} && -f ${pidfile} ]];  then
        killproc -p $oldbin_pidfile $prog -QUIT
        success $"$prog online upgrade"
        echo
        return 0
    else
        failure $"$prog online upgrade"
        echo
        return 1
    fi
}

# Tell nginx to reopen logs
reopen_logs() {
    configtest_q || return 6
    echo -n $"Reopening $prog logs: "
    killproc -p $pidfile $prog -USR1
    retval=$?
    echo
    return $retval
}

case "$1" in
    start)
        rh_status_q && exit 0
        $1
        ;;
    stop)
        rh_status_q || exit 0
        $1
        ;;
    restart|configtest|reopen_logs)
        $1
        ;;
    force-reload|upgrade)
        rh_status_q || exit 7
        upgrade
        ;;
    reload)
        rh_status_q || exit 7
        $1
        ;;
    status|status_q)
        rh_$1
        ;;
    condrestart|try-restart)
        rh_status_q || exit 7
        restart
            ;;
    *)
        echo $"Usage: $0 {start|stop|reload|configtest|status|force-reload|upgrade|restart|reopen_logs}"
        exit 2
esac

Проясните, пожалуйста, некоторые пункты:

1) Какая цель преследуется монтированием tmpfs в /media ?
2) Как выглядит ваш unit-файл с десятью параметрами получившийся в итоге, если не стыдно.
3) Является ли правильным решением, редактирование файла поставляемого с пакетом, который при этом не является файлом конфигурации?

какого тогда они на upstart неостановились?

Он и сейчас есть и после будет. Задачи у всех разные.

В смысле, умение прочитать полсотни строк на стандартном языке оболочки, поправить при необходимости наживую и при необходимости же обратиться к съевшему на sh-программировании собаку более крупной породы за консультацией для придания правке элегантности уже считается "элитарностью"?

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

Я тут уже как-то показывал фото упавшего по сегфолту при отвалившемся (вытащенном) корне со словами "sysvinit себе такого у меня не позволяет".

Шляпники от mission critical отходят как раз со всеми этими MSDN-образными наворотами вдесятеро более сложного кода ради "упрощения для пользователя" вдвое.

Вот с этим предложением я полностью согласен! :)
Старик Фрейд - кстате тоже :)

Сынку, инициализация RAID контроллера занимает больше времени чем загрузка ОС. Перестанешь быть админом локалхоста, убедишься сам

> И упавшие демоны перезапустятся

Перезапустятся и снова отвалятся из за например неконсистентной бд? А может дополнительно её порушат? Упавший сервис это уже повод для беспокойства, как чрезвычайная ситуация. Я такие могу за 12 лет по пальцам одной руки пересчитать

С этого места поподробнее. За счет чего?

> И упавшие демоны перезапустятся

Разбор причины падения, алгоритм расскажи.

Не запустится и не перезапустится. Те же мифы о системд, только в профиль.
Никакой разницы никто не увидит пока не начнет че-то настраивать или писать свои скрипты.

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

В реале же будем иметь загрузившийся рабочий стол, которым ещё некоторое время пользоваться нельзя (привет, шиндовс!)

>И упавшие демоны перезапустятся

если демон падает - это баг