Job exception: ERROR: invalid input syntax for type inet: "unix:" LINE 2: SET ip_address = 'unix:' ^
rack-mini-profiler-4.0.1/lib/patches/db/pg/alias_method.rb:109:in 'PG::Connection#exec'
rack-mini-profiler-4.0.1/lib/patches/db/pg/alias_method.rb:109:in 'PG::Connection#async_exec'
mini_sql-1.6.0/lib/mini_sql/postgres/connection.rb:217:in 'MiniSql::Postgres::Connection#run'
mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:38:in 'block in MiniSql::ActiveRecordPostgres::Connection#run'
mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:34:in 'block in MiniSql::ActiveRecordPostgres::Connection#with_lock'
activesupport-8.0.5.1/lib/active_support/concurrency/null_lock.rb:9:in 'ActiveSupport::Concurrency::NullLock#synchronize'
mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:34:in 'MiniSql::ActiveRecordPostgres::Connection#with_lock'
mini_sql-1.6.0/lib/mini_sql/active_record_postgres/connection.rb:38:in 'MiniSql::ActiveRecordPostgres::Connection#run'
/var/www/discourse/lib/mini_sql_multisite_connection.rb:109:in 'MiniSqlMultisiteConnection#run'
mini_sql-1.6.0/lib/mini_sql/postgres/connection.rb:196:in 'MiniSql::Postgres::Connection#exec'
/var/www/discourse/app/models/user.rb:1145:in 'User.update_ip_address!'
/var/www/discourse/lib/auth/default_current_user_provider.rb:235:in 'block in Auth::DefaultCurrentUserProvider#current_user'
/var/www/discourse/lib/scheduler/defer.rb:135:in 'block in Scheduler::Deferrable#do_work'
rails_multisite-7.0.0/lib/rails_multisite/connection_management/null_instance.rb:49:in 'RailsMultisite::ConnectionManagement::NullInstance#with_connection'
rails_multisite-7.0.0/lib/rails_multisite/connection_management.rb:17:in 'RailsMultisite::ConnectionManagement.with_connection'
/var/www/discourse/lib/scheduler/defer.rb:130:in 'Scheduler::Deferrable#do_work'
/var/www/discourse/lib/scheduler/defer.rb:116:in 'block (2 levels) in Scheduler::Deferrable#start_thread'
When it happens, an “Oops - Error 500” page is displayed. At first, I thought Caddy was the culprit because it wasn’t forwarding the client’s IP address to Discourse, so I tried several different configurations, but none of them solved the issue.
It’s worth mentioning that this doesn’t happen very often. It occurs only occasionally, and when it does, simply refreshing the page immediately recovers the site. It then works normally for quite some time before the error randomly occurs again.
I’m not an expert and I did not use Caddy but Nginx on my self-hosted instance, but can I ask for your actual Caddy and Discourse templates configuration in ./app/containers.yml?
Can you remember what you usually did before the error happens? I mean, changing admin settings, posting, using some plugin?
I’m sorry not to give specific help to your issue, but I think your replies can add value to your question for getting a clear and fast response from the community.
templates:
- "templates/postgres.18.template.yml"
- "templates/redis.template.yml"
- "templates/web.template.yml"
- "templates/web.socketed.template.yml"
- "templates/enable-ruby-yjit.yml"
## which TCP/IP ports should this container expose?
## If you want Discourse to share a port with another webserver like Apache or nginx,
## see https://meta.discourse.org/t/17247 for details
expose:
# - "66:80" # http
# - "66:443" # https
params:
## Which Git revision should this container use? (default: latest)
version: latest
## Maximum upload size (default: 10m)
upload_size: 150m
db_default_text_search_config: "pg_catalog.english"
## Set db_shared_buffers to a max of 25% of the total memory.
## will be set automatically by bootstrap based on detected RAM, or you can override
db_shared_buffers: "2048MB"
## can improve sorting performance, but adds memory usage per-connection
#db_work_mem: "40MB"
## Which Git revision should this container use? (default: tests-passed)
#version: tests-passed
env:
LC_ALL: en_US.UTF-8
LANG: en_US.UTF-8
LANGUAGE: en_US.UTF-8
# DISCOURSE_DEFAULT_LOCALE: en
## https://meta.discourse.org/t/rescaling-the-server-which-configs-need-to-be-changed-unicorn-workers-memory-etc/252788
## How many concurrent web requests are supported? Depends on memory and CPU cores.
## will be set automatically by bootstrap based on detected CPUs, or you can override
UNICORN_WORKERS: 8
## TODO: The domain name this Discourse instance will respond to
## Required. Discourse will not work with a bare IP number.
DISCOURSE_HOSTNAME: example.com
## Uncomment if you want the container to be started with the same
## hostname (-h option) as specified above (default "$hostname-$config")
#DOCKER_USE_HOSTNAME: true
## TODO: List of comma delimited emails that will be made admin and developer
## on initial signup example 'user1@example.com,user2@example.com'
DISCOURSE_DEVELOPER_EMAILS: 'admin+discourse@example.com'
## TODO: The SMTP mail server used to validate new accounts and send notifications
# SMTP ADDRESS is required
# WARNING: SMTP password should be wrapped in quotes to avoid problems
DISCOURSE_SMTP_ADDRESS: smtp.provider.com
DISCOURSE_SMTP_PORT: 587
DISCOURSE_SMTP_USER_NAME: noreply@example.com
DISCOURSE_SMTP_PASSWORD: "***"
#DISCOURSE_SMTP_ENABLE_START_TLS: true # (optional, default: true)
DISCOURSE_SMTP_DOMAIN: example.com # (required by some providers)
DISCOURSE_NOTIFICATION_EMAIL: noreply@example.com
#DISCOURSE_SMTP_OPENSSL_VERIFY_MODE: peer # (optional, default: peer, valid values: none, peer, client_once, fail_if_no_peer_cert)
#DISCOURSE_SMTP_AUTHENTICATION: plain # (default: plain, valid values: plain, login, cram_md5)
## If you added the Lets Encrypt template, uncomment below to get a free SSL certificate
# LETSENCRYPT_ACCOUNT_EMAIL: admin+letsencrypt@example.com
## The http or https CDN address for this Discourse instance (configured to pull)
## see https://meta.discourse.org/t/14857 for details
#DISCOURSE_CDN_URL: https://discourse-cdn.example.com
## The maxmind geolocation IP account ID and license key for IP address lookups
## see https://meta.discourse.org/t/-/173941 for details
#DISCOURSE_MAXMIND_ACCOUNT_ID: 123456
#DISCOURSE_MAXMIND_LICENSE_KEY: 1234567890123456
# Force HTTPS
DISCOURSE_FORCE_HTTPS: true
# Request Limits
DISCOURSE_MAX_REQS_PER_IP_MODE: none
DISCOURSE_MAX_ADMIN_API_REQS_PER_MINUTE: 12000
DISCOURSE_MAX_DATA_EXPLORER_API_REQ_MODE: none
DISCOURSE_MAX_DATA_EXPLORER_API_REQS_PER_10_SECONDS: 1000
DISCOURSE_YJIT_ENABLED: true
## The Docker container is stateless; all data is stored in /shared
volumes:
- volume:
host: /var/discourse/shared/standalone
guest: /shared
- volume:
host: /var/discourse/shared/standalone/log/var-log
guest: /var/log
- volume:
host: /var/discourse/plugins
guest: /var/plugins
## Plugins go here
## see https://meta.discourse.org/t/19157 for details
hooks:
after_code:
- exec:
cd: $home/plugins
cmd:
- git clone https://github.com/discourse/docker_manager.git
- cp -a /var/plugins/. $home/plugins/
## Any custom commands to run after building
run:
- exec: echo "Beginning of custom commands"
## If you want to set the 'From' email address for your first registration, uncomment and change:
## After getting the first signup email, re-comment the line. It only needs to run once.
#- exec: rails r "SiteSetting.notification_email='info@unconfigured.discourse.org'"
- exec: echo "End of custom commands"
To be more specific, this error occurs several hours after the previous one, it doesn’t happen very often. I don’t see anything unusual in app.yml or the Caddyfile.
I’ve been working on this for days. I’ve verified that Caddy sends the header, that nginx receives and applies it, that there’s no CDN, no other process touching the socket, and no webhooks. Every single test passes. And the Unix error keeps appearing. I thought it was because of the rebuild, but it’s not. All of this happens randomly over very long periods of time.