My question evolves around tor arm the controller used with tor. I hope I'm posting in the correct area as I'm not at all sure where the fault lies; either with Ubuntu or arm. If I'm in the wrong place apologies!

My relay has been in operation for little better than two weeks. I am new to tor relay. I've experienced the same problem several times. For the most part the relay takes care of itself with me checking it's operation periodically throughout the day. Until it happens.. I lose all Administrative functions with arm. Meanwhile, the relay seemingly continues to function as normal. The only solution I've found so far is to stop tor, and arm and do a hard restart. It's then good again for who knows how long until it happens again.

I've intentionally left out computer specifics as the computer itself is not the issue. It's software related either arm or Ubuntu OR both. How to sort it out, I am at a loss.

Thanks for any help everyone :-)


Upon further exploration!

From notices.log

Oct 29 04:31:51.000 [notice] Circuit handshake stats since last time: 90/90 TAP, 1/1 NTor.
Oct 29 04:31:51.000 [notice] Since startup, we have initiated 0 v1 connections, 0 v2 connections, 0 v3 connections, and 1820 v4 connections; and received 746 v1 connections, 315 v2 connections, 380 v3 connections, and 5426 v4 connections.
Oct 29 07:35:02.000 [notice] *Received reload signal (hup)*. Reloading config and resetting internal state.
Oct 29 07:35:02.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Oct 29 07:35:02.000 [notice] Read configuration file "/etc/tor/torrc".

So why am I getting a "reload signal??"


2 Answers 2


It's a startup scripts that are causing this - they're used to send sighup or even make a full reload if the service is failed to respond or send a heartbeat to systemd, stuff happens. In case of systemd - find tor's unit definition in /etc/systemd and check these values:


and do systemctl daemon-reload

  • There was no reference at all to tor in systemd. Now what? Adri
    – adriann
    Nov 2, 2017 at 12:12
  • @adriann systemctl list-unit-files has no mention? when tor is running - please send ps ax | grep tor output and attach your torrc config - we will take a look
    – Alexey Vesnin
    Nov 2, 2017 at 13:26

One source for a reload signal is likely to be the logrotate daemon.

If you look at the script in /etc/logrotate.d/tor you'll see that part of it's process is calling service tor reload. This is used to get Tor to append to the newly created log files, after the old ones have been moved to .1, .2, etc.

It shouldn't stop Tor from running, but it might interrupt your connection to the control port, simply exiting and restarting arm should resolve that without restarting Tor.

  • daily rotate 5 compress delaycompress missingok notifempty create 0640 debian-tor adm sharedscripts postrotate if service tor status > /dev/null; then service tor reload > /dev/null fi endscript }Ok.....The above is what is says... now what? Adri
    – adriann
    Nov 2, 2017 at 12:07
  • Well, it's normal for it to run. Does quitting arm and startingit again reconnect? If not, then there's nothing in the Tor logs that suggests that's the case and it would be helpful to see what arm reports and what the tor log reports at the time that you cannot connect with arm.
    – cacahuatl
    Nov 2, 2017 at 23:07

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .