On 2/25/14, Roger Dingledine arma@mit.edu wrote:
On Tue, Feb 25, 2014 at 02:27:22PM +1100, Zenaan Harkness wrote:
tor should never stop running (or crash) with just a config file reload!
Alas, I disagree. The alternative is that it *doesn't* stop running, yet you think it's using the new torrc file when it isn't. That would be a worse kind of surprise.
Unless you have a third alternative that is better? I agree that the current state is not great.
That said, we *do* have a partial answer, in the init script itself -- it runs Tor with --verify-config to make sure that the config file itself is parseable. So the remaining trouble is when the config file is parseable, but the requested changes are incompatible with Tor's current state.
Aha. Thank you.
What would be preferable from my personal POV is that an attempt to load the config file would fail with an error output to the console. In debian, there are six standard options for service management:
status start stop reload restart force-reload
reload ought not cause the daemon to stop. Sometimes daemons have restart and force-reload be the same thing.
force-reload is where the daemon might be restarted if there is a config file change which cannot be effected otherwise.
At least, that's my understanding, although I'm not an expert sorry.
DisableDebuggerAttachment 0
This is the only change, the one which subsequent to adding that option, and running service tor reload, tor apparently stopped running, as above.
Yes. Please read your Tor logs where it explains why.
https://www.torproject.org/docs/faq#Logs
So the only change that I am aware of that could have caused the HSDir flag (as shown in arm) to go away, was either that option (DisableDebuggerAttachment 0), or simply the fact that the relay crashed (or somehow otherwise stopped running).
It's the latter -- the HSDir flag is a function of the stability of your relay. See https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l1867
Thank you for the pointers and clarity. Very much appreciated. Zenaan