Forum: Managing VoltDB

Post: "FATAL" license error

"FATAL" license error
henning
Apr 28, 2012
When the VoltDB server does not find a license at startup it prints the line

FATAL 20:22:44,542 [main] HOST: Unable to open license file: ../../voltdb/license.xml
As
it starts with "fatal", I believe that sent me on an hour long bug hunt that was caused by something else, the JSON port being occupied. But this error message was the last one coming from the server.
Does that path really exist?
scooper
Apr 28, 2012
Hi,

That error message specifically occurs when the file does not exist at the specified path, e.g. ../../voltdb/license.xml in your case. It is not complaining about the contents of the license file since it never was read. Would you mind double checking the path?

Sorry, I should have read the question more carefully. If you know the license file doesn't exist there perhaps I don't understand the question. What kind of help are you looking for?

Cheers,
Steve
Misleading
henning
Apr 28, 2012
Hi,

That error message specifically occurs when the file does not exist at the specified path, e.g. ../../voltdb/license.xml in your case. It is not complaining about the contents of the license file since it never was read. Would you mind double checking the path?



My point is that it is misleading that it is headed "FATAL".

In most environments I saw, a fatal error usually terminates
execution as opposed to non-fatal errors. In a situation where the
VoltDB server stops right after listing out this line (or very shortly
after), it can mislead as to what the actual problem was.

Because it is not rare that execution stops some lines after a fatal error was encountered, e.g. in a build process.

I had the situation that the actual problem was the JSON port, which
was duly reported in the output. But because the first error seemed to
be the "fatal" license error, I tried to fix that instead of fixing the
port problem which was the actual problem. And fixing the license
problem not only was not a quick thing, but of course did not help
anything. Because the server kept stopping at the same output lines
again, I first thought I fixed the license wrong.

In the end the license had never been the problem, it had just looked like it.
Thanks for clarifying. We're
scooper
Apr 29, 2012
My point is that it is misleading that it is headed "FATAL".

In most environments I saw, a fatal error usually terminates
execution as opposed to non-fatal errors. In a situation where the
VoltDB server stops right after listing out this line (or very shortly
after), it can mislead as to what the actual problem was.

Because it is not rare that execution stops some lines after a fatal error was encountered, e.g. in a build process.



Thanks for clarifying. We're putting a big emphasis on fixing
up our logging and error reporting. I'll file a ticket so that this
particular issue gets addressed.

Steve
Thought this was fixed..
rbetts
Apr 29, 2012
Henning,

This message was a regression in some logging caused by some WAN checks I added. I thought I fixed it though with the below commit. What version are you running / reporting this against?

commit 4a097228018c31a98414e02899a39246255e2deb
Author: Ryan Betts
Date: Wed Feb 22 17:22:02 2012 -0500
ENG-2391 Start removing master DR keyword

* Command line now only accepts 'replica'
* License enforcement prevents unlicensed replica from
starting.
* License enforcement prevents PartitionDRGateway from
instantiating real gateway.
* Fixes errant 'fatal' license log message when starting
community edition. (Incidentally changed this code.)
Sorry
henning
Apr 29, 2012
Henning,

This message was a regression in some logging caused by some WAN checks I added. I thought I fixed it though with the below commit. What version are you running / reporting this against?



Sorry for the false alarm then, this was fixed already.

I had run into it, and first complained about it, when doing the
first benchmark setups and what I know is, it was a pre-2.5 version. But
it's on the Amazon EC2 instances so I can't check it right now.

Before posting this, I used a 2.2 from Feb 16. So that matches very well with your fix.

I had wrongly thought that I was using an up to date version, which I should have checked of course.

My bad,

Henning