Systemd 服务无法解析主机(名称解析暂时失败),但 root 用户可以

Systemd 服务无法解析主机(名称解析暂时失败),但 root 用户可以

我有一个 systemd 服务,它运行一个检查我的wireguard 连接的脚本。服务文件如下所示:

[Unit]
Description=Check the wg status and restart it if necessary
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/home/checkwg.sh

[Install]
WantedBy=multi-user.target

该脚本checkwg.sh如下所示:

#!/bin/bash

wgout=$(wg show)

if [[ ! -n $wgout  ]] # check to see if there is an active wg connection
then
        echo "wg appears down, reactivating..."
        wg-quick up myvpn # This line throws "Temporary failure in name resolution"
else
        echo "wg is up"
fi

有一个 if 语句检查 wg 是否已启动。如果它没有启动,那么它就会运行wg-quick up myvpn

当我以 root 身份运行该脚本时(我使用的是 Dietpi,因此只有一个用户 root),该脚本就可以工作。这是输出:

./checkwg.sh
wg appears down, reactivating...
[#] ip link add myvpn type wireguard
[#] wg setconf myvpn /dev/fd/63
[#] ip address add 10.0.4.54 dev myvpn
[#] ip link set mtu 1420 up dev myvpn
[#] ip route add 10.0.0.1/32 dev myvpn
[#] wg set myvpn fwmark 51820

但是当我尝试运行checkwg.service(通过 running systemctl restart checkwg)时,它给了我:

systemctl restart checkwg
journalctl -fu checkwg.service
May 17 10:22:30 camera systemd[1]: Started Check the wg status and restart it if necessary.
May 17 10:22:30 camera checkwg.sh[23181]: wg appears down, reactivating...
May 17 10:22:31 camera checkwg.sh[23181]: [#] ip link add myvpn type wireguard
May 17 10:22:31 camera checkwg.sh[23181]: [#] wg setconf myvpn /dev/fd/63
May 17 10:22:31 camera checkwg.sh[23181]: Temporary failure in name resolution: `myvpn.myhost.com:5555'. Trying again in 1.50 seconds...
May 17 10:22:32 camera checkwg.sh[23181]: Temporary failure in name resolution: `myvpn.myhost.com:5555'. Trying again in 2.25 seconds...
May 17 10:22:34 camera checkwg.sh[23181]: Temporary failure in name resolution: `myvpn.myhost.com:5555'. Trying again in 3.38 seconds...

为什么 systemd 无法解析我的主机,但 root 用户却可以?我相当有信心这不是wireguard问题,因为当我用wg-quick up myvpn它替换时ping google.com会引发相同的错误:Temporary failure in name resolution

答案1

系统升级(到 Fedora 38)后我遇到了同样的问题。通过添加以下内容修复了该问题:

LoadCredential=network.dns

在该[Service]部分下。

干杯,简。

相关内容