I’m trying to run a relay on my Arch server, and for some reason when running it as a systemd service it gets killed by watchdog very quickly. This doesn’t happen to any of my other systemd services so I have no idea what’s going on.
Logs from start to kill:
https://hst.sh/ehufonikef
As a side note, it’s also unable to find ipv6 address and I don’t know how to fix that either, although that’s less of a concern.
Hm! Some initial thoughts that might help:
Your Tor logs look good. Your Tor is starting, bootstrapping, checking its reachability, and everything looks as expected.
It appears that systemd is expecting some sort of “it worked” response from Tor, and it waits 1 minute and doesn’t get it so it assumes the Tor launch has failed and tries to kill it.
So my first thought is that there is a bug somewhere in the arch package, where it is expecting the wrong thing or otherwise not recognizing that Tor did successfully start.
But googling around for your messages like “tor.service: Watchdog timeout (limit 1min)!” doesn’t show anybody else with this issue. If it’s a bug with the arch package in general I would expect many more people to be reporting it.
So: is there anything unusual or unique or nonstandard about your Arch set-up? 
(Thanks for wanting to run a relay!)
There’s nothing non-standard or special about my setup as far as I know.
I’ve tried building tor from source and it still has the issue so I know it’s not the package’s fault.
how to Relay Monitor using linux kali? i try arm nothing happen
idk but i do with nyx on ubuntu
Hm. When you build Tor from source, do you then run it under the same systemd init script? That systemd file is part of the Tor package, and it seems to be the comonent that is causing the problem.
This is all default except for the user and group, which doesn’t seem to be a problem since it’s with or without it. And yes, I ran it under the same systemd file when from source.
# relatively conservative, hardened Tor service. You may need to
# edit it if you are making changes to your Tor configuration that it
# does not allow. Package maintainers: this should be a starting point
# for your tor.service; it is not the last point.
[Unit]
Description=Anonymizing overlay network for TCP
After=syslog.target network.target nss-lookup.target
[Service]
User=toruser
Group=tor
Type=notify
NotifyAccess=all
ExecStartPre=/usr/bin/tor -f /etc/tor/torrc --verify-config
ExecStart=/usr/bin/tor -f /etc/tor/torrc
ExecReload=/bin/kill -HUP ${MAINPID}
KillSignal=SIGINT
TimeoutSec=60
Restart=on-failure
WatchdogSec=1m
LimitNOFILE=32768
# Hardening
PrivateTmp=yes
PrivateDevices=yes
ProtectHome=yes
ProtectSystem=full
ReadOnlyDirectories=/
ReadWriteDirectories=-/var/lib/tor
ReadWriteDirectories=-/var/log/tor
NoNewPrivileges=yes
CapabilityBoundingSet=CAP_SETUID CAP_SETGID CAP_NET_BIND_SERVICE CAP_DAC_READ_SEARCH
[Install]
WantedBy=multi-user.target
Decided to try removing the WatchdogSec=1m line. It seems to have worked. I’ll post again if it breaks.
How are you starting the Tor service?
I would suggest also asking this question in the Arch community, since the most likely explanation is that it is something wrong with either the Arch package or with how you are using it.
(Maybe there are some Arch users here who can jump in and help too.)
Actually had the same issue on CentOS 8: Debian Pastezone
Disabling “dnf makecache” fixed the issue for me.
I am starting the service with systemctl (systemctl enable and start). Also dnf-makecache doesn’t seem to exist on arch.
It’s started happening again, all information is essentially the same as before.
Systemd logs https://paste.ppeb.me/etecomufov
Systemd service https://paste.ppeb.me/reqazikaro
Still zero idea what fixed it last time.