And then my Bitbucket server died

One day I moved all my LXC containers to one host. This was done to use one of my NUCs as a Roon ROCK server. Moving the containers was easy with LXC. Just take a snapshot of the container and copy it to another server. Start it there and well, that was that.

In the back of my head a voice was telling me that all my LXC containers have boot.autostart set to true. The voice was telling also telling me this might become an issue. What if the Bitbucket server starts before the PostgreSQL server running on the same host?

Anyway, quite soon, after a few reboots, I got into trouble. Bitbucket was stuck at “Migrating home directory”.

I’m not saying booting all containers at the same time is the problem. It might be. It might also be that I shutdown down the SQL server before Bitbucket.

Looking for a solution wasn’t easy as I couldn’t find anything in the Bitbucket logs:

******@bitbucket ERROR: function aurora_version() does not exist at character 8

Apparently there is some sort of PostgreSQL implementation you can run on the Amazon cloud that is called Aurora. You learn something new every day…

I thought I had found the root cause, but also realised that all the people mentioning these log messages weren’t saying their server didn’t boot.

Then I started googling the message “Migrating home directory” and quickly had a solution. It seems my database was locked. This statement allowed my server to boot Bitbucket successfully again:

UPDATE DATABASECHANGELOGLOCK SET LOCKED=false, LOCKGRANTED=null, LOCKEDBY=null where ID=1;

The dreadful missing JDK dialog on macOS

I’m not a fan of Eclipse or products derived from Eclipse. I think they’re slow, not very intuitive and the program state never seems to be up to date, but sometimes unfortunately there’s no alternative.

Sometimes I use Apache Directory Studio to edit my LDAP data. Today I installed Directory studio, but it wouldn’t start because it couldn’t find the JDK. I have unwrapped several JDK tar balls in my /opt directory, but Directory Studio doesn’t know that.

Of course I immediately started googling and a lot of people mentioned to put -vm <path to java> in the Contents/Eclipse/ApacheDirectoryStudio.ini inside the application’s folder in /Applications. This unfortunately didn’t work for me.

I started checking other files in the application folder and found Contents/Info.plist. Inside the array tag in that file at the bottom there’s a comment about using a particular Java version. Adding this to that array tag did the trick: <string>-vm</string><string>/somepath/java</string>

Just now I have installed Eclipse to see if it suffers from the same problem out of the box and it does. The solution is the same for Eclipse. Just add the vm information in the Info.plist in the Contents folder in the Eclipse application folder.