Connection closed every couple of minutes

Support User
1

I’ve just finished installing Tryton with the web interface. But, does anyone know why I keep getting this error every couple of minutes?

Traceback (most recent call last):
  File "/trytond/transactionpy", line 207, in commit
    self.connection.commit()
psycopg2InterfaceError: connection already closed

I’m running it under uWSGI via Nginx, if that’s relevant.

2

Is the DB server closing the connection every couple of minutes?

3

I’m not familiar with postgres configuration, what should I be looking for? It’s a default install in Debian buster, installed through the apt archives.

4

I would suspect a firewall between that cut stalling connection.

5

Tryton and postgres are running on the same machine, the only firewall rules I’m using block most of the external ports, there’s nothing time based.

6

And, the database connection is through a Unix socket:

uri = postgresql://tryton:<PW>@/

7

Well it may be the OS who close stalling TCP connection.

8

I also don’t seem to have any issues with other applications which are connecting to MariaDB and Redis servers over a Unix socket, so really not sure what’s going on here.

9

Same thing sometimes happens to me. But only when we (re)started Tryton-server and Nginx-server. I think it’s a configuration problem in Nginx, because at one client it is running fine, as at another client this happens. What I see on the client side is something about the bus. After login and logout about 2 - 3 times everything is back to normal and the message does not appear anymore.
Because it appeared after restarting Tryton, it isn’t a issue at the moment so I didn’t dig deeper. But I think in my case it has something to do with the location definition in Nginx configuration.

10

Hmm, interesting. My server config is pretty basic, essentially if the file doesn’t exist, proxy to Tryton:

server {
	listen 443 ssl http2;
	listen [::]:443 ssl http2;

	server_name <domain>;
	root /var/www/tryton-sao/;

	<ssl_certs>

	more_set_headers "Content-Security-Policy: default-src 'none'; script-src 'self' 'unsafe-inline'; object-src 'none'; style-src 'self' 'unsafe-inline'; img-src 'self' blob:; media-src 'self'; frame-src 'none'; font-src 'self'; connect-src 'self'; frame-ancestors 'none'; base-uri 'none'; form-action 'self'; manifest-src 'none'; worker-src 'none'; upgrade-insecure-requests" always;

	location / {
		try_files $uri @tryton;
	}

	location @tryton {
		uwsgi_pass tryton;
		include uwsgi_params;
		uwsgi_request_buffering off;
	}

	location = /favicon.ico {
		alias /var/www/tryton-sao/images/tryton-icon.png;
	}

	location = /robots.txt {
		return 200 "User-agent: *\nDisallow: /\n";
	}
}
11

I tried logging in and out 3 times, but it also doesn’t seem to make a difference to me. If I open and close a few different tabs in the admin, I will encounter that error within a minute or 2.

It also sounds a bit weird that Nginx could be responsible for causing a connection between Tryton and the DB to get closed. Surely, that would be outside the control of Nginx.

12

Just to mention I’ve tried switching the DB connection to a localhost TCP connection, but get the same results either way.

13

Are you using the webclient? We are using the GTK desktop client. I’ve asked my client to pull the nginx.conf from the server. That one works for them.
And from my memory there was a specific location with the databasename.

location /production_database/ {
    uwsgi stuff
}

Can you can try something like that?

14

Another possibility is that the connection pool is started before the fork of µwsgi. In this case the connections could be shared between multiple process and closed by one while the other still use it.
You could try to µwsgi option lazy-apps=true which prevent µwsgi to load the application before forking.

1 Like
15

lazy-apps seems to have solved the issue, and I can even activate new modules in the admin now. Thanks.

16

How do you launch the µwsgi process? It will be good to understand why the connection pool is created before the fork (and see if we can fix that).

17

I run service tryton-wsgi start. Obviously, I had to configure all that myself as this is not something provided by the Debian package.

/etc/systemd/system/tryton-wsgi.service:

[Unit]
Description=Start uwsgi for Tryton ERP
After=network.target

[Service]
Type=simple
User=tryton
Group=www-data
PermissionsStartOnly=true
ExecStart=/usr/bin/uwsgi --post-buffering 65536 --ini /etc/tryton/uwsgi.ini

[Install]
WantedBy=multi-user.target

/etc/tryton/uwsgi.ini:

[uwsgi]
uid = tryton
gid = tryton
socket = /run/trytond/trytond.sock
chmod-socket = 660
plugins = python3
module = trytond.application:app
env = TRYTOND_CONFIG=/etc/tryton/trytond.conf
env = TRYTOND_LOGGING_CONFIG=/etc/tryton/trytond_log.conf
env = TRYTOND_DATABASE_NAMES=tryton

logto = /var/log/uwsgi/tryton.log
log-5xx = true
disable-logging = true

lazy-apps=true

master
workers = 1
max-requests = 200
harakiri = 30
die-on-term
1 Like
18

This is the line that force the creation of the connection pool.
I created Do not copy connection pool after fork (#8281) · Issues · Tryton / Tryton · GitLab to be able to use the advantage of loading the database before the fork.

1 Like
19

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.