纠正本身对systemd的一个错误认知

之前一直觉得，systemd只会到/etc/systemd/system读取配置文件。要enable某个service就是copy service的配置文件到/etc/systemd/system目录下或者建一个symlinks。

昨天，想在启动时自动执行一个程序，本身写了个service文件放到/etc/systemd/system，发现没起做用。

看了一下systemd的手册

http://www.freedesktop.org/software/systemd/man/

其实下面目录都是systemd的读取目录。读取的优先次序是从上到下。

Table 1.  Load path when running in system mode (--system).
/etc/systemd/system/*
/run/systemd/system/*
/usr/lib/systemd/system/*

Table 2.  Load path when running in user mode (--user).                
$XDG_CONFIG_HOME/systemd/user/*
$HOME/.config/systemd/user/*
/etc/systemd/user/*
/run/systemd/user/*
/usr/lib/systemd/user/*

既然上面的目录都是systemd的读取目录，service的enable, disable是怎么回事呢？/usr/lib/systemd/system/下有全部安装的软件的配置，systemd如何来肯定须要运行那个unit呢？

systemd的启动项是用unit文件来定义的。首先，每一个unit都有Requires，Wants字段配置unit间的依赖关系。除unit文件定义外，每一个unit都另外能够有一个配套的.requires/和.wants/ 目录，放到这两个目录里的unit会被隐式做为依赖项。

其次，unit文件里能够定义一个install节，描述该单元WantsBy，或RequiresBy哪一个单元。当使用systemctl enable service时，就到WantsBy的单元的.wants目录建一个symlinks过来。相似的，RequiresBy也是这样。

由于/etc/systemd/system优先级最高，/etc/systemd/system目录下创建一些unit的.requires和.wants目录，而后systemctl在/etc/systemd/system对应目录下创建symlinks，就能保证不修改软件的安装文件的状况下，enable service，避免软件包升级时被覆盖。

最后，系统启动时systemd自动读取default.target这个unit，default.target定义了它的Requires和Wants，而后一路按依赖启动各项服务。