-
I started experimenting with Koel recently, just to take a look at it. I don't know exactly what I've done in the web UI, but when restarting Koel, it was broken, and stuck in an endless loop with this in the logs:
Koel cannot connect to the database. Let's set it up. Database hosts array is empty. Koel cannot connect to the database. Let's set it up. Database hosts array is empty. Koel cannot connect to the database. Let's set it up. Database hosts array is empty.Also may be worth noting that the logging was happening so fast, it was impossible to view it in Cloudron's viewer (kept killing my browser).
Checking around, I noticed that /app/pkg/env.template and /app/data/env had some suspicious changes (note, I removed the APP_KEY entry just in case that's sensitive):
--- env.template 2020-10-31 05:21:45.000000000 +0000 +++ /app/data/env 2021-04-10 07:14:34.260807115 +0000 @@ -8,14 +8,14 @@ # sqlite-persistent (Local sqlite file) # IMPORTANT: This value must present for artisan koel:init command to work. DB_CONNECTION=mysql -DB_HOST=${CLOUDRON_MYSQL_HOST} -DB_PORT=${CLOUDRON_MYSQL_PORT} -DB_DATABASE=${CLOUDRON_MYSQL_DATABASE} -DB_USERNAME=${CLOUDRON_MYSQL_USERNAME} -DB_PASSWORD=${CLOUDRON_MYSQL_PASSWORD} +DB_HOST= +DB_PORT= +DB_DATABASE= +DB_USERNAME= +DB_PASSWORD= # A random 32-char string. You can leave this empty if use php artisan koel:init. -APP_KEY= +APP_KEY=base64:xxxxxxx # Another random 32-char string. You can leave this empty if use php artisan koel:init. JWT_SECRET= @@ -139,4 +139,3 @@ MAIL_ENCRYPTION= MAIL_FROM_ADDRESS=${CLOUDRON_MAIL_FROM} MAIL_FROM_NAME=Koel -Sure enough, when I added the database environment entries back, start.sh successfully worked. My guess is that something (Koel itself?) rewrites /app/data/env on some condition in the UI, and it doesn't manage to keep the environment variables there when it does that.
-
Another finding, from reading Koel's documentation:
https://docs.koel.dev/#streaming-music
Use native PHP readfile(). This is the default method, and the slowest and most unstable one. Only use this method if you can't others.
Might be nice to look into changing STREAMING_METHOD, assuming that it's easy to enable?
-
I tried to reproduce this but the config (env) seems to survive restarts
Strange, let me know if you hit this again or can help me reproduce this. -
@girish Theory: setUpDatabase in app/Console/Commands/InitCommand.php calls setKey() to alter the env file.
setUpDatabase is called from maybeSetUpDatabase, if the PDO connection throws an exception. My guess is that the database connection dropped right when Koel was starting up, and it responded by setting the environment variables to empty (since it's run in non-interactive mode), and wrote those to the env file?
-
Yep, steps to reproduce:
- Set up a koel instance
- Open a terminal, edit /app/data/env
- Break one of the database variables (I added an 'x' at the end of DB_DATABASE I think)
- Restart Koel, and watch as your logs explode your browser, and Koel doesn't recover
I guess this MIGHT conceivably be a Koel bug: I think that it should not endlessly try to connect to the database when not run in interactive mode. And it should also probably not write the database environment variables in such a mode...?
-
Potential patch here: https://github.com/rburchell/koel/commit/21dadd1363e1534e81a8e6b125a22a7aeb27508a, I'll try find the time to shepherd this upstream in some form.
Not sure if it makes sense to also consider some actions on the Cloudron side. It strikes me that it is a bit fragile to have an 'env' file that is modified by the application, but with this particular bug fixed in Koel, I guess it wouldn't be a problem anymore...
-
@robin said in Koel breaks (manages to end up with a corrupt environment file):
It strikes me that it is a bit fragile to have an 'env' file that is modified by the application
Yeah, that seems wrong to have the app modify the env file. The env file is usually a config file that is meant for users and packagers and not for the app to store it's settings (my understanding anyway).
-
