哪个环节导致的？
很多很多，systemd 提供了大量功能，此处空间太小写不下，因此大量库或应用程序直接或间接依赖了 systemd。
当然理论上 arch 并不是离开 systemd 就无法工作，比如 mkinitpcio 就支持一种使用 busybox sh 脚本作为 init 进程的 initramfs，并且在过去很长时间（直到几个月前）一直是默认。虽然只是 initramfs，但说明在牺牲一定功能的情况下，这样做是可行的。
如果你真的很不喜欢 systemd，那或许可以试试 Artix Linux，不过我没试过不太了解。
最直观能感受到的，就是官方软件包自带的供系统启动它们的服务（包括系统的核心服务）的文件，只有 systemd 的
如果你想把 systemd 换掉，不是不能换，但成本还是挺大的，比如你要想把现有的 arch 换 openrc 的话：
另外有些你需要的服务可能需要手写服务文件，问别人的时候也要说清楚自己用的不是 systemd
如果，你真的真的出于某种原因不用 systemd，那么就像楼上说的一样，建议使用 Atrix Linux。
其实手写服务是放弃 systemd 的阻力中最小的一环（
让人难以抛弃 systemd 的恰恰是它 all in one 集成了大量“不属于传统 init 职责”的功能（当然这其中大部分功能也确实不是 pid 1）。这其中大部分功能是有非 systemd 替代品的，只有少数是刚需，比如 udevd 以及尤其是 logind。但正是因为这少数没有替代品的功能，让 systemd 成为了主流发行版的默认选择乃至唯一选择；而既然 systemd 已经成为默认甚至唯一选择，对于那些有非 systemd 替代品的功能，很多程序也愿意选择依赖 systemd 提供的功能。最终就让切换到非 systemd 的阻力极大无比。
顺便一提，Artix Linux 使用 elogind 作为会话管理器，它是一个 systemd-logind 的 fork，所以本质上仍然是 systemd。
用Aritx Linux的话是不是就用不了Arch和Cachy的软件源了？
我还想用cachyos的内核，主要是最近在拿Arch研究Linux的启动流程，想研究把它的init程序换了来练练手
那当然
这难度有些太大了。如果想学习启动流程，可以先把 mkinitcpio hooks 配置改成基于 busybox 的，以此为基础并参阅 wiki 和源码学一下它做了些什么
https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/blob/v40/meson.build#L39
好滴谢谢大佬
实际上手写systemd.service比起来rc.d之类的要简单方便太多了！在换systemd之前我从来不自己写服务，就是因为太混乱、文档又太少了。
好像 openrc 什么的也不需要写 system v style 的 init script