Каково текущее состояние перехода Ubuntu от сценариев init.d
к upstart
? Мне было любопытно, поэтому я сравнил содержимое /etc/init.d/
с /etc/init/
на одной из наших машин для разработки, на которой работает Ubuntu 12.04 LTS Server.
# /etc/init.d/ # /etc/init/
acpid acpid.conf
apache2 ---------------------------
apparmor ---------------------------
apport apport.conf
atd atd.conf
bind9 ---------------------------
bootlogd ---------------------------
cgroup-lite cgroup-lite.conf
--------------------------- console.conf
console-setup console-setup.conf
--------------------------- container-detect.conf
--------------------------- control-alt-delete.conf
cron cron.conf
dbus dbus.conf
dmesg dmesg.conf
dns-clean ---------------------------
friendly-recovery ---------------------------
--------------------------- failsafe.conf
--------------------------- flush-early-job-log.conf
--------------------------- friendly-recovery.conf
grub-common ---------------------------
halt ---------------------------
hostname hostname.conf
hwclock hwclock.conf
hwclock-save hwclock-save.conf
irqbalance irqbalance.conf
killprocs ---------------------------
lxc lxc.conf
lxc-net lxc-net.conf
module-init-tools module-init-tools.conf
--------------------------- mountall.conf
--------------------------- mountall-net.conf
--------------------------- mountall-reboot.conf
--------------------------- mountall-shell.conf
--------------------------- mounted-debugfs.conf
--------------------------- mounted-dev.conf
--------------------------- mounted-proc.conf
--------------------------- mounted-run.conf
--------------------------- mounted-tmp.conf
--------------------------- mounted-var.conf
networking networking.conf
network-interface network-interface.conf
network-interface-container network-interface-container.conf
network-interface-security network-interface-security.conf
newrelic-sysmond ---------------------------
ondemand ---------------------------
plymouth plymouth.conf
plymouth-log plymouth-log.conf
plymouth-splash plymouth-splash.conf
plymouth-stop plymouth-stop.conf
plymouth-upstart-bridge plymouth-upstart-bridge.conf
postgresql ---------------------------
pppd-dns ---------------------------
procps procps.conf
rc rc.conf
rc.local ---------------------------
rcS rcS.conf
--------------------------- rc-sysinit.conf
reboot ---------------------------
resolvconf resolvconf.conf
rsync ---------------------------
rsyslog rsyslog.conf
screen-cleanup screen-cleanup.conf
sendsigs ---------------------------
setvtrgb setvtrgb.conf
--------------------------- shutdown.conf
single ---------------------------
skeleton ---------------------------
ssh ssh.conf
stop-bootlogd ---------------------------
stop-bootlogd-single ---------------------------
sudo ---------------------------
--------------------------- tty1.conf
--------------------------- tty2.conf
--------------------------- tty3.conf
--------------------------- tty4.conf
--------------------------- tty5.conf
--------------------------- tty6.conf
udev udev.conf
udev-fallback-graphics udev-fallback-graphics.conf
udev-finish udev-finish.conf
udevmonitor udevmonitor.conf
udevtrigger udevtrigger.conf
ufw ufw.conf
umountfs ---------------------------
umountnfs.sh ---------------------------
umountroot ---------------------------
--------------------------- upstart-socket-bridge.conf
--------------------------- upstart-udev-bridge.conf
urandom ---------------------------
--------------------------- ureadahead.conf
--------------------------- ureadahead-other.conf
--------------------------- wait-for-state.conf
whoopsie whoopsie.conf
Честно говоря, я не совсем уверен, правильно ли я интерпретирую разделение обязанностей, так как не ожидал, что будет какое-либо совпадение (какой фреймворк обрабатывает, какие сервисы). Поэтому я был весьма удивлен, узнав, что в ссылках на службы было значительное совпадение, в дополнение к невозможности различить, какая из них должна была стать основной структурой службы.
Почему, по-видимому, существует значительное количество избыточности в обработке отдельных услуг между init.d
и upstart
? Есть ли здесь что-то еще, что я упускаю?
Что мешает upstart
полностью вступить во владение для init.d
? Есть ли какие-то функции, которые требуются определенным демонам, которых у upstart
еще нет, которые препятствуют конвертации некоторых сервисов? Или это что-то совсем другое?
Многие пакеты, службы которых контролировались с использованием initscripts до их переноса в Upstart, продолжают отправлять «initscript» в /etc/init.d/, который на самом деле является символической ссылкой на / lib / init / upstart-job, которая переводит initscript синтаксис примерно эквивалентный синтаксис выскочки. Например, в моей системе 51 из 90 «initscripts» являются символическими ссылками на /lib/init/upstart-job.