Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Getting Fatal Error: Cannot connect to database #35

Closed
noelforte opened this issue May 19, 2020 · 2 comments
Closed

Getting Fatal Error: Cannot connect to database #35

noelforte opened this issue May 19, 2020 · 2 comments
Labels
question Further information is requested

Comments

@noelforte
Copy link

Been trying for hours to get docker to start but at this point I'm going to start looking into running shynet directly instead of with docker since I can't seem to get the container to initialize properly and nothing's better than a good ol' sudo service shynet start. To be clear, I am using the latest docker image and can't get past a first run.

First I was getting a lot of:

django.db.utils.OperationalError: could not connect to server: Connection refused
	Is the server running on host "localhost" (127.0.0.1) and accepting
	TCP/IP connections on port 5432?
could not connect to server: Address not available
	Is the server running on host "localhost" (::1) and accepting
	TCP/IP connections on port 5432?

Migrations failed, exiting
Launching Shynet web server...
[2020-05-19 05:29:42 +0000] [11] [INFO] Starting gunicorn 20.0.4
[2020-05-19 05:29:42 +0000] [11] [INFO] Listening at: http://0.0.0.0:8080 (11)
[2020-05-19 05:29:42 +0000] [11] [INFO] Using worker: sync
[2020-05-19 05:29:42 +0000] [13] [INFO] Booting worker with pid: 13

...which would throw my terminal into a frozen state, forcing me to have to open a new session on my VPS just to get my prompt back by shutting down the docker container and then try again. After a bit, this comment gave me the idea that the container couldn't see my database at all since 'localhost' to it was itself and not the server it was on. I then tried using my VPS's public IP which didn't work:

File "/usr/local/lib/python3.8/site-packages/psycopg2/__init__.py", line 127, in connect
    conn = _connect(dsn, connection_factory=connection_factory, **kwasync)
django.db.utils.OperationalError: could not connect to server: Connection refused
	Is the server running on host "<my_ip_address>" and accepting
	TCP/IP connections on port 5432?

Tried adjusting postgresql settings to watch that IP instead of localhost, even thought that dashes in my db name were throwing it off, or that postgres might be looking for a socket connection instead— nothing.

Unless I can get help diagnosing the problem, I'm going to start looking into running shynet as a linux service since I think that will probably help uncomplicate a lot of the connection issues I'm having. Tool looks promising though!

@milesmcc
Copy link
Owner

This is an odd issue. Could you post a redacted version of your environment file?

Shynet leans on Django for essentially all of its database work, so it’s unlikely that this is an issue with Shynet itself. Still, I’m curious about the root cause here—it’ll probably be helpful to add an NB to the usage guide for others once we figure out what it is.

@milesmcc milesmcc added the question Further information is requested label May 19, 2020
@noelforte
Copy link
Author

I was able to get the container started but it required trusting my private IP in pg_hba.conf as well as ensuring that postgresql was listening on the same address. Then had issues getting the container to set a whitelabel correctly as it was having issues parsing the spaces.

Finally got it up, but as some feedback I'd say there are way too many variables that need to fall into alignment and be documented to those that aren't well-initiated with docker which is already an opinionated way of managing software. Definitely going to keep an eye on this project but I'm probably better off looking elsewhere for a solution for now. Thanks for your help!

My .env file if it helps but I left a lot of the settings at their defaults.

# This file shows all of the environment variables you can
# set to configure Shynet, as well as information about their
# effects. Make a copy of this file to configure your deployment.

# Database settings (PostgreSQL)
DB_NAME=<my_db_name>
DB_USER=<my_db_user>
DB_PASSWORD=<my_db_password>
DB_HOST=<my_db_host ('localhost' does not work, must be a real, reachable IP)
DB_PORT=5432

# Email settings (optional)
EMAIL_HOST_USER=example
EMAIL_HOST_PASSWORD=example_password
EMAIL_HOST=smtp.example.com
SERVER_EMAIL=<Shynet> noreply@shynet.example.com

# General Django settings
DJANGO_SECRET_KEY=<random_hash>

# For better security, set this to your deployment's domain. Comma separated.
ALLOWED_HOSTS=*

# Set to True (capitalized) if you want people to be able to sign up for your Shynet instance (not recommended)
SIGNUPS_ENABLED=False

# The timezone of the admin panel. Affects how dates are displayed.
TIME_ZONE=America/New_York

# Set to "False" if you will not be serving content over HTTPS
SCRIPT_USE_HTTPS=True

# How frequently should the monitoring script "phone home" (in ms)?
SCRIPT_HEARTBEAT_FREQUENCY=5000

# How much time can elapse between requests from the same user before a new
# session is created, in seconds?
SESSION_MEMORY_TIMEOUT=1800

# Should only superusers (admins) be able to create services? This is helpful
# when you'd like to invite others to your Shynet instance but don't want
# them to be able to create services of their own.
ONLY_SUPERUSERS_CREATE=True

# Whether to perform checks and setup at startup, including applying unapplied
# migrations. For most setups, the recommended value is True. Defaults to True.
# Will skip only if value is False.
PERFORM_CHECKS_AND_SETUP=True

# Your admin user's email. A temporary password will be printed
# to the console on first run.
SHYNET_ADMIN_EMAIL=you@example.com

# The domain on which you'll be hosting Shynet. 
SHYNET_HOST=shynet.example.com

# What you'd like to call your Shynet instance.
SHYNET_WHITELABEL=My Shynet Instance

# Redis, queue, and parellization settings; not necessary for single-instance deployments.
# Don't uncomment these unless you know what you are doing!
# NUM_WORKERS=1
# Make sure you set a REDIS_CACHE_LOCATION if you have more than one frontend worker/instance.
# REDIS_CACHE_LOCATION=redis://redis.default.svc.cluster.local/0 
# If CELERY_BROKER_URL is set, make sure CELERY_TASK_ALWAYS_EAGER is False and
# that you have a separate queue consumer running somewhere via `celeryworker.sh`.
# CELERY_TASK_ALWAYS_EAGER=False
# CELERY_BROKER_URL=redis://redis.default.svc.cluster.local/1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants