Problems Running Metabase v0.37.4 As Service On Ubuntu 20.04

Get Help
1

Hi everyone,

I am currently trying to get Metabase up and running as a service on a DigitalOcean droplet.
I based my configuration on this guide: https://www.metabase.com/docs/latest/operations-guide/running-metabase-on-debian.html

Metabase is starting and seems to be working as it should (generating log messages and creating db files in its working directory).
However, it is not binding to its port most of the time (yeah, heisenbugs and all).

From my analysis it seems to only be actually working on a full system reboot, not if I manually systemctl stop & start it again.

My current Metabase configuration:
MB_PASSWORD_COMPLEXITY=normal
MB_PASSWORD_LENGTH=10

However i have tried binding to a different port & host with this configuration and it did not change the described behaviour.
MB_PASSWORD_COMPLEXITY=normal
MB_PASSWORD_LENGTH=10
MB_JETTY_HOST=127.0.0.1
MB_JETTY_PORT=4000

Netstat directly after reboot, no commands issued by me besides netstat
# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 735/nginx: master p
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 514/systemd-resolve
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 690/sshd: /usr/sbin
tcp 0 0 127.0.0.1:45527 0.0.0.0:* LISTEN 656/containerd
tcp6 0 0 :::80 :::* LISTEN 735/nginx: master p
tcp6 0 0 :::22 :::* LISTEN 690/sshd: /usr/sbin
tcp6 0 0 :::3000 :::* LISTEN 635/java
udp 0 0 127.0.0.53:53 0.0.0.0:* 514/systemd-resolve

If i then systemctl stop & start the Metabase service it does not bind correctly:

Netstat output on running server, after i stopped and restarted the Metabase service:
# netstat -tulpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:39939 0.0.0.0:* LISTEN 663/containerd
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 731/nginx: master p
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 516/systemd-resolve
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 689/sshd: /usr/sbin
tcp6 0 0 :::80 :::* LISTEN 731/nginx: master p
tcp6 0 0 :::22 :::* LISTEN 689/sshd: /usr/sbin
udp 0 0 127.0.0.53:53 0.0.0.0:* 516/systemd-resolve

Maybe I am doing something wrong, maybe Metabase is malfunctioning? Any help would be appreciated as I have no idea on how to further analyze the issue.

Yes, I can reproduce this with a fresh droplet running Ubuntu 20.04 and am happy to share my script if this helps

2

Hi @ProfessorLogout

You should not be using H2 in production:
https://www.metabase.com/docs/latest/operations-guide/migrating-from-h2.html

Check the log of Metabase. That will tell you which port is being used. It’s likely something to do with how environment variables are not being loaded, which is why it shows as port 3000, which is the default.
Also see: Struggling to run Metabase as a service on Ubuntu

3

Hi @flamber

Yes, I’m aware I should not (and will not) use H2 in production, but that should not have anything todo with the actual issue I believe.

Metabase logs tell me basically nothing, this is everything getting logged on startup:

    Dec 29 12:59:22 666-v0 metabase[1988]: 2020-12-29 12:59:22,004 INFO metabase.util :: Maximum memory available to JVM: 237.8 MB
    Dec 29 12:59:36 666-v0 metabase[1988]: 2020-12-29 12:59:36,471 INFO util.encryption :: Saved credentials encryption is DISABLED for this Metabase instance.
    Dec 29 12:59:36 666-v0 metabase[1988]:  For more information, see https://metabase.com/docs/latest/operations-guide/encrypting-database-details-at-rest.html

Environment variables are loaded, tested by setting

MB_EMOJI_IN_LOGS=false

However, this is still not the real error, let me try to rephrase this:
When Metabase gets started it does not bind to any port (neither the default 3000 or something custom set through MB_JETTY_PORT.

4

@ProfessorLogout You are giving way too little RAM. I have a feeling that you are seeing this issue too:
https://github.com/metabase/metabase/issues/10175
There should be much more information in the logs.