标签：systemd

简单介绍

在基于 Linux-3.x 内核版本的很多发行版都提供了 Systemd 来管理系统和服务. 同时也将 cgroup 功能加到了 slice, scope 和 service 三个单元中, 详见 sec-Default_Cgroup_Hierarchies. 基于这些特性我们可以很方便的通过 systemd 来限制服务或者进程对系统资源的使用, 这在单主机多服务的场景下会很有用. 下面则以 MySQL 服务为例介绍如何使用 systemd 限制资源的使用, 其它服务的限制和此等同.

示例使用

以 Centos7 系统为例, 从 redhat-resource-control 的文档来看, 官方建议通过 service 来实现资源的限制, 所以这里我们增加可以带端口参数(如果单台主机有多个 MySQL 实例的话)启动的 mysql 服务:

# cat /usr/lib/systemd/system/mysql@.service                                   
[Unit]
Description=MySQL Server node%i

[Service]
Type=forking
Environment="PORT_ARGS=%I"
PermissionsStartOnly=true
ExecStart=/usr/local/mysqlnode/bin/node ${PORT_ARGS} start
ExecStop=/usr/local/mysqlnode/bin/node ${PORT_ARGS} stop

[Install]
WantedBy=multi-user.target

上述服务以 fork 方式启动服务, @ 符号之后的端口号即为相应的端口参数, 启动后查看对应服务状态:

# systemctl start mysql@3327 
# systemctl status mysql@3327
● mysql@3327.service - MySQL Server node3327
   Loaded: loaded (/usr/lib/systemd/system/mysql@.service; disabled; vendor preset: disabled)
   Active: active (running) since Fri 2018-12-07 21:31:32 CST; 4s ago
  Process: 58084 ExecStart=/usr/local/mysqlnode/bin/node ${PORT_ARGS} start (code=exited, status=0/SUCCESS)
 Main PID: 58159 (mysqld_safe)
   CGroup: /system.slice/system-mysql.slice/mysql@3327.service
           ├─58159 /bin/sh /opt/Percona-Server-5.6.38-rel83.0-Linux.x86_64.ssl101//bin/mysqld_safe --defaults-file=/export/mysql/node3327/my.node.cnf
           ├─59489 /opt/Percona-Server-5.6.38-rel83.0-Linux.x86_64.ssl101/bin/mysqld --defaults-file=/export/mysql/node3327/my.node.cnf --basedir=/opt/Percona-Server-5.6.38-rel83.0-Linux.x86_64.ssl101 --datadir=/export/mysql/node3327/...
           └─59490 logger -t mysqld-3327 -p daemon.error

通过 systemd 增加 cgroup 限制，可以一次设置单项属性值, 也可以一次设置多项：

# systemctl set-property mysql@3327.service MemoryLimit=5G       # 5G 内存
# systemctl set-property mysql@3327.service CPUQuota=150%        # 150% cpu 使用率
# systemctl set-property mysql@3327.service BlockIOWeight=1000   # IO 权重

# systemctl status mysql@3327
● mysql@3327.service - MySQL Server node3327
   Loaded: loaded (/usr/lib/systemd/system/mysql@.service; disabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/mysql@3327.service.d
           └─50-MemoryLimit.conf
   Active: active (running) since Fri 2018-12-07 21:31:32 CST; 1min 18s ago
  Process: 58084 ExecStart=/usr/local/mysqlnode/bin/node ${PORT_ARGS} start (code=exited, status=0/SUCCESS)
 Main PID: 58159 (mysqld_safe)
   Memory: 1.3M (limit: 5G)            # 内存限制 5G
   CGroup: /system.slice/system-mysql.slice/mysql@3327.service
           ├─58159 /bin/sh /opt/Percona-Server-5.6.38-rel83.0-Linux.x86_64.ssl101//bin/mysqld_safe --defaults-file=/export/mysql/node3327/my.node.cnf
           ├─59489 /opt/Percona-Server-5.6.38-rel83.0-Linux.x86_64.ssl101/bin/mysqld --defaults-file=/export/mysql/node3327/my.node.cnf --basedir=/opt/Percona-Server-5.6.38-rel83.0-Linux.x86_64.ssl101 --datadir=/export/mysql/node3327/...
           └─59490 logger -t mysqld-3327 -p daemon.error

更多属性参见 man systemd.resource-control, 不过一些参数没有对应的属性, 需要手动单独设置, 比如设置单独某个服务的 memory + swap 限制, 可以使用以下命令将限制的字节数写到对应的参数文件中:

echo xxxxxx > memory.memsw.limit_in_bytes

查看 MySQL 进程 cgroup 信息, 可以看到 memory, blkid, cpuacct 三个条目对应的信息:

# cat /proc/59489/cgroup 
11:memory:/system.slice/system-mysql.slice/mysql@3327.service
10:devices:/system.slice/system-mysql.slice
9:cpuset:/
8:blkio:/system.slice/system-mysql.slice/mysql@3327.service
7:perf_event:/
6:hugetlb:/
5:freezer:/
4:cpuacct,cpu:/system.slice/system-mysql.slice
3:pids:/system.slice/system-mysql.slice
2:net_prio,net_cls:/
1:name=systemd:/system.slice/system-mysql.slice/mysql@3327.service

查看进程相关的限制值:

# cat /sys/fs/cgroup/memory/system.slice/system-mysql.slice/mysql@3327.service/memory.limit_in_bytes 
5368709120

# cat /sys/fs/cgroup/blkio/system.slice/system-mysql.slice/mysql@3327.service/blkio.weight
1000

# cat /sys/fs/cgroup/cpu/system.slice/system-mysql.slice/mysql@3327.service/cpu.cfs_quota_us 
150000

简单验证

这里仅以不同的 CPUQuota 为例说明, 如下所示可以看到, MySQL 进程在不同 CPUQuota 限制下的不同表现, benchyou 的压测结果也相差较大.

限制进程 CPUQuota 为 150% 的情况下:

# top -p 59489
   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                           
 59489 mysql     20   0 3412052 1.468g   8784 S 149.5  2.3   7:08.22 mysqld

# benchyou --oltp-tables-count=256 --read-threads=30 --update-threads 8 --write-threads 6 --delete-threads=5 --mysql-table-engine=innodb ..
time            thds              tps     wtps    rtps    rio    rio/op   wio    wio/op    rMB     rKB/op    wMB     wKB/op   cpu/op  freeMB  cacheMB   w-rsp(ms)  r-rsp(ms)    total-number
[13s]        [r:30,w:6,u:8,d:5]  3323     304     3019    0      0.00     0      0.00      0.00    0.00      0.00    0.00     0.00    0       0         62.56      9.92         40765

time            thds              tps     wtps    rtps    rio    rio/op   wio    wio/op    rMB     rKB/op    wMB     wKB/op   cpu/op  freeMB  cacheMB   w-rsp(ms)  r-rsp(ms)    total-number
[14s]        [r:30,w:6,u:8,d:5]  3319     325     2994    0      0.00     0      0.00      0.00    0.00      0.00    0.00     0.00    0       0         57.21      9.99         44084

限制进程 CPUQuota 为 400% 情况下:

# top -p 59489
   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                                                           
 59489 mysql     20   0 3416472 1.474g   8796 S 400.0  2.4   7:47.42 mysqld 


# benchyou --oltp-tables-count=256 --read-threads=30 --update-threads 8 --write-threads 6 --delete-threads=5 --mysql-table-engine=innodb ..
time            thds              tps     wtps    rtps    rio    rio/op   wio    wio/op    rMB     rKB/op    wMB     wKB/op   cpu/op  freeMB  cacheMB   w-rsp(ms)  r-rsp(ms)    total-number
[10s]        [r:30,w:6,u:8,d:5]  10547    967     9580    0      0.00     0      0.00      0.00    0.00      0.00    0.00     0.00    0       0         19.49      3.12         96270

time            thds              tps     wtps    rtps    rio    rio/op   wio    wio/op    rMB     rKB/op    wMB     wKB/op   cpu/op  freeMB  cacheMB   w-rsp(ms)  r-rsp(ms)    total-number
[11s]        [r:30,w:6,u:8,d:5]  10829    1036    9793    0      0.00     0      0.00      0.00    0.00      0.00    0.00     0.00    0       0         18.23      3.04         107099

会话级别限制

如果没有以 service 启动, 可以按照 pid 查看会话级别的信息:

# systemctl status 303   # 303 为 mysql 进程 id
● session-31208.scope - Session 31208 of user root

session-31208.scope 即为会话级别的信息, 一个会话可能包含多个 MySQL 进程, 使用上述的 systemctl set-property session-31208.scope XXXX 即可对整个会话的进程进行相关的限制. 当然使用这种方式即是对多个进程总体使用情况的限制.

其它限制

如果要单独限制 1 个进程 id, 则需要借助 libcgroup 提供的工具, 具体的使用同 Centos6 的设置, 不过 Centos7 已经弃用了 libgcgroup-tools, 不再建议使用, 如果要对单独进程进行限制, 最好使用 service 进行启动. 另外从 systemd 提供的 ControlGroupInterface 来看, 其提供的控制选项还不够精细, 比如没有 memsw, cpuset 等设置的属性, 这种情况下如果有限制的需求, 还需要靠和以前一样的 libcgroup-tool 方式来设置, 比如以下设置, 限制 pid 为 59489 的进程仅使用 cpu 0 ~ 5, mem 可以是 cpu node0 或 node1, cgclassify 没有指定 --sticky 选项的话则 tasks 会包含指定进程的子进程信息:

# cgcreate -g  cpuset:mysql@3327.service
# cgset -r cpuset.cpus=0-5 mysql@3327.service
# cgset -r cpuset.mems=0-1 mysql@3327.service
# cgclassify -g cpuset:mysql@3327.service 59489

当然也可以使用红帽知识库的方式在启动进程的时候就限制相应的 cpuset 等选项, 详见 redhat-1445073

0. 简介

systemd 是 freedesktop 的项目，官网 https://www.freedesktop.org/wiki/Software/systemd/ ,项目源码在 github 上发布，可以在 https://github.com/systemd/systemd 查看所有版本更新、 Bug Fix 和版本对应的文档等。
systemd-networkd 是 systemd 默认提供的网络管理服务，可以完全管理以太网，对于无线网卡，还需要其他服务支持，比如管理 Wi-Fi 的 wpa_supplicant@.service ，管理 PPP 的 ppp@.service 。
管理网卡前，应该确保各网卡的驱动都已经正常加载，systemd 的 systemd-modules-load.service 负责在系统启动时静态加载内核模块。它会从以下路径搜索可用的配置文件：

/etc/modules-load.d/*.conf
/run/modules-load.d/*.conf
/usr/lib/modules-load.d/*.conf

配置文件的内容就是一个内核模块名称的列表，可以用井号 # 或者分号 ; 注释单个模块。

1. 基本配置

我的系统中，systemd 的版本是 216 ，有两个以太网卡和一个 Wi-Fi 网卡，先查看一下网卡列表，再查看 systemd-networkd.service 的状态：

~# networkctl list
IDX LINK             TYPE               OPERATIONAL SETUP     
1 lo               loopback           carrier     unmanaged 
2 wlp1s0           wlan               off         unmanaged 
3 enp0s20f6        ether              routable    configured
4 enp0s20f7        ether              no-carrier  configured
4 links listed.
~# systemctl status systemd-networkd 
a—? systemd-networkd.service - Network Service
Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled)
Active: active (running) since Fri 2018-04-27 17:49:22 UTC; 24min ago
    Docs: man:systemd-networkd.service(8)
Main PID: 260 (systemd-network)
Status: "Processing requests..."
CGroup: /system.slice/systemd-networkd.service
        a””a”€260 /lib/systemd/systemd-networkd

Apr 27 17:49:21 quark systemd[1]: Starting Network Service...
Apr 27 17:49:22 quark systemd-networkd[260]: lo              : gained carrier
Apr 27 17:49:22 quark systemd[1]: Started Network Service.
Apr 27 17:49:22 quark systemd-networkd[260]: eth1            : renamed to enp0s20f7
Apr 27 17:49:22 quark systemd-networkd[260]: eth0            : renamed to enp0s20f6
Apr 27 17:49:23 quark systemd-networkd[260]: enp0s20f6       : gained carrier
Apr 27 17:49:23 quark systemd-networkd[260]: enp0s20f7       : gained carrier
Apr 27 17:49:25 quark systemd-networkd[260]: enp0s20f6       : lost carrier
Apr 27 17:49:26 quark systemd-networkd[260]: enp0s20f7       : lost carrier

sytemd-network.service 的配置文件可以位于 /usr/lib/systemd/network/ 或者 /etc/systemd/network/ 目录下，后者具有最高优先级。配置文件有三种类型：

• .network 文件，设置网卡的 IP 等各项属性
• .netdev 文件，新建一个虚拟网卡
• .link 文件，每当一个网卡出现时，udev 都会查找与它同名的 .link 文件

这几类文件都遵循下面的规则：

• 各选项的值都支持星号 * 通配符
• 当 [Match] 段内的条件都匹配时，后面的配置项才会被激活
• 如果 [Match] 段为空，表示后面的配置项在任何情况下都可用
• 无论配置文件在哪个目录，都会统一安装字典顺序进行加载
• 同名文件可以相互替换

如果要给 enp0s20f6 配置一个静态 IP ，可以在 /etc/systemd/network/ 目录下新建一个 eth0.network 文件，内容如下：

[Match]
Name=enp0s20f6  # 匹配名为 enp0s20f6 的网卡
[Network]
DHCP=none    # 关闭 DHCP 客户端，
Address=192.168.5.242/24  # 设置 IP 和子网掩码
Gateway=192.168.5.50   # 设置网关，这项设置会将该网卡添加到缺省路由
DNS=8.8.8.8  # 设置 DNS 

如果要使用 DHCP 自动获取 IP ，也将 DHCP 设为如下值：

• v4 ，只接受 ipv4 的 IP
• v6 ，只接受 ipv6 的 IP
• both ，同时接受 ipv4 和 ipv6 格式的 IP

启动 DHCP 客户端后，Gateway 和 DNS 也会自动获取，有时我们不希望这样，可以在配置文件中添加一个 [DHCP] 段，做如下设置：

[DHCP]
UseDNS=false # 不使用 DHCP 分配的 DNS ，默认值是 true
UseRoutes=false # 不会将本网卡设为缺省路由，默认值是 true 

在这里会出现一个 Bug ，就是 UseRoutes 设置无效，高版本中已经解决，解决方案在 https://github.com/systemd/systemd/pull/3075 。

2. Wi-Fi 配置

Wi-Fi 连接还是使用 wpa_supplicant 程序，systemd 提供了 wpa_supplicant@.service 管理整个流程，然后再用 systemd-networkd.service 配置 IP 等。
wpa_supplicant@.service 的内容：

[Unit]
Description=WPA supplicant daemon (interface-specific version)
Requires=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device

# NetworkManager users will probably want the dbus version instead.

[Service]
Type=simple
ExecStart=/usr/sbin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-%I.conf -i%I

[Install]
Alias=multi-user.target.wants/wpa_supplicant@%i.service

这是 service 模板，启动时在 @ 符号之后加入 Wi-Fi 网卡的名称使其实例实例化，这个名词还会关联到 wpa_supplicant 的配置文件，我们先在 /etc/ 下新建一个 wpa_supplicant 目录，然后新建一个 wpa_supplicant-wlp1s0.conf 文件，内容如下：

ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=wheel
update_config=1
eapol_version=1
ap_scan=1
fast_reauth=1

用 wpa_passphrase 添加无线路由器配置：

~# sudo wpa_passphrase [essid] [password] >> /etc/wpa_supplicant/wpa_supplicant-wlp1s0.conf
在 /etc/systemd/network/ 目录下添加配置文件 wireless.network ，内容如下：
[Match]
Name=wlp1s0
[Network]
DHCP=yes

最后重启各项服务：

~# systemctl restart systemd-networkd
~# systemctl restart wpa_supplicant@wlp1s0
~# systemctl restart systemd-resolved

3. 3G/4G 配置

依然使用 pppd 进行 3G/4G 拨号，systemd 提供了 ppp@.service 服务管理 pppd 。首先在 /etc/ppp/peers/ 下建好 ppp 拨号文件 me909s ，然后启动服务：

~# systemctl start ppp@me909s 

4. 关闭 IPv6

向内核参数加入 ipv6.disable=1 可以完全关闭 IPv6 功能。此外，只加入 ipv6.disable_ipv6=1 内核参数可以保留 IPv6 功能，但不会向网卡分配 IPv6 地址，做法是：

~# echo 1 > /proc/sys/net/ipv6/conf/enp0s20f6/disable_ipv6

5. ssh server

目前流行的启动 ssh server 的方式是调用 sshd.socket ：

~# systemctl start sshd.socket

旧有的 sshd.service 模式会在后台保持一个 sshd 的守护进程，每当有 ssh 连接要建立时，就创建一个新进程，比较适合 SSH 下有大量流量的系统；
新的 sshd.socket 方式也是在每次要建立新的ssh连接时生成一个守护进程的实例，不过监听端口则是交给了 systemd 来完成，意味着没有 ssh 连接的时候，也不会有 sshd 守护进程运行，大部分情况下，使用 sshd.socket 服务更为合适。这也与 MacOS 下的行为相一致，默认只监听端口，有连接时才创建进程。
另外，通过使用 .socket 文件来管理需要监听端口的服务，可以直接通过 systemctl 来查看一些网络相关的信息，如监听的端口、目前已经接受的连接数、目前正连接的连接数等。

我们运行 linux 服务器的主要目的是通过运行程序提供服务，比如 mysql、web server等。因此管理 linux 服务器主要工作就是配置并管理上面运行的各种服务程序。在 linux 系统中服务程序的管理主要由 init 系统负责。如同笔者在《初识 systemd》一文中的介绍，linux 的 init 系统已经从最初的 sysvinit 进化到了如今的 systemd。本文主要介绍在 systemd 环境中如何编写运行服务的配置文件。

unit(单元)的配置文件

Unit 是 systemd 进行任务管理的基本单位，我们在前文中已经介绍过，service 类型的 unit 代表一个后台服务进程。接下来我们就详细的介绍如何配置 service 类型的 unit。下面我们先来看一个简单的服务配置：

[Unit]
Description=Prometheus Server
Documentation=https://prometheus.io/docs/introduction/overview/
After=network.target

[Service]
User=prometheus
Restart=on-failure
WorkingDirectory=/usr/local/share/prometheus/
ExecStart=/usr/local/share/prometheus/prometheus 
          -config.file=/usr/local/share/prometheus/prometheus.yml

[Install]
WantedBy=multi-user.target

这是笔者主机上 prometheus 服务的配置文件。把上面的内容保存到文件 /lib/systemd/system/prometheus.service 中，然后就可以使用 systemctl 命令管理 prometheus 服务了。注意，服务类型的配置文件名称必须以 .service 结尾。
查看上面配置信息的详细内容，我们会发现整个配置的内容分为三个部分：
[Unit] unit 本身的说明，以及与其它有依赖关系的服务的设置，包括在什么服务之后才启动此 unit 之类的设置。
[Service] 不同的 unit 类型就得要使用相对应的设置项目，比如 timer 类型的 unit 应该是 [Timer]，socket 类型的 unit 应该是 [Socket]。服务类型的 unit 就是 [Service]，这个项目内主要在规范服务启动的脚本、环境配置文件文件名、重新启动的方式等等。
[Install] 这个部分主要设置把该 unit 安装到哪个 target 。

服务类型 unit 的详细配置

配置文件分为三个部分，每个部分中都可以提供详细的配置信息。为了精确的控制服务的运行方式，我们需要了解这些详细的配置选项，并最终让服务以我们期望的方式运行。

[Unit] 部分
Description 关于该 unit 的简易说明。
Documentation 文档相关的内容，如 Documentation=https://prometheus.io/docs/introduction/overview/
Documentation=man:sshd（8）
Documentation=file:/etc/ssh/sshd_config
After 说明本 unit 是在哪个服务启动之后才启动的意思。仅是说明服务启动的顺序而已，并没有强制要求 。
Before 与 After 的意义相反，在指定的服务启动前最好启动本个服务的意思。仅是说明服务启动的顺序而已，并没有强制要求 。
Requires 本 unit 需要在哪个服务启动后才能够启动！就是设置服务间的依赖性。如果在此项设置的前导服务没有启动成功，那么本 unit 就不会被启动！
Wants 与 Requires 刚好相反，规范的是这个 unit 之后还要启动什么服务，如果这 Wants 后面接的服务如果没有启动成功，其实不会影响到这个 unit 本身！
Conflicts 这个项目后面接的服务如果有启动，那么本 unit 就不能启动！如果本 unit 启动了，则指定的服务就不能启动。

[Service] 部分
Type
说明这个服务的启动方式，会影响到 ExecStart，主要有下面几种类型：
simple：默认值，这个服务主要由 ExecStart 设置的程序来启动，启动后常驻于内存中。
forking：由 ExecStart 指定的启动的程序通过 spawns 产生子进程提供服务，然后父进程退出。
oneshot：与 simple 类似，不过这个程序在工作完毕后就结束了，不会常驻在内存中。
dbus：与 simple 类似，但这个服务必须要在取得一个 D-Bus 的名称后，才会继续运行！因此设置这个项目时，通常也要设置 BusName= 才行。
idle：与 simple 类似，意思是，要执行这个服务必须要所有的工作都顺利执行完毕后才会执行。这类的服务通常是开机到最后才执行即可的服务。
notify：与 simple 类似，但这个服务必须要收到一个 sd_notify() 函数发送的消息后，才会继续运行。

ExecStart
就是实际执行此服务的程序。接受 “命令 参数 参数…” 的格式，不能接受 <, >, >>, |, & 等特殊字符，很多的 bash 语法也不支持。所以，要使用这些特殊的字符时，最好直接写入到脚本里面去！

ExecStartPre 和 ExecStartPost 分别在服务启动前后，执行额外的命令。

ExecStop 用来实现 systemctl stop 命令，关闭服务。
ExecReload 用来实现 systemctl reload 命令，重新加载服务的配置信息。

Restart 当设置为 Restart=1 时，如果服务终止，就会自动重启此服务。
RestartSec 与 Restart 配合使用，在服务终止多长时间之后才重新启动它。默认是 100ms。

KillMode
可以是 process, control-group, none 中的一种，如果是 process 则服务终止时，只会终止主要的程序(ExecStart接的后面那串指令)，如果是 control-group 时，则由此 daemon 所产生的其他 control-group 的程序，也都会被关闭。如果是 none 的话，则没有程序会被关闭。

TimeoutSec
若这个服务在启动或者是关闭时，因为某些缘故导致无法顺利 “正常启动或正常结束” 的情况下，则我们要等多久才进入 “强制结束” 的状态！

RemainAfterExit
当设置为 RemainAfterExit=1 时，则当这个服务所属的所有程序都终止之后，此服务会再尝试启动。这对于 Type=oneshot 的服务很有帮助！

环境变量的设置对很多程序来说都是十分重要的，下面的配置则可以以不同的方式为服务程序设置环境变量：
Environment 用来设置环境变量，可以使用多次：

[Service]
# Client Env Vars
Environment=ETCD_CA_FILE=/path/to/CA.pem
Environment=ETCD_CERT_FILE=/path/to/server.crt

EnvironmentFile 通过文件的方式设置环境变量，可以把下面的内容保存到文件 testenv 中：

AAA_IPV4_ANCHOR_0=X.X.X.X
BBB_IPV4_PRIVATE_0=X.X.X.X
CCC_HOSTNAME=test.example.com

然后这样设置：

[Service]
EnvironmentFile=/testenv

接下来就可以在 ExecStart 配置中使用在文件中设置的环境变量，如：

ExecStart=/xxx --abc=xx${AAA_IPV4_ANCHOR_0}yy

[Install] 部分
WantedBy 这个设置后面接的大部分是 *.target unit。意思是，这个 unit 本身是附挂在哪个 target unit 下面。
Also 当目前这个 unit 被 enable 时，Also 后面接的 unit 也要 enable 的意思。
Alias 当 systemctl enable 相关的服务时，则此服务会进行链接文件的创建！

Timer 类型 unit 的详细配置

Timer 类型的 unit 主要用来执行定时任务，并有可能取代 cron 服务。由于 timer 类型的 unit 经常与服务类型的 unit 一起使用，所以本文也附带介绍一下 timer unit 的配置。与服务类型的 unit 不同，timer unit 配置文件中的主要部分是 [Timer]，下面是其主要的配置项：
OnActiveSec 当 timers.target 启动后多久才执行这个 unit。
OnBootSec 当开机后多久才执行这个 unit。
OnStartupSec 当 systemd 第一次启动后多久才执行这个 unit。
OnUnitActiveSec 这个 timer 配置文件所管理的那个 unit 服务在最后一次启动后，隔多久后再执行一次。
OnUnitInactiveSec 这个 timer 配置文件所管理的那个 unit 服务在最后一次停止后，隔多久后再执行一次。
Unit 一般不需要设置，基本上我们设置都是 服务名称.server + 服务名称.timer。如果你的服务名称和 timer 名称不相同，就需要在 .timer 文件中通过 Unit 项指定服务的名称。
OnCalendar 使用实际时间(非循环时间)的方式来启动服务。
Persistent 当使用 OnCalendar 的设置时，指定该功能要不要持续执行。

通过上面的介绍，相信大家对 systemd 服务类型和 timer 类型的 unit 配置已经有了基本的理解，下面让就让我们配置两个实际的例子。

配置 redis 服务

在 ubuntu 上我们一般会手动编译并安装 redis。在安装完成后需要把 redis 配置为 systemd 管理的服务，下面介绍具体的配置过程。

添加 redis 配置文件

首先手动创建 /etc/redis 目录并添加配置文件：

$ sudo mkdir /etc/redis

并把代码目录中的配置文件 redis.conf 拷贝到 /etc/redis 目录中：

$ sudo cp /tmp/redis-4.0.0/redis.conf /etc/redis/

然后修改配置文件 /etc/redis/redis.conf 中的 supervised 为 systemd：
supervised systemd

接着继续在配置文件 /etc/redis/redis.conf 中配置工作目录，把 dir ./ 修改为：
dir /var/lib/redis

配置由 systemd 管理 redis 服务

创建 /etc/systemd/system/redis.service 文件

$ sudo vim /etc/systemd/system/redis.service

编辑其内容如下：

[Unit]
Description=Redis In-Memory Data Store
After=network.target

[Service]
User=redis
Group=redis
ExecStart=/usr/local/bin/redis-server /etc/redis/redis.conf
ExecStop=/usr/local/bin/redis-cli shutdown
Restart=always

[Install]
WantedBy=multi-user.target

启动服务并配置为开机启动：

$ sudo systemctl start redis
$ sudo systemctl enable redis
$ sudo systemctl status redis

通过脚本定时备份文件

备份文件的 bash 脚本：

#!/bin/bash
mydate()
{
        date "+%Y%m%d%H%M%S"
}
backupdate=$(mydate)
tar -zcf /tmp/backup.${backupdate}.tar.gz /home/nick/learn

把上面的代码保存到文件 /usr/local/bin/backupdir.sh，并添加可执行权限：

$ sudo chmod +x /usr/local/bin/backupdir.sh

然后创建 service unit 配置文件：

[Unit]
Description=nick backup learn dir service

[Service]
User=nick
Group=nick
Type=simple
ExecStart=/usr/local/bin/backupdir.sh

[Install]
WantedBy=multi-user.target

把上面的 unit 配置保存到文件 /etc/systemd/system/nickbak.service。
然后执行下面的命令测试服务的执行情况：

$ sudo systemctl daemon-reload
$ sudo systemctl start nickbak.service

这样的备份任务只会在执行 sudo systemctl start nickbak.service 时执行一次。下面我们通过 timer unit 把它配置为定时执行。
创建 timer unit 配置文件：

[Unit]
Description=nick backup learn dir timer

[Timer]
OnCalendar=*:0/15
Persistent=true
Unit=nickbak.service

[Install]
WantedBy=multi-user.target

把上面的 unit 配置保存到文件 /etc/systemd/system/nickbak.timer。配置中 OnCalendar=*:0/15 表示每 15 分钟执行一次 nickbak.service 服务。

执行下面的命令把 nickbak.timer 设置为开机启动，并启动 nickbak.timer：

$ sudo systemctl daemon-reload
$ sudo systemctl enable nickbak.timer
$ sudo systemctl start nickbak.timer

现在来看看 nickbak.timer 的状态：

$ sudo systemctl status nickbak.timer

从现在开始 nickbak.timer 会每隔 15 分钟执行一次 nickbak.service 服务。

总结

systemd 提供了服务管理(其实是 unit 管理)的方方面面，我们需要做的就是写好服务 unit 的配置文件，然后利用 systemd 来管理我们的服务。这是一个看似简单实则繁琐的任务(很多的配置项其实需要我们在实践中不断的调整并优化)。希望本文对大家来说是个简单的入门。

一般情况下，常规用途的 Linux 发行版在开机启动时拉起各种相关服务进程，包括许多你可能无需使用的服务，例如蓝牙bluetooth、Avahi、 调制解调管理器ModemManager、ppp-dns（LCTT 译注：此处作者笔误 ppp-dns 应该为 pppd-dns) 等服务进程，这些都是什么东西？用于哪里，有何功能？

Systemd 提供了许多很好的工具用于查看系统启动情况，也可以控制在系统启动时运行什么。在这篇文章中，我将说明在 Systemd 类发行版中如何关闭一些令人讨厌的进程。

查看开机启动项

在过去，你能很容易通过查看 /etc/init.d 了解到哪些服务进程会在引导时启动。Systemd 以不同的方式展现，你可以使用如下命令罗列允许开机启动的服务进程。

$ systemctl list-unit-files --type=service | grep enabled
accounts-daemon.service                    enabled
anacron-resume.service                     enabled
anacron.service                            enabled
bluetooth.service                          enabled
brltty.service                             enabled
[...]

在此列表顶部，对我来说，蓝牙服务是冗余项，因为在该电脑上我不需要使用蓝牙功能，故无需运行此服务。下面的命令将停止该服务进程，并且使其开机不启动。

$ sudo systemctl stop bluetooth.service
$ sudo systemctl disable bluetooth.service

你可以通过下面命令确定是否操作成功。

$ systemctl status bluetooth.service
 bluetooth.service - Bluetooth service
  Loaded: loaded (/lib/systemd/system/bluetooth.service; disabled; vendor preset: enabled)
  Active: inactive (dead)
    Docs: man:bluetoothd(8)

停用的服务进程仍然能够被另外一个服务进程启动。如果你真的想在任何情况下系统启动时都不启动该进程，无需卸载该它，只需要把它掩盖起来就可以阻止该进程在任何情况下开机启动。

$ sudo systemctl mask bluetooth.service
 Created symlink from /etc/systemd/system/bluetooth.service to /dev/null.

一旦你对禁用该进程启动而没有出现负面作用感到满意，你也可以选择卸载该程序。

通过执行命令可以获得如下服务列表：

$ systemctl list-unit-files --type=service                       
UNIT FILE                                  STATE   
accounts-daemon.service                    enabled
acpid.service                              disabled
alsa-restore.service                       static    
alsa-utils.service                         masked

你不能启用或禁用静态服务，因为静态服务被其他的进程所依赖，并不意味着它们自己运行。

哪些服务能够禁止？

如何知道你需要哪些服务，而哪些又是可以安全地禁用的呢？它总是依赖于你的个性化需求。

这里举例了几个服务进程的作用。许多服务进程都是发行版特定的，所以你应该看看你的发行版文档（比如通过 google 或 StackOverflow）。

• accounts-daemon.service 是一个潜在的安全风险。它是 AccountsService 的一部分，AccountsService 允许程序获得或操作用户账户信息。我不认为有好的理由能使我允许这样的后台操作，所以我选择掩盖mask该服务进程。
• avahi-daemon.service 用于零配置网络发现，使电脑超容易发现网络中打印机或其他的主机，我总是禁用它，别漏掉它。
• brltty.service 提供布莱叶盲文设备支持，例如布莱叶盲文显示器。
• debug-shell.service 开放了一个巨大的安全漏洞（该服务提供了一个无密码的 root shell ，用于帮助 调试 systemd 问题），除非你正在使用该服务，否则永远不要启动服务。
• ModemManager.service 该服务是一个被 dbus 激活的守护进程，用于提供移动宽频broadband（2G/3G/4G）接口，如果你没有该接口，无论是内置接口，还是通过如蓝牙配对的电话，以及 USB 适配器，那么你也无需该服务。
• pppd-dns.service 是一个计算机发展的遗物，如果你使用拨号接入互联网的话，保留它，否则你不需要它。
• rtkit-daemon.service 听起来很可怕，听起来像是 rootkit。 但是你需要该服务，因为它是一个实时内核调度器real-time kernel scheduler。
• whoopsie.service 是 Ubuntu 错误报告服务。它用于收集 Ubuntu 系统崩溃报告，并发送报告到 https://daisy.ubuntu.com 。 你可以放心地禁止其启动，或者永久的卸载它。
• wpa_supplicant.service 仅在你使用 Wi-Fi 连接时需要。

系统启动时发生了什么？

Systemd 提供了一些命令帮助调试系统开机启动问题。该命令会重演你的系统启动的所有消息。

$ journalctl -b

-- Logs begin at Mon 2016-05-09 06:18:11 PDT,
end at Mon 2016-05-09 10:17:01 PDT. --
May 16 06:18:11 studio systemd-journal[289]:
Runtime journal (/run/log/journal/) is currently using 8.0M.
Maximum allowed usage is set to 157.2M.
Leaving at least 235.9M free (of currently available 1.5G of space).
Enforced usage limit is thus 157.2M.
[...]

通过命令 journalctl -b -1 可以复审前一次启动，journalctl -b -2 可以复审倒数第 2 次启动，以此类推。

该命令会打印出大量的信息，你可能并不关注所有信息，只是关注其中问题相关部分。为此，系统提供了几个过滤器，用于帮助你锁定目标。让我们以进程号为 1 的进程为例，该进程是所有其它进程的父进程。

$ journalctl _PID=1

May 08 06:18:17 studio systemd[1]: Starting LSB: Raise network interfaces....
May 08 06:18:17 studio systemd[1]: Started LSB: Raise network interfaces..
May 08 06:18:17 studio systemd[1]: Reached target System Initialization.
May 08 06:18:17 studio systemd[1]: Started CUPS Scheduler.
May 08 06:18:17 studio systemd[1]: Listening on D-Bus System Message Bus Socket
May 08 06:18:17 studio systemd[1]: Listening on CUPS Scheduler.
[...]

这些打印消息显示了什么被启动，或者是正在尝试启动。

一个最有用的命令工具之一 systemd-analyze blame，用于帮助查看哪个服务进程启动耗时最长。

$ systemd-analyze blame
         8.708s gpu-manager.service
         8.002s NetworkManager-wait-online.service
         5.791s mysql.service
         2.975s dev-sda3.device
         1.810s alsa-restore.service
         1.806s systemd-logind.service
         1.803s irqbalance.service
         1.800s lm-sensors.service
         1.800s grub-common.service

这个特定的例子没有出现任何异常，但是如果存在系统启动瓶颈，则该命令将能发现它。