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
GLDS found a problem with fbtracemgr in 2.5.1 snapshot builds (lock-ups)
on Linux and I confirmed it.
After using interactive fbtracemgr for a few minutes I had another lockup, was not able to connect to any db, one old fb process was still working (i.e. not completely locked up). What happened is that I was running load simulator and started interactive trace manager. It was working fine for a few minutes, then I noticed that load simulator stuck. Checked fb processes on server and they were not working. Ctrl-C'ed fbtracemgr. Tried to connect with embedded isql to that and to different db -- no luck (no response). Killed all fb processes connected to that db. Newest lock file was used only by that old working fb process, other older lock files were not used by any process. Still was not able to connect (stack traces for stuck isql below). Commenting out AuditTraceConfigFile in firebird.conf and undoing fbtrace.conf did not help. Renaming /tmp/firebird/fb_trace.{57CC44CD-3A56-92D4-3CF1-2C10B655CBA1}.0000000 helped, server is alive again.
Submitted by: @AlexPeshkoff
Issue reported by Pavel Cisar:
GLDS found a problem with fbtracemgr in 2.5.1 snapshot builds (lock-ups)
on Linux and I confirmed it.
After using interactive fbtracemgr for a few minutes I had another lockup, was not able to connect to any db, one old fb process was still working (i.e. not completely locked up). What happened is that I was running load simulator and started interactive trace manager. It was working fine for a few minutes, then I noticed that load simulator stuck. Checked fb processes on server and they were not working. Ctrl-C'ed fbtracemgr. Tried to connect with embedded isql to that and to different db -- no luck (no response). Killed all fb processes connected to that db. Newest lock file was used only by that old working fb process, other older lock files were not used by any process. Still was not able to connect (stack traces for stuck isql below). Commenting out AuditTraceConfigFile in firebird.conf and undoing fbtrace.conf did not help. Renaming /tmp/firebird/fb_trace.{57CC44CD-3A56-92D4-3CF1-2C10B655CBA1}.0000000 helped, server is alive again.
Commits: 772f9af 248d4ee
The text was updated successfully, but these errors were encountered: