Open tomaszdubiel18 opened 1 year ago
Re UBUNTU. Please provide stack traces (all threads) for any one process which keeps undesired connection in ESTABLISHED state.
When I ran: root@stream:/opt/firebird# strace -s 99 -ffp 639871 I got this. Is this what you want? Sorry for the delay, but problem temporarily stopped occuring, but now came back and it is again very problematic: strace: Process 639871 attached with 7 threads [pid 639937] futex(0x7fa216f699d8, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...> [pid 639913] futex(0x7fa216f7cd8c, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...> [pid 639876] futex(0x7fa216101130, FUTEX_WAIT_BITSET|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...> [pid 639873] futex(0x7fa21d166350, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, NULL, FUTEX_BITSET_MATCH_ANY <unfinished ...> [pid 639872] restart_syscall(<... resuming interrupted read ...> <unfinished ...> [pid 639874] restart_syscall(<... resuming interrupted read ...> <unfinished ...> [pid 639871] restart_syscall(<... resuming interrupted read ...> <unfinished ...> [pid 639872] <... restart_syscall resumed>) = -1 ETIMEDOUT (Connection timed out) [pid 639872] futex(0x7fa21ce46d40, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 0, {tv_sec=1694525515, tv_nsec=641920000}, FUTEX_BITSET_MATCH_ANY <unfinished ...> [pid 639871] <... restart_syscall resumed>) = 0 [pid 639871] poll([{fd=1, events=POLLIN}], 1, 60000
When I ran gdb command, I got this: Please take a look: Thread 7 (Thread 0x7fa1d4be7640 (LWP 639937) "firebird"):
Thread 6 (Thread 0x7fa2097ff640 (LWP 639913) "firebird"):
Thread 5 (Thread 0x7fa210bff640 (LWP 639876) "firebird"):
--Type
Thread 4 (Thread 0x7fa2177fe640 (LWP 639874) "firebird"):
Thread 3 (Thread 0x7fa217fff640 (LWP 639873) "firebird"):
Thread 2 (Thread 0x7fa21ce47640 (LWP 639872) "firebird"):
Thread 1 (Thread 0x7fa21d173c00 (LWP 639871) "firebird"):
Sorry, forgot to mention that you should install debugInfo for your FB version.
I hope I did everything ok. Is this useful information for you? Please take a look. We are looking for a solution to this problem.
Thread 7 (Thread 0x7fa1d3777640 (LWP 782759) "firebird"):
Thread 6 (Thread 0x7fa2097ff640 (LWP 782758) "firebird"):
Thread 5 (Thread 0x7fa210bff640 (LWP 782756) "firebird"):
--Type
Thread 4 (Thread 0x7fa2177fe640 (LWP 782754) "firebird"):
Thread 3 (Thread 0x7fa217fff640 (LWP 782753) "firebird"):
Thread 2 (Thread 0x7fa21ce47640 (LWP 782752) "firebird"):
Thread 1 (Thread 0x7fa21d173c00 (LWP 782751) "firebird"):
Yes, stack traces are OK. I see EventManager in one of threads. That means your process can deliver events back to client, that adds one connection required for it. I.e. ONE additional opened socket is normal when you work with events, and yes, sooner of all it's not shown in monitoring.
How many connections does this particular (or similar - I doubt this one is still alive) process have actually? I.e. please add netstat for a PID next time you send me stack traces.
Hello. This time I send stack for a regular Firebird process listening on the main port 3050. This process PID is 1035711 Attaching to process 1035711 [New LWP 1035712] [New LWP 1035713] [New LWP 1035714] [New LWP 1035716] [New LWP 1035734] [New LWP 1035735] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x00007f6c98bddd7f in __GI___poll (fds=0x7f6c993ec9b8, nfds=1, timeout=60000) at ../sysdeps/unix/sysv/linux/poll.c:29 29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. (gdb) thread apply all bt
Thread 7 (Thread 0x7f6c4e3ab640 (LWP 1035735) "firebird"):
Thread 6 (Thread 0x7f6c8d7ff640 (LWP 1035734) "firebird"):
Thread 5 (Thread 0x7f6c94aff640 (LWP 1035716) "firebird"):
--Type
Thread 4 (Thread 0x7f6c977c9640 (LWP 1035714) "firebird"):
Thread 3 (Thread 0x7f6c97fca640 (LWP 1035713) "firebird"):
Thread 2 (Thread 0x7f6c987cb640 (LWP 1035712) "firebird"):
Thread 1 (Thread 0x7f6c9941ec00 (LWP 1035711) "firebird"):
Here is another example, with some netstat info added. Can you see now what is the reason of those processes established without flag "keepalive" remaining active?
root@stream:/home/stream# netstat -ano --timers | grep "xxx:60929" tcp6 0 0 xxx:3050 xxx:60929 ESTABLISHED off (0.00/0/0)
root@stream:/home/stream# lsof -i :3050 | grep "xxx:60929" firebird 1040351 firebird 1u IPv6 12399451 0t0 TCP stream:gds-db->xxx:60929 (ESTABLISHED)
Attaching to process 1040351 [New LWP 1040352] [New LWP 1040353] [New LWP 1040354] [New LWP 1040356] [New LWP 1040358] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". 0x00007f6c98bddd7f in __GI___poll (fds=0x7f6c993ec9b8, nfds=1, timeout=60000) at ../sysdeps/unix/sysv/linux/poll.c:29 29 ../sysdeps/unix/sysv/linux/poll.c: No such file or directory. (gdb) thread apply all bt
Thread 6 (Thread 0x7f6c8d7ff640 (LWP 1040358) "firebird"):
Thread 5 (Thread 0x7f6c94aff640 (LWP 1040356) "firebird"):
Thread 4 (Thread 0x7f6c977c9640 (LWP 1040354) "firebird"):
Thread 3 (Thread 0x7f6c97fca640 (LWP 1040353) "firebird"):
Thread 2 (Thread 0x7f6c987cb640 (LWP 1040352) "firebird"):
--Type
Thread 1 (Thread 0x7f6c9941ec00 (LWP 1040351) "firebird"):
Here is another example, with some netstat info added. Can you see now what is the reason of those processes established without flag "keepalive" remaining active?
Taking into an account that this is FB3 Classic on Linux with systemd - I suppose problems are with systemd's firebird-classic.socket file in /usr/lib/systemd/system (or /lib/systemd/system) - is line KeepAlive=true present in it? Default file has that line.
FB Classic on linux before v.4 does not open socket itself - it's just using one opened by systemd (or xinetd on some systems).
Yes, there is that line in this file.
In that case formally it's systemd problem - socket should have keepalive set. But telling true I doubt that :-) Sooner of all your server is misconfigured in some way.
Hello. I've been told to create an issue here. Firebird 3.0.10. The problem is present on Windows Server 2022, Firebird 3.0.10 SuperServer and on Ubuntu 22.04.2 Firebird 3.0.10 ClassicServer. On Ubuntu the problem is serious. Many connections remain in ESTABLISHED state, even though there are no entries from that IP in MON$ATTACHMENTS, and every two days RAM is finished. On Windows it's not that serious, but the problem is present as well.