linux服务之upstart与systemd

http://blog.fens.me/linux-upstart/

rpm -ql initscripts|more

[root@84-monitor init]# rpm -qf /etc/init
upstart-0.6.5-12.el6_4.1.x86_64
[root@84-monitor init]# rpm -ql upstart|more
/etc/dbus-1/system.d/Upstart.conf
/etc/init
/etc/init/init-system-dbus.conf
/sbin/halt
/sbin/init
/sbin/initctl
/sbin/poweroff
/sbin/reboot
/sbin/reload
/sbin/restart
/sbin/runlevel
/sbin/shutdown
/sbin/start
/sbin/status
/sbin/stop
/sbin/telinit

[root@84-monitor iscsi]# rpm -qf /etc/iscsi
iscsi-initiator-utils-6.2.0.873-10.el6.x86_64
[root@84-monitor iscsi]# rpm -ql iscsi-initiator-utils
/etc/NetworkManager
/etc/NetworkManager/dispatcher.d
/etc/NetworkManager/dispatcher.d/04-iscsi
/etc/iscsi
/etc/iscsi/iscsid.conf
/etc/logrotate.d/iscsiuiolog
/etc/rc.d/init.d/iscsi
/etc/rc.d/init.d/iscsid
/sbin/brcm_iscsiuio
/sbin/iscsi-iname
/sbin/iscsiadm
/sbin/iscsid
/sbin/iscsistart
/sbin/iscsiuio
[root@84-monitor iscsi]# rpm -qf /etc/NetworkManager/
initscripts-9.03.40-2.el6.centos.x86_64
dhclient-4.1.1-38.P1.el6.centos.x86_64
iscsi-initiator-utils-6.2.0.873-10.el6.x86_64

https://blog.linuxeye.com/400.html

CentOS 7 使用systemd替换了SysV。Systemd目的是要取代Unix时代以来一直在使用的init系统，兼容SysV和LSB的启动脚本，而且够在进程启动过程中更有效地引导加载服务。

LSB 是 Linux 标准化领域中事实上的标准，制定了应用程序与运行环境之间的二进制接口。
具体地说，它是：1、一个二进制接口规范，是指应用程序在系统间迁移时不用重新编译，保证应用程序在所有经过认证的LINUX发行版上都具有兼容性。2、一个测试规范，测试LINUX发行版和LINUX应用程序是否符合LSB标准。3、搭建遵从LSB规范的应用程序的开发环境。4、为在纯LSB环境下运行和测试应用程序而提供的运行环境样本。LSB包括两个核心部分，分为普通规范和特定处理器规范。
LSB 项目最初发起于 1998 年 5 月，其项目启动宣言得到了 Linus Torvalds、Bruce Perens、Eric Raymond 等人的签名支持，当时的目标是建立一系列构建 Linux 发行版所采用的源代码应该遵循的标准，并提供一个参考平台。2000 年 5 月，LSB 成为 Free Standards Group（FSG） 的一个工作组。
2001 年 6 月发布第一个正式版本的规范以后，LSB 规范几乎每 6 个月都会进行一次更新。截止到 2005 年 7 月发布的 3.0 版本为止，LSB 重点关注的是服务器端的使用，这与 Linux 在服务器端得到了广泛的应用是一致的。这个规范已经被 ISO 采纳为国际标准 23360。
目前最新的版本规范是 2005 年 10 月发布的 LSB 3.1，它可以支持 7 种体系结构：
IA32
IA64
X86_64
PPC32
PPC64
S390
S390x

安装 polkit 后才可使用电源管理。

$ systemctl poweroff

https://www.zhihu.com/question/25873473

作为 systemd 的拥护者，我前半部分尽量客观的陈述：
systemd 本来是一个先进的init程序，除了管理 daemon 之外，还实现了 socket-activation 来支持按需加载服务。
就架构上来说完胜现有的任何系统上的任何服务管理体系（我可以很负责很客观的说），但是反对的意见主要是：

• 不遵循 UNIX 原则。
• systemd 在设计之初就不考虑 Linux 以外的平台，不遵循 POSIX 标准，而且很多功能根本就是 Linux 特有的，无法移植到 Linux 之外的平台，这尤其让 BSD 爱好者们很受伤，在 Debian 7 以前，一直维护着Linux和FreeBSD两个内核，只不过后者没什么人用，Debian 8 为了支持systemd 不得不放弃支持 Debian kFreeBSD。
• 接管了太多设施，如 syslog 被 systemd-journal 取代，crond 也被 systemd 的 timer 单元取代，udev 也准备集成到 systemd 中来，未来甚至还可能取代 /etc/fstab。尽管这些新的服务大部分都是独立于主进程的，但是还是有整个系统被红帽控制住的感觉（systemd的作者Lennart Poettering 就职于红帽，systemd 也主要是红帽的 Fedora 首先在推，OpenSUSE 后面跟随）。这在开源社区看来是件政治不正确的事情。
• 有人怀疑 systemd 的可靠程度。然后就是很多管理员以前积攒的脚本全报废了（这也是管理员反对的主因吧）。

后面我要说下自己的意见：

1. 原则如果阻碍了进步，那还算个屁，不客气地说，UNIX 原则已经过时了。
2. 移植性问题：我除了 Mac 外不用任何 BSD 系统，当然 Mac 上一般只做开发不做运维（但就算如此，Mac 上还是有 launchd，systemd 借[chao]鉴[xi]的就是 launchd）。
3. 对于systemd接管其他设施，一般认为这样也有利于 Linux 系统标准化，在 systemd 之前，init 程序的实现就有 SysV Init，Ubuntu 的 upstart，Gentoo 的 OpenRC 等等，syslog 的实现由 syslog-ng，rsyslogd，简直就是一团乱麻，开发和部署的系统不一样的时候简直神烦（当然这种烦恼仅限于我这样主要做开发，边学边运维的）。关于udev什么的我不是很了解，但是我对 systemd 设计哲学本身就比较认可，相信这么做也是事出有因。另外有些功能在 systemd 之前根本就无法实现，比如
1. logrotate 从来就不能保证归档日志的时候不丢失刚刚写入的 Log，systemd-journal 接管了 syslog 和 logrotate 之后日志被结构化的存储之后才解决这个问题。当然这是小问题。
2. 从前的 init 程序根本就不管 daemon 能否正常的退出。有的时候 daemon 被挂了，但是daemon 开的子进程却没有正确退出，还占着关键资源，导致服务根本不能重启，除非重启操作系统。systemd 是能追踪全局进程树，能精确杀死一个进程下所有子进程，具备这样的能力才能称作 daemon manager。
4. 对 systemd 的怀疑，我觉得那是很多人没用过 systemd，事实上 systemd 在设计上要完备得多（虽然其他 init 服务有各种各样些缺陷，但不是大家痛点），这种设计上就进行了充分的考量的系统，稳定下来后（比如进入 RHEL 7）必然更加可靠。

作者：蓝形参
链接：https://www.zhihu.com/question/25873473/answer/31612048
来源：知乎
著作权归作者所有，转载请联系作者获得授权。