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
@ppeb What are the contents of your systemd service file?
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.
Sorry, forgot the torrc:
User tor
MetricsPort 127.0.0.1:9035
MetricsPortPolicy accept 127.0.0.1
DisableDebuggerAttachment 1
DirCache 0
MaxAdvertisedBandwidth 800 KB
Log notice syslog
RunAsDaemon 1
DataDirectory /var/lib/tor
ORPort 9001
RelayBandwidthRate 1600 KBytes
RelayBandwidthBurst 3200 KBytes
Nickname and ContactInfo are set.
Some messages that are shown but are probably not relevant:
Unable to find IPv4 address for ORPort 9001. You might want to specify IPv6Only to it or set an explicit address or set Address
Jul 25 11:10:50.668 [warn] DirCache is disabled and we are configured as a relay. We will not become a Guard.
Necrobumping…I got the same issue with an “regular” Arch ARM on Raspberry Pi 3.
Did you find any solution?
Jul 25 12:18:33 alarmpi systemd[1]: tor.service: Supervising process 1391 which is not our child. We'll most likely not notice when it exits.
Jul 25 12:19:15 alarmpi Tor[1391]: Signaled readiness to systemd
Jul 25 12:19:15 alarmpi systemd[1]: Started Anonymizing overlay network for TCP.
Jul 25 12:20:15 alarmpi systemd[1]: tor.service: Watchdog timeout (limit 1min)!
Jul 25 12:20:15 alarmpi systemd[1]: tor.service: Killing process 1391 (tor) with signal SIGABRT.
Jul 25 12:20:15 alarmpi systemd[1]: tor.service: Killing process 1391 (tor) with signal SIGKILL.
Jul 25 12:20:15 alarmpi systemd[1]: tor.service: Killing process 1393 (tor) with signal SIGKILL.
Jul 25 12:20:15 alarmpi systemd[1]: tor.service: Killing process 1394 (tor) with signal SIGKILL.
Jul 25 12:20:15 alarmpi systemd[1]: tor.service: Killing process 1395 (tor) with signal SIGKILL.
Jul 25 12:20:15 alarmpi systemd[1]: tor.service: Killing process 1396 (n/a) with signal SIGKILL.
Jul 25 12:20:15 alarmpi systemd[1]: tor.service: Main process exited, code=killed, status=9/KILL
Jul 25 12:20:15 alarmpi systemd[1]: tor.service: Failed with result 'watchdog'.