mirror of
https://github.com/koel/koel.git
synced 2026-04-26 09:15:59 +03:00
[GH-ISSUE #1304] koel:init exits after two successful setup steps #753
Labels
No labels
Authentication
Dependencies
Documentation
Feature Request
Flac
Help Wanted
Installation/Setup
Integration
Mobile
PR Welcome
Pending Release
Performance
Playlist
S3
Search
Sync
[Pri] Low
[Pri] Normal
[Status] Keep Open
[Status] Needs Author Reply
[Status] Needs Review
[Status] Stale
[Status] Will Implement
[Type] Blessed
[Type] Bug
[Type] Duplicate
[Type] Enhancement
[Type] Help Request
[Type] Question
[Type] Task
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/koel-koel#753
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @MichaIng on GitHub (Apr 11, 2021).
Original GitHub issue: https://github.com/koel/koel/issues/1304
Describe the bug
When running
koel:init, after the two setup steps "Migrating database" and "Seeding initial data", it exits with the following error message:Repeating
koel:initor checking the database shows that the previous step has actually succeeded, so that the setup goes one step further, before exiting with the same error. Repeatingkoel:initall together three times, allows it to succeed. A minor additional issue is that PHP does not return an error code when exiting that way.To reproduce
Steps to reproduce the behavior:
cd koel && composer install.envwith database info + credentialsMEDIA_PATHand add-nbelow.php artisan koel:init --no-assetsExpected behavior
The setup should succeed, either with interactive media directory input or unattended when
MEDIA_PATHwas set.Screenshots
Environment
Additional context
The used UNIX user doesn't play a rule. While above was done as
root, the issue was recognised first when running it as an unprivileged service user, while R/W permissions were of course assured. Also it has been tested with MariaDB UNIX socket and TCP-based connection, which doesn't make a difference.@Christoffaer commented on GitHub (Apr 11, 2021):
I want to live
Den sön 11 apr. 2021 21:36MichaIng @.***> skrev:
@MichaIng commented on GitHub (Apr 12, 2021):
Obviously
migrateDatabaseandmaybeSeedDatabaseare throwing errors, even when they succeed. So running the included commands manually with additional verbosity could help to debug the issue:php artisan migrate --force -vvvmanuallyphp artisan db:seed --force -vvvmanuallyAnother minor issue is that even when the init command exits with that error message, it does not return an error code to artisan => the console.
artisancatches a status code to exist with:github.com/koel/koel@c9446c4adb/artisan (L33)I'm no experienced PHP coder, but would
return 1orreturn (bool) falsework here:github.com/koel/koel@c9446c4adb/app/Console/Commands/InitCommand.php (L77)🈯
php artisan key:generate🈯
php artisan config:clear🈴
php artisan migrate --force -vvv.env. Then it tries to connect to an SQLite database, which of course fails as MySQL is configured?koel:initcatches this correctly, but obviously the error messages override the error code so that it is not returned to the parent artisan instance.sqlite3does not change something, resetting the MySQL database and redoing the above fails the same way.php artisan migrate --force -vvvcall (without resetting the MySQL database) succeeds without showing any attempt to use SQLite at all.🈴
php artisan db:seed --force -vvvArtistTableSeederfails as it tries to access via SQLite.ArtistTableSeedersucceeds butAlbumTableSeederfails.So it seems like for unknown reasons, it is tried to access the database via SQLite while it has been configured to use MySQL. And this seems to be the case only when the affected database tables or entries do not exist yet. It's a bit above my insights to understand where the database driver selection is done and why the
.enventries (even that MySQL is the default already) are not respected in every case. At least it's not a bug in a specific PHP version, as two versions and three builds have been tested with the same behaviour. Probably an issue with Laravel. I'd be happy to do further debug steps or provide additional information/outputs/logs, but I'm not sure at this point how to go on best.@phanan commented on GitHub (Apr 16, 2021):
That's because TNTSearch (the full-text search engine that Koel uses) uses SQLite. Make sure
/storage/search-indexesexists (which it should).Edit: I've just checked the installation archives, indeed the directory isn't there, which is a bug.
@phanan commented on GitHub (Apr 16, 2021):
Released v5.1.1 which fixes the TNTSearch/SQLite issue.
@MichaIng commented on GitHub (Apr 16, 2021):
Ah I see:
github.com/koel/koel@0e0e6f436bMany thanks for the quick fix. Just tested it and it works all as expected now 👍. I'm marking this issue as closed.