※ 引述《kenduest (小州)》之铭言：
: 个人表达一点看法。
: 其实基本上 systemd 好坏各有定论，若要在这边讨论基本上当然很正常，
: 只是原帖只是提供国外的网址内容说里面有许多抱怨的声音说他不好，
: 那我想问的是原帖自己有没有用过 systemd 呢？有的话又是多久时间了，
: 能够表达一下自己的心得想法，而不是这边起个火然后大家来发表高见。
: systemd 包含太多议题，个人以 init script 个项目表达他的一些优点
Umm
我是觉得前言这部分...
题外话了
: 1. daemon 服务启动后要把服务停止结束，使用 /etc/init.d/name stop
: 方式其实无法确保整个 process 都结束，很有机会程式本身 fork
: 出去或者是执行外部程式这类动作都无法在所谓 stop 这个参数之后
: 正确都被关闭。
: systemd 本身整合 cgroup，整合运作资源功能先不谈，其实在 systemd
: 架构内透过 cgroup 执行的程序都可以被追踪到，执行的程式与资源都
: 能够被正确结束。
这点我很喜欢
cgroup拿来做process追踪真的很棒
但可惜了这是Linux only的功能
BSD好像没类似功能(望
不过BSD我还是喜欢最纯的BSD style啦XD
反正用BSD大多都是挂上去百年不动了(?
: 2. 各家的 /etc/init.d 目录内 init script 都没有一个标准，大家都有
: 自己 function 有自己的语法实作，所以常写了 init script 可能只有
: 适合 rh-based 的系统，换成 debian or suse 就无法正常工作。
: 若使用 systemd 的话就可以依据他的标准设定档案就有个规范，就算是
: 有需要调整地方也不多，可携性比较高。
: 另外 systemd 内可以 override 某个 service unit 设定，原本的
: service unit 档案可以不用异动就拉出额外的设定，以往要改就是动
: 原本档案内容
这部分我觉得...
其实很多distro后期都migrate到upstart去了
只是基于sysv能用&相容
有不少东西没跟着migrate
倒置一些应该被upstart包起来的东西反倒要而额去处理...
这问题要说比较接近是弄半套造成的结果
而这点现行一些还没完全systemd化的distro
我相信这问题还是有的...
不然要我说
我是觉得upstart conf跟service unit感觉很类似了
是说这部分的话
比较印象的大概是start-stop-daemon vs daemon ?
虽然这是把foreground process daemon化才会遇到的
不过一些自己的小东西蛮常会这样处理倒是
不过其实在upstart时已经能自动追踪处理这种freground process了
虽然习惯sysv的可能会直觉回去用start-stop-daemon/daemon处理XD
: 3. init script 要指定优先级甚至相依性单纯化，以往还要去检查自家
: linux 版本相关服务的启动顺序数字来当作撰写 script 时候带给
: chkconfig 这类工具使用的启动与结束的优先数字。其中建立必要 rc?.d
: 相关 script 档案会产生必要数字决定启动与结束顺序...
: 在 systemd unit 档案内只有注明相依，与包含需要在哪些服务启动
: 之前还是之后，systemd 就自动协助处理，这不用仰赖上面提到数字优先性
这点我印象upstart也能自动处理掉吧?
而且sysv/BSD我也记得会自尝试照注解的dep去自动给定正确数字吧?
要说也就差在init系列最终会变成透明的symlink给你看到
systemd只是个黑盒子这样吧?
不过我自己还没遇过dep真的很复杂的情况
(说实在我也不清楚怎样够复杂?
所以我不确定这点systemd有多优势
: 4. 服务的 unit 档案内可以很简单指定自己的启动模式，是开机跑一次还是
: 成为持续运作的服务，若程式结束了要不要每隔多久自己就重新启动，
: 其中也包含重试启动的次数等。
: 透过 systemd 工具就可以自己服务启动的状态。在传统架构内要监视该
: 服务是很麻烦的，要看状态也只能够自己查看 log 来判断...
同上
upstart已经在这方面处理的不错了
至少oneshot/foreground/daemon/forking都能处理
respawn也是有
要说就在PID追踪上不如systemd有cgroup的优势而已
说到log
systemd可以把stdout/err都丢journal
upstart好像只能处理stdout?
要处理stderr要对exec动手脚比较麻烦的样子
: 5. 传统 init script 服务可能有相依性，一般来说 init script 前面会写
: 可能相依哪些服务，不过实际上手动执行相关服务时候若该服务需要另外
: 一个服务先启动，这样手动启动服务方式并检查到。
: systemd 基本上会协助处力这部分的相依需求，会预先执行某个服务后再来
: 执行原本服务。另外服务可以有相依指定当然也可以有互斥指定，某个服务
: 启用了与执行了，另外一个服务就不能够启用与执行。这个在传统 init
: script 服务架构上要支援会比较麻烦。
这部分有点看不大懂QQ
: 6. 有遇过某个服务可能因为某个原因导致要启动很久所以卡住，导致系统无法
: 完全开起来情况吧？卡多久没人知道，得慢慢等。这个在 systemd 内就比较
: 难发生，而且也可以自己指定某个 service 启动要求的时间，没有指定
: 也会有自己默认的配置设定。
: 另外有一些 service 可能启动时候会有一些初始化需要等待，以 systemd
: 来说会判断所需相依性，所以该服务可以执行然后等它完成，其他服务部分
: 就可以先启动，整个服务启动的流程也可以更有效率。另外关机庾重开时候
: 也可以指定服务结束执行等待时间。
upstart这点不大确定XD
好像start部分没limit?
虽然可能多数service也不会预期开不起来就是
: systemd 只有优点没缺点吗，答案是未必，只是很多东西可以看正面而都非负面
: 的事情。最后个人感觉，linux distro 的 developer 对于换不换 systemd 是
: 有他们的考量在，对于末端 end user 或者是 sysadm 的人来说影响不大，就算
: 有其实也不是问题...
: 不过老实说系统架构换 systemd 应该很多 sysadm 会担心吧! 因为是全新的东西，
: 一般习惯旧架构的人对新事物难免会害怕，就像是 centos 7 改用全新的网络设定
: 架构都用 Network Manager 管理，有人还是会选择关闭他直接改设定档案...
: 不过常言到进厨房就不要怕热，走这行也不就是如此？有新的改变其实真的不熟悉
: 只需要了解一下就好... 再者以 sysadm 来说，牵涉的议题其实也不是很深，
: 带来的影响其实相当有限....
: 最后要论 systemd 好坏，一开始贴文不是给个 url 然后要大家表达看法，就算是
: 我有看法要回应也是回应给那些网络上写反对意见的人，回应在这边基本上是根本
: 没有必要。再来这篇其实我对于 systemd 陈述也只是 systemd 内冰山一角的好处，
: 上面表达都是纯个人的意见，不是拿来批斗传统 init script 的缺点用。
虽然知道你说的传统可能是纯粹sysv/BSD
不过其实现在linux也脱离纯sysv很久了...
不过sysv的script倒是一直存在XDrz
其实systemd不少功能很早就有方案解决了
不然不会有那么多init派别XDDD
但systemd靠cgroup追踪这点算是一大重要特色吧
BTW
没用过slackware所以好奇问一下
slackware是像早期init那样? 还是有dep存在?
毕竟现在FreeBSD/NetBSD也多少有dep存在了
倒是OpenBSD还是坚持人工排序XD
好奇Slack是有dep还是一样人工排序?
是跟OpenBSD同阵线吗?
总之就个人来说我是蛮喜欢systemd的
主要是东西整合起来有他的方便性在
但其实upstart时期我就觉得蛮自在了XD
传统init也习惯 只是人终究是懒
要我去全部自己排我宁可遇到排错再去改就好XDD