※ 引述《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