<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 21, 2016 at 2:07 AM, John Dennis <span dir="ltr"><<a href="mailto:jdennis@redhat.com" target="_blank">jdennis@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="">On 06/20/2016 06:13 AM, Marko Strukelj wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
The first error means that there are existing tables in the local H2<br>
database (under standalone/data there are keycloak.* files).<br>
<br>
It looks like the logic determined that they are of some previous db<br>
schema version, and tried to upgrade the schema to latest version, but<br>
unexpectedly the schema in place already seems to contain the tables it<br>
wasn't supposed to contain.<br>
<br>
I suppose that could happen if upgrade process is interrupted by<br>
restarting the server?<br>
<br>
Since you are using the default H2 database I assume you don't care<br>
about any existing data. The solution for you then is to stop the<br>
server, delete the database (rm standalone/data/keycloak.*), and start<br>
the server again.<br>
</blockquote>
<br></span>
Thank you Marko, I've got a few more questions for you.<br>
<br>
These errors occur during automated installation and configuration via ansible.<br>
<br>
One of the operations performed is invoking bin/add-user-keycloak to add the admin user. I seem to recall add-user-keycloak operates on static files which are read during start up. Could the use of add-user-keycloak trigger the schema errors seen in the log?<br></blockquote><div><br></div><div>No.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
This is a brand new install so why would there be an upgrade process running?<br></blockquote><div><br></div><div>One possibility would be that the packaged installation already contains standalone/data/keycloak.* files, which it shouldn't - maybe it's a custom packaging you put together?</div><div>Another possibility is that the error does not happen on first start, but on subsequent start, after server is forcefully restarted.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
The ansible scripts do restart the server. Starting the server is done via bin/standalone.sh but stopping the server is performed by systemd sending a SIGTERM, waiting and then sending a SIGKILL (or so I believe). Does the upgrade process gracefully handle SIGTERM such that it continues to run until complete and then exit?</blockquote><div><br></div><div>This is the most likely culprit. I don't think upgrade procedure will properly complete when java process is set to shutdown no matter what signal is used.</div><div>The shutdown should only be performed after server has reached started state.</div><div><br></div><div>That's when you see an entry in the log similar to:</div><div>
<p class="">
</p><p class=""><span class="">11:26:41,410 INFO [<a href="http://org.jboss.as">org.jboss.as</a>] (Controller Boot Thread) WFLYSRV0025: Keycloak 1.9.7.Final (WildFly Core 2.0.10.Final) started in 10219ms - Started 416 of 782 services (526 services are lazy, passive or on-demand)</span></p><p class=""><span class=""><br></span></p></div></div></div></div>