请对 systemd 做如下设置，避免它将你的用户进程调整为更容易被杀：
建立 /etc/systemd/user.conf.d/oom.conf 文件，并写入：
[Manager] DefaultOOMScoreAdjust=0
建立 /etc/systemd/system/user@.service.d/resources.conf 文件（及其中间目录），并写入：
[Service] OOMScoreAdjust=0
systemd 的默认设置也会干扰火狐浏览器自己的设定，造成与预期相反的行为。
有个服务器需要维护，因此需要将其上的所有服务暂时迁移走。打算直接扔到另一台比较闲的服务器上，直接拿 systemd-nspawn 跑起来得了。简单方便，除了网络之外不需要额外配置。但问题是，这些服务里包含一个使用 docker 运行的 ElasticSearch，在同为容器的 nspawn 里跑会有问题吗？
试了一下，还真有的问题。dockerd 会报权限错误而跑不起来。但稍微搜一下就找到了解决方案：
SYSTEMD_SECCOMP=0 systemd-nspawn --capability=all --network-bridge=br0 --boot -D rootfs
nspawn 默认会限制一些权限。这样可以让其不做任何限制，相当于 docker 的 --privileged 参数。然后就可以嵌套着跑啦。
跑起来之后检查一下，所有服务均正常运作了，没有任何问题。把网络配好，外边的 nginx 负责一下转发（因为懒所以没配外网 IP），就可以接替工作啦。
PS: 迁移的过程中遇到了一个小坑。rsync 不加 --numeric-ids 的话会尽量保持用户名不变，等里边的系统跑起来就各种权限问题了。所以转移 rootfs 的时候一定得记着加上 --numeric-ids。
PaddleOCR 发布 2.6 版本了，支持 Python 3.10 啦，于是可以在 Arch Linux 上跑了～所以我决定再部署一次。
我之前跑 PaddleOCR 有两个方案，使用 chroot 加一大堆 systemd 的限制选项，以及使用 bwrap 和用户命名空间。
chroot 的方案总感觉不知道限制够了没。实际上当初那篇文章写完我就意识到这服务怎么用我的 uid 在跑啊，乱发信号好像还能把我的进程都杀掉的样子。另外这个 chroot 其实是我用来学习、研究和适配 Debian 用的，并不是专门跑这个服务的，感觉有点——怎么说呢——碍事？总之不太好。
bwrap 方案更干净一些，不过创建起来挺麻烦的（所以我才只部署了一次嘛）。不使用用户命名空间可能会简单一些，但那样就是用我的用户在跑了。
所以这次我决定试试方案，使用 systemd-nspawn。另外（再次）尝试了使用 NVIDIA GPU 的版本，把我电脑上闲得发慌的 GeForce 940MX 显卡给用上了。
首先去 Arch 镜像里的 iso/latest/ 目录下载个 archlinux-bootstrap-x86_64.tar.gz 回来。在 /var/lib/machines 下创建个叫 paddleocr 的 btrfs 子卷 / zfs 文件系统 / 普通目录用来存放新的 rootfs。sudo bsdtar xf ...... -C /var/lib/machines/paddleocr 解压出来。记得一定要用 bsdtar 以避免丢失某些文件元信息（虽然我不知道那些信息有啥用但是有警告就是不爽嘛）。
然后就可以 systemd-nspawn -M paddleocr 拿到个 shell 了。这里边只安装了 base 和 arch-install-scripts。可以先修改 pacman 镜像然后 pacman -Syu python 滚一下顺便装上 Python。然后 useradd -s /bin/bash -m -U paddleocr 创建个跑 paddleocr 的用户。su - paddleocr 切过去，python -m venv venv 创建虚拟环境，然后进去按 PaddleOCR 的文档装就行了。装好运行起来没问题之后，写个 for 循环把所有支持的语种都识别一遍，以下载各语言的模型（当然你也可以只下载你想要的）。做好之后可以清一下缓存啥的。gdu 就挺好用的。
哦，以上是 CPU 版本的安装流程。GPU 版本的可没有这么简单。首先要把显卡设备传进这个 nspawn 里。创建 /etc/systemd/nspawn/paddleocr.nspawn 文件，然后里边写上：
[Exec] ResolvConf=off NoNewPrivileges=true User=paddleocr [Files] Bind=/run/paddleocr Bind=/var/cache/pacman/pkg Bind=/dev/nvidia0 Bind=/dev/nvidiactl Bind=/dev/nvidia-modeset Bind=/dev/nvidia-uvm Bind=/dev/nvidia-uvm-tools [Network] Private=true
哦，这里有挂载 pacman 缓存目录前边忘了说，不过这个不重要啦。这里指定了用户，但是可以在命令行上用 -u root 覆盖的，不影响进去维护。私有网络，也就是给它配置个网络命名空间，里边除了 lo 外啥网络接口都没有。那它怎么访问网络呢？它访问不了网络啦。所以要 bind mount 进去一个 /run/paddleocr，用于通信的 UNIX 域套接字将会放在这里。网络不通，走文件系统就好啦。
然后找台机器把 AUR 包 cuda-10.2 和 cudnn7-cuda10.2 打一下，但是不用安装。我们不搞 CUDA 开发，里边有一大堆东西都是不需要的。把需要的库复制进 rootfs 里去就行了。至于需要什么库？进那个虚拟环境的 Python 里，import paddle 然后 paddle.utils.run_check() 跑一下就知道了。复制库之后记得跑 ldconfig 啊。
PaddleOCR 能跑起来之后，就可以把我的服务丢进去跑啦。最终命令长这样：
sudo systemd-nspawn -M paddleocr --user=paddleocr /home/paddleocr/paddleocr-http --loglevel=warn -j 4
-j 参数是限制并发识别数的，避免过载 CPU 或者 GPU，并不是线程数。
跑起来之后，sudo setfacl -m u:$USER:rwx /run/paddleocr/http.sock 给自己授权，然后 curl 一下试试：
time curl -sS -F file=@a.png -F lang=zh-Hans --unix-socket /run/paddleocr/http.sock http://localhost:5174/api | jq .
对于小图片的话挺快的，不到一秒就能出结果。我使用 CPU 版本跑的话，会慢个近十倍的样子。顺便说一下，这是我对服务进行性能优化之后的结果。之前每张图都开新进程跑太慢了。大概是需要加载一大堆库，然后把模型上传到 GPU，每张图一进程的话 GPU 版本反而会明显慢于 CPU 版本。代价是服务会一直占用大约 2G 内存，即使你并没有在用。
系统挂起到内存或者休眠到磁盘时，内存里的内容是被保留了，但是 GPU 显存并没有，大概因此会报 cuda runtime error 999。这时候，只需要停止服务，卸载 nvidia_uvm 内核模块然后重新加载，再启动服务就可以恢复了。如果 nvidia_uvm 卸载不掉的话，那就没办法了，要么重启，要么改用 CPU 版本。NVIDIA 是有个把显存 dump 到内存里存起来的方案的，但是没必要啊，尤其是休眠到磁盘上的时候，多浪费时间啊。
你可以直接用我做好的文件。通过本地的 IPFS 服务访问：
http://localhost:8080/ipns/k51qzi5uqu5di433o42zgqk2xck3y160q1hyvqbyyerd36au2pk0c2jw3hcqxx/
你也可以用别的网关来访问，都一样。如果 IPNS 解析失败的话，试试
http://localhost:8080/ipfs/QmNV31bApmgRcHCQjGufQ3zrFDaf6JBWvBt8pU2TA2Baz6/
我把用于跑服务、设置权限的配置文件打了个 Arch 软件包。nspawn 用的 rootfs 也打包上传了。PaddleOCR CPU 和 GPU 版本是分开的，所以有两个包。CPU 版本的 nspawn 叫 paddleocr-cpu，服务名也是。把 rootfs 解压到正确的地方之后，systemctl start paddleocr 或者 paddleocr-cpu 就好啦。用户需要加入 paddleocr 组才能访问 HTTP 套接字哦。
如果遇到CUDA error(803), system has unsupported display driver / cuda driver combination报错，请将系统当前的 libcuda.so.1 复制进 nspawn 里：
sudo cp /usr/lib/libcuda.so.1 /var/lib/machines/paddleocr/usr/local/lib
另外服务配置文件放到 GitHub 上了：paddleocr-service。
2024年04月20日更新：autogroup 仅对位于根 cgroup 中的进程有效。而在现在使用 systemd 的系统中，默认会使用 cgroup v2，没有进程位于根 cgroup，autogroup 也就不起效了。如果没有开启 cgroup 的 cpu 控制器的话，进程的 nice 值将起效。
假设有一个程序叫 use-cpu，它运行的时候会一直消耗一个 CPU 核心。试问，如果我开两个终端窗口，分别执行以下两个进程，其 CPU 会如何分配？
$ taskset 2 ./use-cpu $ taskset 2 nice -n 10 ./use-cpu
两个进程都在1号CPU上运行，意味着它们必定争抢时间片。第二个进程使用 nice 命令设置其 nice 为 10，那么，是不是第二个进程会占用比较少的 CPU 呢？
很合情合理的推理，然而答案是否定的。
呃，也不一定。cat /proc/sys/kernel/sched_autogroup_enabled 看一下，这个开了的话，CPU 调度会多一个层级。默认是开的，所以这两个进程会均分 CPU 时间。
首先说好了呀，这里只讨论普通进程（SCHED_OTHER）的调度。实时进程啥的不考虑。当然啦，CPU 分配只发生在 R（Runnable）状态的进程之间，暂时用不到 CPU 的进程不管。
最上面的层级是 cgroups 了。按照 cgroup 层级，每一层的子组或者进程间按权重分配。对于 cgroups v1，权重文件是 cpu.shares；cgroups v2 则是 cpu.weight。不管用哪个版本的 cgroups，systemd 默认都没有做特别的设置的。对于 v1，大家全在根组里；对于 v2，CPU 控制器都没有启用。如果你去设置 systemd 单元的 CPUWeight 属性（或者旧的 CPUShares 属性），那么 systemd 就会开始用 cgroups 来分配 CPU 了。一个意外的状况是，使用 cgroups v2 时，systemd-run 不会自动启用上层组的 CPU 控制器，以至于如果上层未手动启用的话，设置不起作用。在使用 cgroups v1 时，用 systemd 设置 CPUWeight 或者 CPUShares 也不太好用，因为它并不会自动把进程挪到相应的层级里去……
其次就是这个默认会开的 autogroup。这个特性是为了提升交互式的桌面系统的性能而引入的，会把同一 session 的进程放一个组里。每个 autogroup 作为一个整体进行调度，每个 autogroup 也有个 nice 值，在 /proc/PID/autogroup 里可以看到，也可以 echo 一个想要的 nice 值进去。至于这个 session，不是 systemd 的那个 session，而是传统 UNIX 的那个 session，也是 setsid(2) 的那个 session。我一直以为它没多大作用，没想到在这里用上了。基本上，同一群进程会在同一个 session 里（比如一群火狐进程，或者一群 make 进程），同一个终端里跑的进程也都在一个 session 里（除非你 setsid 了）。
最后才是轮到进程。其实准确地讲是线程。同一个 autogroup 里的时间片如何分配，就看里边这些线程的 nice 值的大小了。所以其实，我系统里的那些高 nice 值的进程，由于 autogroup 的存在而它们又没有去设置 autogroup 的 nice 值，其实调度起来没什么差别的。
man 7 schedman 7 cgroups最近我的系统有这么个问题：在备份或者系统更新等高 I/O 负载的时候，系统整体性能下降严重，界面经常卡到动不了。经过分析发现此时比平常多了许多磁盘读操作。平常的时候磁盘读操作是很少的，会有大量的缓存命中，反倒是写操作一直都有（因为我本地搭了个监控系统）。啊对，分析用到的磁盘性能数据就是来自于这个监控系统。
所以原因很清楚了：备份和系统更新不仅造成了大量缓存未命中，还占用了本来存放着热数据的缓存，导致常规使用的缓存命中率也急速下降，结果我的机械硬盘就忙不过来了。
那么，要是能够限制这些操作占用的缓存，性能不就能好一点吗？那些新读进来的数据反正是短期内再也用不到了，缓存起来也只是浪费有限的内存空间啊。
研究了一下 /sys/fs/cgroup/memory/memory.stat，看起来 cgroups 内存限制是包含缓存部分的，于是就试试呗。正好 systemd 直接就能设置了：
$ sudo systemd-run -p MemoryMax=512M --scope pacman -Syu
本来我是设置的 256M 限制，结果发现 dkms 编译内核模块的时候超级慢，还用掉了不少 swap……于是分了 512M。效果还是不错的，常规操作偶尔还是卡一卡（毕竟还是有一些 I/O 操作），但比起不限制的时候要少很多。
要注意一点的是，不使用 cgroups v2 的话（Arch Linux 默认），这个命令不能加 --user 以在用户级的 systemd 下跑的。而使用 cgroups v2 的话，lxc 和 docker 都跑不了……
备份也是类似的，而且因为 rsync 自己用不到多少内存，这个效果更好：
$ systemd-run -p MemoryMax=256M --scope ./backup-my-system
终于又一次在半小时内完成了备份 QAQ 之前动不动就一两小时的。
我也不知道为什么这个问题近期才出现，总之现在是缓解了。（接下来有空继续计划换 SSD 硬盘的事情～
2020年10月06日更新：现在知道系统在内存不足、使用 swap 的时候出现的卡顿现象可能是这个 bug，并且在 5.5 版本中被修复。我在迁移到 SSD 之后也一直禁用 swap 也是因为这个问题。现在更新到 5.8 之后开启 swap，并没有在 swap 时发生明显的卡顿了。PS: 关于 swap 是干嘛的，可以参看 farseerfc 的这篇《【譯】替 swap 辯護：常見的誤解 》以及后续。
最近学 wzyboy 搭了一套 collectd + Graphite + Grafana 监控。collectd 和 Grafana 都比较好搞，Arch 官方源里有。但是 Graphite 就没有了。
我没有使用 Python 2 版、带 Web 前端的 Graphite 包，而是使用 graphite-api 提供 Web API，python2-carbon 存储数据。它们在 AUR 上有，其中 python2-carbon 是相当危险的（现在已经改了）。
为什么危险呢？
首先，最明显的，carbon 服务以 root 用户运行。它本身没有任何使用 root 权限的必要，所以专门创建一个 carbon 用户更好。
其次，它运行起来之后，我发现是监听 0.0.0.0 的。这个也无必要：我的 collectd 就在本地呢。
最后，也是最吓人的：它默认开启了接收 pickle 数据的端口。Python pickle 模块的文档一打开，就能看到红色的警告，告诉人们不能接收不信任来源的 pickle 数据。而我曾经工作过的公司也发生过通过 pickle 注入代码的事情：攻击者发现了一个对外网开放的 Redis 服务，刚好那个 Redis 是给 Celery 用的。攻击者于是往里边写了条自己构造的 pickle，在解析时调用 curl 命令向其服务器报告IP、端口和当前UNIX用户的信息。
这接口，开在外网，就是远程代码招行；开在本地，就是本地提权。很危险的。
为了防止各种漏洞被利用，一个未雨绸缪的办法就是：权限最小化。本来这是件比较麻烦的事情，好在 systemd 提供了许多现成的配置项，使得给 carbon 这种服务加固简单易行。
首先创建用户，写一个 sysusers 文件就可以了：
u carbon - "carbon service" /var/lib/carbon
然后，它需要使用文件系统的某些部分。那么别的就用不着访问了，比如 /home。而 /dev、/tmp 这些，自己用自己的就好。连 / 也不让写，也不允许获取任何新特权了。其实使用 carbon 用户它本来就写不了 / 也没有任何特权了，但以防万一嘛，要是哪里来个本地提权漏洞呢？
[Unit] Description=Graphite/Carbon After=network.target [Service] Type=forking ExecStart=/usr/bin/carbon-cache.py --config=/etc/carbon/carbon.conf start User=carbon PrivateTmp=true PrivateDevices=true ProtectSystem=full ProtectHome=true NoNewPrivileges=true CapabilityBoundingSet= ReadOnlyPaths=/ ReadWritePaths=/run ReadWritePaths=/var/log/carbon ReadWritePaths=/var/lib/carbon [Install] WantedBy=multi-user.target
限制文件系统的访问，systemd 配置起来很方便，我打包的时候喜欢尽量加上。
最近公司弄了 Wi-Fi 登录。就是那个叫 captive portal 的东西。
Android 早就会在连接 Wi-Fi 时检测网络是不是要登录了，为此 Google 弄了个 /generate_204 的 URL。小米、高通、USTC、v2ex 也都提供了这个东西，方便广大中国大陆 Android 用户使用。（我发现我的 Android 使用的是高通的地址，没有用 Google 的。）
但我使用的 Arch Linux 自行开发的 netctl 网络管理工具没这种功能。火狐倒是不知道什么时候加上了，不过使用的地址 http://detectportal.firefox.com/success.txt 是返回 200 的。
所以我启动火狐就可以看到要登录的提示了。然而问题是，其它程序不知道要登录啊。像 offlineimap、openvpn、rescuetime 这种还好，会自己重试。可每次网络需要登录的时候 dcron 就会给我发一堆邮件告诉我我的 git pull 都失败了……当然还有我老早就注意到的 pkgstats，经常会因为启动过早而无法发送统计数据。
所以呢，得想个办法，等连上互联网之后再跑那些脚本啊服务什么的。
检测是不是连好了很简单，不断尝试就可以了。但我需要一个系统级的 Condition 对象来通知等待方可以继续了。然而我只知道 Linux 有提供信号量。难道要自己弄共享内存来用么？
去 #archlinux-cn 问了一下，farseerfc 说试试命名管道。我想了想，还真可以。只有读端的时候进程就会阻塞，一旦有写端就能成功打开了。当然没有读端的打开写端会打不开，不过没关系，反正这进程也不能退出，得一直拿着这个文件描述符。
没想到很少用到的命名管道有意想不到的用法呢。我以前还为了不阻塞而专门写了篇文章呢。
于是负责检测网络连通的 check-online 和等待网络连好的 wait-online 都写好了。
check-online 应当是个服务。那就交给 systemd 吧。然后……systemd 不是有个 network-online.target 么？正好可以让 check-online 来达成这个目标呢，多合适呀。
于是服务写好了。测试了几天，大成功！不仅 wait-online 很好地工作了，而且我发现 openvpn 和 pkgstats 自动排到 network-online.target 后边去了。nginx 的 OSCP staple 经常因为 DNS 失败而无法成功，我也可以在联好网之后去 reload 一下它了。（不是强依赖，我可不希望连不上网的时候我本地的 wiki 也访问不了。）
整个项目就叫作 wait-online，在 GitHub 上，欢迎送小星星哦～Arch Linux 包可以从 [archlinuxcn] 仓库 安装 wait-online-git 包。
我在用 offlineimap。用着用着就发现一个问题：偶尔 offlineimap 会卡在网络上不动弹了。跟 getmail 一个德性……
但是 offlineimap 又跟 getmail 有点不一样，它是持续运行着的。虽然非要把之前那个 killhung 程序拿来用不是不可以，但我还是重新弄了一个更优雅的方案：systemd watchdog。
我的 offlineimap 本来就是用 systemd 服务的方式来跑的，所以很适合这样的改造呢。只是，当我瞅了一眼源码之后，我就放弃了 patch offlineimap 的打算。很难在合适的地方添加 watchdog 相关的代码。
既然从内部着手不好做，那就从外部写一个 wrapper 好了，反正 offlineimap 跟 getmail 不一样，正常情况下一直在输出东西，就把这个作为它的「心跳」特征好了。当然这个 wrapper 还可以给其它程序用。
于是，watchoutput 程序诞生了！稍微改一下 offlineimap 的 .service 文件，像这样子就好了：
[Unit] Description=Offlineimap Service [Service] Type=notify ExecStart=.../watchoutput /usr/bin/offlineimap TimeoutStopSec=3s SyslogIdentifier=offlineimap Restart=on-failure WatchdogSec=70 LimitCORE=0 [Install] WantedBy=default.target
加上LimitCORE=0是为了阻止重启的时候由于 SIGABRT 信号导致 coredump，浪费磁盘空间。
用了几天之后，终于观察到一次由 watchdog 触发的重启：
12月 19 12:26:53 lilywork offlineimap[21623]: Establishing connection to imap.exmail.qq.com:993 (main-remote) 12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Watchdog timeout (limit 1min 10s)! 12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Killing process 21623 (python3) with signal SIGABRT. 12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Killing process 21625 (offlineimap) with signal SIGABRT. 12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Main process exited, code=dumped, status=6/ABRT 12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Unit entered failed state. 12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Failed with result 'core-dump'. 12月 19 12:28:03 lilywork systemd[687]: offlineimap.service: Service hold-off time over, scheduling restart. 12月 19 12:28:03 lilywork systemd[687]: Stopped Offlineimap Service. 12月 19 12:28:03 lilywork systemd[687]: Starting Offlineimap Service... 12月 19 12:28:04 lilywork systemd[687]: Started Offlineimap Service.
没过几天，我又给这个 watchoutput 的脚本找到另外的用处：自动重启网络。
我家里的笔记本连 Wi-Fi 不知怎么，这些天经常会卡住（只发不收，一直处于 ARP 找网关的状态）。内核之前报过一次错，现在也没反应了。
于是：
[Unit] Description=Watch for network availability [Service] Type=notify ExecStart=.../watchoutput --retry-on-exit 2 --wait-before-retry 30 --ignore-stderr \ -- ping -i 30 192.168.1.1 Restart=on-failure WatchdogSec=70 StandardOutput=null StandardError=journal LimitCORE=0 SyslogIdentifier=watch-network [Install] WantedBy=default.target
拿 watchoutput 监控 ping 网关的输出，每30秒 ping 一次，如果70秒还没反应就重启它自己。然后我们还需要重新连接网络。在 /etc/systemd/system 下建立 netctl-auto@wlan0.service.d 目录，并在其下建立一个 watchdog.conf 文件，给 netctl-auto@wlan0.service 服务增加一项配置：
[Unit] PartOf=watch-network.service
这样当 watch-network.service 重启的时候，netctl-auto@wlan0.service 就会自动重启了～
首先看看你的网卡和驱动组合是否支持这样的操作。
>>> iw list | grep -A2 combinations:
valid interface combinations:
* #{ managed } <= 1, #{ AP, P2P-client, P2P-GO } <= 1, #{ P2P-device } <= 1,
total <= 3, #channels <= 2
上边这个输出说明支持，并且频道可以不一样。
然后，添加一个用途 AP 的网络接口，并配置 IP 地址。我的无线网络接口名字是 wlan0，因为我通过创建空 /etc/udev/rules.d/80-net-setup-link.rules 文件的方式禁用了 systemd 的网络接口改名。
sudo iw dev wlan0 interface add wlan0_ap type __ap sudo ifconfig wlan0_ap 192.168.17.1
配置 NAT：
echo 1 | sudo tee /proc/sys/net/ipv4/ip_forward sudo iptables -w -t nat -A POSTROUTING -s 192.168.17.0/24 -j MASQUERADE
配置 DHCP。我用的是 dnsmasq。它本来是作为 DNS 缓存用的，但是也支持 DHCP，那就用它了：
interface=wlan0_ap no-dhcp-interface=wlan0 dhcp-range=192.168.17.50,192.168.17.150,12h
注意不要在其它只提供 DNS 服务的接口上提供 DHCP 服务，以免出现冲突。
然后就可以开启热点啦。hostapd 配置如下：
interface=wlan0_ap driver=nl80211 ssid=名字 channel=1 hw_mode=g ieee80211d=1 country_code=cn ieee80211n=1 ieee80211h=1 ignore_broadcast_ssid=0 auth_algs=1 wpa=2 wpa_passphrase=secret wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP rsn_pairwise=CCMP
最后把它们跑起来就可以了。
为了方便使用，我创建了个 systemd 服务 wlan0_ap.service：
[Unit] Description=Setup wlan0_ap Before=hostapd.service After=sys-subsystem-net-devices-wlan0.device After=iptables.service [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/bin/iw dev wlan0 interface add wlan0_ap type __ap ExecStart=/usr/bin/ip address add dev wlan0_ap 192.168.17.1/24 ExecStart=/usr/bin/iptables -w -t nat -A POSTROUTING -s 192.168.17.0/24 -j MASQUERADE ExecStop=-/usr/bin/iptables -w -t nat -D POSTROUTING -s 192.168.17.0/24 -j MASQUERADE ExecStop=/usr/bin/ip address delete dev wlan0_ap 192.168.17.1/24 ExecStop=/usr/bin/iw dev wlan0_ap del [Install] WantedBy=hostapd.service
systemctl enable wlan0_ap 之后就可以直接 systemctl start hostapd 来启动了～当然也很容易停止服务：systemctl stop hostapd wlan0_ap。我的 dnsmasq 总是开启的，所以就不用加依赖了。还有 ipv4_forward 我也是早就写到配置文件 /etc/sysctl.d/99-sysctl.conf 里的。
从这里看到 ssh 的 Control master 特性之后，就在~/.ssh/config里启用了这个特性：
ControlPath ~/.ssh/master-%r@%h:%p ControlMaster auto ControlPersist yes Compression yes
会话连接复用，对于以交互操作的使用，很不错的！对低延迟的服务器可能只是少了用户认证过程，但对于连接国外服务器，少了 TCP 握手、SSH 握手与认证等来来回回的过程，连接会快非常多的，尤其是对于常用的服务器，比如 GitHub 之类的，提速非常明显。
然后，问题就来了：系统挂起再恢复之后，大部分连接会 stalled，需要手工断开连接。即使配置了超时，它也不一定及时。于是我想，既然 netctl-auto 之类的服务能够在挂起系统时适当处理，那么我是不是也能写一个用户级的 systemd 服务来处理这件事情呢？
于是我按系统级的配置方法弄好了，结果什么也没有发生……后来才明白，只有系统级的 sleep.target，没有用户级的啊。
在 Arch Linux 官方论坛看到有人这么尝试，让系统级的 systemd 调用用户级的 systemd。配置有点不对，但是想法是非常好的！
于是就有了我现在用的方案：
[Unit] Description=sleep.target of a systemd user session Before=sleep.target StopWhenUnneeded=yes [Service] Type=oneshot User=%I Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/bus RemainAfterExit=yes ExecStart=/usr/bin/systemctl --user start sleep.target ExecStop=/usr/bin/systemctl --user stop sleep.target [Install] WantedBy=sleep.target
启用（enable）user-sleep@1000.service之后，系统挂起时，就会调用 ID 为 1000 的用户的用户级 systemd，也 reach sleep.target 啦。当然这个用户级的 sleep.target 也得自己写：
[Unit] Description=Sleep Documentation=man:systemd.special(7) DefaultDependencies=no StopWhenUnneeded=yes
然后就可以让用户级的服务WantedBy=sleep.target啦～
| Theme: Aeros 2.0 by TheBuckmaker.com