Open vbmithr opened 10 years ago
Sorry, we have 2 problems with this: 1) automation. we almost never set up a cluster by hand (we use an automation framework for this) and even worse: 2) expert bias: we've been working on Arakoon for a long time, and no longer notice these things. If you list the things you bumped into, that would be rather helpful.
Ok I will help you on that when I bump into some undocumented error :)
[vb@nerenyi ~/code/avahi-arakoon-mgr]% arakoon -config var/arakoon.cfg --node nerenyi
zsh: exit 1 arakoon -config var/arakoon.cfg --node nerenyi
Something went wrong… but what?
take a look in nerenyi.log ?
On 15/12/2013 19:12, Romain Slootmaekers wrote:
take a look in nerenyi.log ?
It was that I put "::" for the ip on a non-ipv6 enabled version. The point is that there was no way to guess it. Thank for the pointer to the log file!
Anyway, I think it would be good to leave the exception escape the program rather than catch it and just exit with error code 1 with no other message. Alternatively maybe just print something like "have a look at the log file" but I would prefer the first solution.
Is there any rationale for exiting with error instead of letting the exception kill the program ?
Well, it's more of a necessity than a choice: An Arakoon node can be daemonised at startup. Lwt forces us to daemonise very early (basically before you do anything else) When you're a daemon you have no stdout or stderr. In order to have the same code flow (regardless of daemonisation) we take the following route: if there is a parsing error in the .ini file, arakoon stops and reports on stderr, but as soon as there is a log file, all error reporting goes there.
There is almost no error reporting (for example, failure following a mistake in the config file.)