clash+systemd自启动问题

 Linux  clash  systemd 󰈭 654字

通常来说, 参考网上最常见的guide来配置systemd + clash 没有问题: <Running Clash as a service · Dreamacro/clash Wiki>

 1[Unit]
 2Description=Clash daemon, A rule-based proxy in Go.
 3After=network.target
 4
 5[Service]
 6Type=simple
 7Restart=always
 8ExecStart=/usr/local/bin/clash -d /etc/clash
 9
10[Install]
11WantedBy=multi-user.target

问题排查

但是在我的配置中(优先走的是url-test策略组)会出现一些问题:

  • 开机自启后, 大概率会出现完全无法走proxy的情况, 而且该问题近期才出现, 因而并不是因为clash的配置导致…

  • 经过研究发现, 如果开机后进入到clash-dashboard手动进行一次测速, 或是通过systemctl重启服务, 也可以规避该问题

因而认为是systemd启动时装载的顺序有问题, 导致clash启动后进行url-test, 但此时还无法上网, 结果对所有的节点都不通过…

经过测试, 修改为如下的配置即可:

1[Unit] Description=Clash service
2After=network-online.target
3Wants=network-online.target

把network-online也塞进来, 其中主要调用的是ExecStart=/usr/bin/nm-online指令:

 1[Unit]
 2Description=Network Manager Wait Online
 3Documentation=man:nm-online(1)
 4Requires=NetworkManager.service
 5After=NetworkManager.service
 6Before=network-online.target
 7
 8[Service]
 9# `nm-online -s` waits until the point when NetworkManager logs
10# "startup complete". That is when startup actions are settled and
11# devices and profiles reached a conclusive activated or deactivated
12# state. It depends on which profiles are configured to autoconnect and # also depends on profile settings like ipv4.may-fail/ipv6.may-fail, # which affect when a profile is considered fully activated.
13# Check NetworkManager logs to find out why wait-online takes a certain
14# time.
15
16Type=oneshot
17ExecStart=/usr/bin/nm-online -s -q
18RemainAfterExit=yes
19
20# Set $NM_ONLINE_TIMEOUT variable for timeout in seconds.
21# Edit with `systemctl edit NetworkManager-wait-online`.
22#
23# Note, this timeout should commonly not be reached. If your boot
24# gets delayed too long, then the solution is usually not to decrease
25# the timeout, but to fix your setup so that the connected state
26# gets reached earlier.
27Environment=NM_ONLINE_TIMEOUT=60
28
29[Install]
30WantedBy=network-online.target

后记

有时发现开机很慢, 使用systemd-analyze排查:

 1# systemd-analyze  blame
 26.405s NetworkManager-wait-online.service
 3 602ms dev-nvme0n1p5.device
 4 246ms systemd-udev-trigger.service
 5 224ms systemd-remount-fs.service
 6 220ms systemd-fsck@dev-nvme0n1p7.service
 7 204ms systemd-modules-load.service
 8 178ms systemd-fsck@dev-nvme0n1p6.service
 9 168ms systemd-timesyncd.service
10 163ms systemd-update-utmp.service
11 154ms systemd-backlight@leds:dell::kbd_backlight.service
12 152ms systemd-tmpfiles-setup-dev.service
13 136ms user@1000.service
14 131ms lvm2-monitor.service
15 131ms systemd-tmpfiles-setup.service
16 128ms modprobe@fuse.service
17 108ms systemd-fsck@dev-nvme0n1p1.ser

不过其实应该有其他的东西比较费时, 这里暂时记录一下而已, 具体原因有空了再排查

嗨! 这里是 rqdmap 的个人博客, 我正关注 GNU/Linux 桌面系统, Linux 内核, 后端开发, Python, Rust 以及一切有趣的计算机技术! 希望我的内容能对你有所帮助~
如果你遇到了任何问题, 包括但不限于: 博客内容说明不清楚或错误; 样式版面混乱等问题, 请通过邮箱 rqdmap@gmail.com 联系我!
修改记录:
  • 2023-05-29 23:05:14大幅重构了python脚本的目录结构,实现了若干操作博客内容、sqlite的助手函数;修改原本的文本数 据库(ok)为sqlite数据库,通过嵌入front-matter的page_id将源文件与网页文件相关联
  • 2023-05-09 00:04:01systemd-analyze blame
  • 2023-05-08 21:44:36博客架构修改升级
  • 2023-03-24 17:09:48clash与自启动问题
clash+systemd自启动问题