View the original community article here
Last tested: Jun 17, 2020
When jumping versions, Looker needs to update the internal db. Generally this takes less than 5 minutes, but sometimes this can take longer than starting the Looker process. If you try to start Looker while the internal db update is happening, the daemonizing process will time out in 6 minutes with the message Timed out waiting for Looker to start.
This can be a legitimate message, but if you’re skipping several releases, it’s likely that the migrations are actually still running and you just need to give it some more time. If you see this message, sit tight and see if the update finishes and Looker starts up in the next ~15-20 minutes. We can confirm if the process is still running, even after the Time out message, with ps -f $(pgrep -f -- '-jar looker.jar')
If you saw the time out message and stopped the Looker process to restart, you may have issues with failed internal db updates (including but not limited to missing columns, duplicate columns, missing tables...) We will see these errors if we tail the logs. If you stopped and tried to restart and is seeing errors like this in logs, you will need to restore from backup and try the update again, waiting until the migration is complete regardless of Time out errors.
The case when looker stops running
There is a case when the Looker process is actually killed when you see this message: when you're using systemd to start up Looker automatically, but you've forgotten the --no-daemonize flag. --no-daemonize will make the Looker process run as a non-child process of the parent daemonizer (i.e. in the foreground rather than the background), so when the daemonizer is killed Looker will still keep chugging along.
For safety's sake, it might also be worth raising the TimeoutStartSec value in the looker.service file as well.
This content is subject to limited support.