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