Windows 10 WSL2 Ubuntu 20.04 LTS $ docker-compose-non-dev.yml up (failed)
See original GitHub issueWindows 10 WSL2 Ubuntu 20.04 LTS $ docker-compose-non-dev.yml up (failed)
How to reproduce the bug
Followed instructions in “Installing Superset Locally Using Docker Compose” “Docker Desktop recently added support for Windows Subsystem for Linux (WSL) 2, which may be another option.” https://superset.apache.org/docs/installation/installing-superset-using-docker-compose
- Windows 10 / wsl2 / Ubuntu 20.04 LTS
- From Windows Terminal
- Ubuntu 20.04 tab bash shell
- git clone http:s://github.com/apache/superset.git
- cd superset
- docker-compose -f docker-compose-non-dev.yml up
Expected results
“You should see a wall of logging output from the containers being launched on your machine. Once this output slows, you should have a running instance of Superset on your local machine!”
Actual results
Continious running error loop in Windows Terminal Ubuntu 20.04 tab. From Second Ubuntu 20.04 tab captured “docker ps” container list and environment (edited from neofetch).
Screenshots
File “/usr/local/lib/python3.7/site-packages/sqlalchemy/engine/default.py”, line 608, in do_execute superset_worker | cursor.execute(statement, parameters) superset_worker | sqlalchemy.exc.ProgrammingError: (psycopg2.errors.UndefinedTable) relation “report_schedule” does not exist superset_worker | LINE 2: FROM report_schedule superset_worker | ^ superset_worker | superset_worker | [SQL: SELECT report_schedule.created_on AS report_schedule_created_on, report_schedule.changed_on AS report_schedule_changed_on, report_schedule.id AS report_schedule_id, report_schedule.type AS report_schedule_type, report_schedule.name AS report_schedule_name, report_schedule.description AS report_schedule_description, report_schedule.context_markdown AS report_schedule_context_markdown, report_schedule.active AS report_schedule_active, report_schedule.crontab AS report_schedule_crontab, report_schedule.creation_method AS report_schedule_creation_method, report_schedule.timezone AS report_schedule_timezone, report_schedule.report_format AS report_schedule_report_format, report_schedule.sql AS report_schedule_sql, report_schedule.chart_id AS report_schedule_chart_id, report_schedule.dashboard_id AS report_schedule_dashboard_id, report_schedule.database_id AS report_schedule_database_id, report_schedule.last_eval_dttm AS report_schedule_last_eval_dttm, report_schedule.last_state AS report_schedule_last_state, report_schedule.last_value AS report_schedule_last_value, report_schedule.last_value_row_json AS report_schedule_last_value_row_json, report_schedule.validator_type AS report_schedule_validator_type, report_schedule.validator_config_json AS report_schedule_validator_config_json, report_schedule.log_retention AS report_schedule_log_retention, report_schedule.grace_period AS report_schedule_grace_period, report_schedule.working_timeout AS report_schedule_working_timeout, report_schedule.created_by_fk AS report_schedule_created_by_fk, report_schedule.changed_by_fk AS report_schedule_changed_by_fk superset_worker | FROM report_schedule superset_worker | WHERE report_schedule.active IS true] superset_worker | (Background on this error at: http://sqlalche.me/e/13/f405) superset_app | 127.0.0.1 - - [30/Sep/2021:14:07:05 +0000] “GET /health HTTP/1.1” 200 2 “-” “curl/7.64.0”
Environment
(please complete the following information):
- browser type and version: Chrome is up to date Version 94.0.4606.61 (Official Build) (64-bit)
Run from wsl2 Ubuntu bash command line without entering specific container
(which container would you want it run from?).
-
superset version:
superset version
$ superset version superset: command not found -
python version:
python --version
$ python --version
Command ‘python’ not found, did you mean:
command ‘python3’ from deb python3 command ‘python’ from deb python-is-python3
- node.js version:
node -v
$ node -v
Command ‘node’ not found, but can be installed with: sudo apt install nodejs
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 17e3a42c3496 apache/superset:latest-dev “/usr/bin/docker-ent…” 16 hours ago Up 16 hours (healthy) 0.0.0.0:8088->8088/tcp, :::8088->8088/tcp superset_app 53a11da454e0 apache/superset:latest-dev “/usr/bin/docker-ent…” 16 hours ago Up 16 hours (unhealthy) 8088/tcp superset_worker e208351c7e4b apache/superset:latest-dev “/usr/bin/docker-ent…” 16 hours ago Up 16 hours (unhealthy) 8088/tcp superset_worker_beat bc84f45637be redis:latest “docker-entrypoint.s…” 16 hours ago Up 16 hours 6379/tcp superset_cache fbc72e5f019f postgres:10 “docker-entrypoint.s…” 16 hours ago Up 16 hours 5432/tcp superset_db
$ docker -v Docker version 20.10.8, build 3967b7d
OS: Ubuntu 20.04.3 LTS on Windows 10 x86_64 Kernel: 5.10.16.3-microsoft-standard-WSL2 Uptime: 8 days, 17 hours, 26 mins Packages: 719 (dpkg) Shell: bash 5.0.17 Terminal: /dev/pts/4 CPU: Intel i7-8550U (8) @ 1.991GHz Memory: 2584MiB / 12692MiB
- any feature flags active:
Checklist
Make sure to follow these steps before submitting your issue - thank you!
- I have checked the superset logs for python stacktraces and included it here as text if there are any.
WSL2_attempt_to_run_docker-compose_superset_from_cloned_git
File “/usr/local/lib/python3.7/site-packages/sqlalchemy/engine/default.py”, line 608, in do_execute superset_worker | cursor.execute(statement, parameters) superset_worker | sqlalchemy.exc.ProgrammingError: (psycopg2.errors.UndefinedTable) relation “report_schedule” does not exist superset_worker | LINE 2: FROM report_schedule superset_worker | ^ superset_worker | superset_worker | [SQL: SELECT report_schedule.created_on AS report_schedule_created_on, report_schedule.changed_on AS report_schedule_changed_on, report_schedule.id AS report_schedule_id, report_schedule.type AS report_schedule_type, report_schedule.name AS report_schedule_name, report_schedule.description AS report_schedule_description, report_schedule.context_markdown AS report_schedule_context_markdown, report_schedule.active AS report_schedule_active, report_schedule.crontab AS report_schedule_crontab, report_schedule.creation_method AS report_schedule_creation_method, report_schedule.timezone AS report_schedule_timezone, report_schedule.report_format AS report_schedule_report_format, report_schedule.sql AS report_schedule_sql, report_schedule.chart_id AS report_schedule_chart_id, report_schedule.dashboard_id AS report_schedule_dashboard_id, report_schedule.database_id AS report_schedule_database_id, report_schedule.last_eval_dttm AS report_schedule_last_eval_dttm, report_schedule.last_state AS report_schedule_last_state, report_schedule.last_value AS report_schedule_last_value, report_schedule.last_value_row_json AS report_schedule_last_value_row_json, report_schedule.validator_type AS report_schedule_validator_type, report_schedule.validator_config_json AS report_schedule_validator_config_json, report_schedule.log_retention AS report_schedule_log_retention, report_schedule.grace_period AS report_schedule_grace_period, report_schedule.working_timeout AS report_schedule_working_timeout, report_schedule.created_by_fk AS report_schedule_created_by_fk, report_schedule.changed_by_fk AS report_schedule_changed_by_fk superset_worker | FROM report_schedule superset_worker | WHERE report_schedule.active IS true] superset_worker | (Background on this error at: http://sqlalche.me/e/13/f405) superset_app | 127.0.0.1 - - [30/Sep/2021:14:07:05 +0000] “GET /health HTTP/1.1” 200 2 “-” “curl/7.64.0”
- [x ] I have reproduced the issue with at least the latest released version of superset. (cloned git)
- [ x] I have checked the issue tracker for the same issue and I haven’t found one similar.
Additional context
Add any other context about the problem here.
Issue Analytics
- State:
- Created 2 years ago
- Comments:11 (3 by maintainers)
Top GitHub Comments
In case anyone else comes across this, looks like this issue falls square on me. I did not double check my docker memory setting as advised by the docs. I was allocating 4GB vs 6GB. It appears the db init crapped out and did not finish creating the schema, which is now 57 tables vs 6.
I changed the setting, nuked the db volume and restarted the stack successfully.
@esko22 AHH yeah hmm we added this to the documentation a while back to help avoid folks getting tripped up here! Glad this worked for you