If we touch the Ed25519 master ID key, Tor ignores the torrc file after reload signal (HUP)
Tor 0.2.7.2-alpha on Debian Jessie.
Tor generated an Ed25519 master ID key in /datadirectory/keys and started relay functionality fine. We were in the consensus, all going normal. The RSA identity was previously there - this was an upgrade from Tor 0.2.5.12. Signing key and key-cert were also generated for 30 days (default), since I didn't configure a SigningKeyLifetime argument in torrc.
After the first reload signal (HUP), probably for log rotation, Tor ignored the existent and otherwise working config file in /etc/tor/torrc:
Jul 31 08:48:26.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Jul 31 08:48:26.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jul 31 08:48:26.000 [warn] Couldn't find $HOME environment variable while expanding "~/.torrc"; defaulting to "".
Jul 31 08:48:26.000 [notice] Configuration file "/etc/tor/torrc" not present, using reasonable defaults.
I moved the Ed25519 master ID key back to /datadirectory/keys. Did a service tor restart/start (not reload). It worked with the config file in /etc/tor/torrc and started just fine:
Jul 31 08:53:01.000 [notice] Bootstrapped 100%: Done
Jul 31 08:53:01.000 [notice] Now checking whether ORPort <ipv4>:port is reachable... (this may take up to 20 minutes -- look for log messages indicating success)
Jul 31 08:53:02.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jul 31 08:53:53.000 [notice] Performing bandwidth self-test...done.
To test, I tried again service tor reload. Again it ignored my config file in /etc/tor/torrc and disabled relay functionality:
Jul 31 10:55:59.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Jul 31 10:55:59.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jul 31 10:55:59.000 [notice] Configuration file "/etc/tor/torrc" not present, using reasonable defaults.
Jul 31 10:55:59.000 [notice] Opening Socks listener on 127.0.0.1:9050
Jul 31 10:55:59.000 [notice] Closing no-longer-configured Control listener on 127.0.0.1:9051
Jul 31 10:55:59.000 [notice] Closing no-longer-configured OR listener on <ipv6>:port
Jul 31 10:55:59.000 [notice] Closing no-longer-configured OR listener on <ipv4>:port
Jul 31 10:55:59.000 [notice] Tor 0.2.7.2-alpha-dev (git-cedc651deb9e9db6+2b91e7f) opening log file.
Jul 31 10:55:59.000 [notice] Closing old Control listener on 127.0.0.1:9051
Jul 31 10:55:59.000 [notice] Closing old OR listener on <ipv6>:port
Jul 31 10:55:59.000 [notice] Closing old OR listener on <ipv4>:port
Here are the permissions on the Ed25519 master ID key:
File: `ed25519_master_id_secret_key'
Size: 96 Blocks: 8 IO Block: 4096 regular file
Device: 47a0b641h/1201714753d Inode: 394256 Links: 1
Access: (0600/-rw-------) Uid: ( 102/debian-tor) Gid: ( 104/debian-tor)
Access: 2015-07-31 08:49:46.734656706 -0400
Modify: 2015-07-01 13:32:27.213920044 -0400
Change: 2015-07-29 04:02:46.913674620 -0400
Birth: -
I want to highlight that I have other relays running 0.2.7.2-alpha (the same upgraded from 0.2.5.12) where I haven't touched the Ed25519 master ID key and they work very well unattended, nothing weird happens after a reload signal (HUP).