You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Our full-stack app has its FastAPI backend running on Linux server, it connects to our MySQL database.
Ever since our IT has upgraded podman from version 4.9.4 to 5.2.2, we have been seeing this "Lost connection" error while running multiple queries (reads and writes) within a single POST request from our frontend:
[ERROR] pid:35 (pymysql.err.OperationalError) (2013, 'Lost connection to MySQL server during query ([Errno 104] Connection reset by peer)')
(Background on this error at: https://sqlalche.me/e/20/e3q8)
This error happens randomly, but it seems like it will happen when the POST request takes more than 12 seconds or so (in that particular environment), while this single request has a lot of queries. But sometimes a long request can go through without running into this connection error.
After a lot of searches and different approaches, including:
changing MySQL database's parameters like increasing read_timeout, write_timeout, increasing max_allowed_packet_size, etc.
rebuilding and rebooting containers.
openning up firewall setting to allow direct connection from laptop to linux server.
changing SQLAlchemy's engine configuration like limiting connection pool to 1, turning on connection_pre_ping, etc.
Then we decided to rollback our podman version to 4.9.4 where before the errors started happening, no more errors!
Steps to reproduce the issue
Steps to reproduce the issue
1.
2.
3.
Describe the results you received
[ERROR] pid:35 (pymysql.err.OperationalError) (2013, 'Lost connection to MySQL server during query ([Errno 104] Connection reset by peer)')
(Background on this error at: https://sqlalche.me/e/20/e3q8)
Describe the results you expected
The POST request will trigger a series of sql reads, computations and writes on backend, these queries should stay connected and run perfectly.
podman info output
host:
arch: amd64buildahVersion: 1.33.11cgroupControllers:
- memory
- pidscgroupManager: systemdcgroupVersion: v2conmon:
package: conmon-2.1.12-1.el9.x86_64path: /usr/bin/conmonversion: 'conmon version 2.1.12, commit: c0564282e9befb7804c3642230f8e94f1b2ba9f8'cpuUtilization:
idlePercent: 99.94systemPercent: 0.01userPercent: 0.05cpus: 32databaseBackend: boltdbdistribution:
distribution: rhelversion: "9.5"eventLogger: filefreeLocks: 2046hostname: ********idMappings:
gidmap:
- container_id: 0host_id: 1002size: 1
- container_id: 1host_id: 100000size: 65536uidmap:
- container_id: 0host_id: 1002size: 1
- container_id: 1host_id: 100000size: 65536kernel: 5.14.0-503.21.1.el9_5.x86_64linkmode: dynamiclogDriver: k8s-filememFree: 257668243456memTotal: 266766888960networkBackend: netavarknetworkBackendInfo:
backend: netavarkdns:
package: aardvark-dns-1.12.2-1.el9_5.x86_64path: /usr/libexec/podman/aardvark-dnsversion: aardvark-dns 1.12.2package: netavark-1.12.2-1.el9.x86_64path: /usr/libexec/podman/netavarkversion: netavark 1.12.2ociRuntime:
name: crunpackage: crun-1.16.1-1.el9.x86_64path: /usr/bin/crunversion: |- crun version 1.16.1 commit: afa829ca0122bd5e1d67f1f38e6cc348027e3c32 rundir: /run/user/1002/crun spec: 1.0.0 +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJLos: linuxpasta:
executable: /usr/bin/pastapackage: passt-0^20240806.gee36266-2.el9.x86_64version: | pasta 0^20240806.gee36266-2.el9.x86_64 Copyright Red Hat GNU General Public License, version 2 or later <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.remoteSocket:
exists: falsepath: /run/user/1002/podman/podman.socksecurity:
apparmorEnabled: falsecapabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOTrootless: trueseccompEnabled: trueseccompProfilePath: /usr/share/containers/seccomp.jsonselinuxEnabled: falseserviceIsRemote: falseslirp4netns:
executable: /usr/bin/slirp4netnspackage: slirp4netns-1.3.1-1.el9.x86_64version: |- slirp4netns version 1.3.1 commit: e5e368c4f5db6ae75c2fce786e31eef9da6bf236 libslirp: 4.4.0 SLIRP_CONFIG_VERSION_MAX: 3 libseccomp: 2.5.2swapFree: 0swapTotal: 0uptime: 8h 53m 55.00s (Approximately 0.33 days)variant: ""plugins:
authorization: nulllog:
- k8s-file
- none
- passthrough
- journaldnetwork:
- bridge
- macvlan
- ipvlanvolume:
- localregistries:
search:
- registry.access.redhat.com
- registry.redhat.io
- docker.iostore:
configFile: /home/****/.config/containers/storage.confcontainerStore:
number: 2paused: 0running: 2stopped: 0graphDriverName: overlaygraphOptions: {}graphRoot: /home/****/.local/share/containers/storagegraphRootAllocated: 321375940608graphRootUsed: 20980580352graphStatus:
Backing Filesystem: xfsNative Overlay Diff: "true"Supports d_type: "true"Supports shifting: "false"Supports volatile: "true"Using metacopy: "false"imageCopyTmpDir: /var/tmpimageStore:
number: 4runRoot: /run/user/1002/containerstransientStore: falsevolumePath: /home/****/.local/share/containers/storage/volumesversion:
APIVersion: 4.9.4-rhelBuilt: 1730450505BuiltTime: Fri Nov 1 04:41:45 2024GitCommit: ""GoVersion: go1.21.13 (Red Hat 1.21.13-5.el9_4)Os: linuxOsArch: linux/amd64Version: 4.9.4-rhel
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
This version of podman works without errors.
Client: Podman Engine
Version: 4.9.4-rhel
API Version: 4.9.4-rhel
Go Version: go1.21.13 (Red Hat 1.21.13-5.el9_4)
Built: Fri Nov 1 04:41:45 2024
OS/Arch: linux/amd64
Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting
The text was updated successfully, but these errors were encountered:
Issue Description
Our full-stack app has its FastAPI backend running on Linux server, it connects to our MySQL database.
Ever since our IT has upgraded podman from version 4.9.4 to 5.2.2, we have been seeing this "Lost connection" error while running multiple queries (reads and writes) within a single POST request from our frontend:
This error happens randomly, but it seems like it will happen when the POST request takes more than 12 seconds or so (in that particular environment), while this single request has a lot of queries. But sometimes a long request can go through without running into this connection error.
After a lot of searches and different approaches, including:
Then we decided to rollback our podman version to 4.9.4 where before the errors started happening, no more errors!
Steps to reproduce the issue
Steps to reproduce the issue
1.
2.
3.
Describe the results you received
Describe the results you expected
The POST request will trigger a series of sql reads, computations and writes on backend, these queries should stay connected and run perfectly.
podman info output
Podman in a container
No
Privileged Or Rootless
Rootless
Upstream Latest Release
Yes
Additional environment details
This version of podman works without errors.
Additional information
Additional information like issue happens only occasionally or issue happens with a particular architecture or on a particular setting
The text was updated successfully, but these errors were encountered: