When one of attachments is running high load query like:
select count(*) from rdb$triggers,rdb$triggers,rdb$triggers,rdb$triggers,rdb$triggers;
"gfix -shut full -force 0 " is waiting for such query completion. In case query is ran away query and it will be running for hours or days - there is no way to finish shutdown operation. Exact query identification using monitoring tables is also problematic. See CORE1561 for details.
I retested this case on Firebird-220.127.116.1176-0_Win32 (2007-11-14 02:11:33 snapshot build). Even gfix now exists with error "Connection Lost to database", the high load connection is not killed. It is listed as active process with 0 CPU utilization. Starting from this point it's impossible to bring DB online. "gfix -online" gives "lock conflict on no wait transaction -database C:\TEST.FDB shutdown" error. Can You look into it one more time?
By design, shutdown doesn't kill connections. It just interrupts their activity, releases their locks and mark database as shutdown. So the behavior you see is expected. However, the issue with bringing database online smells like a bug. I will take a look.
For some reason client activity is not interrupted on client side. After shutdown it keeps running withour any error. So client has no clue what is going on ank keeps waiting for data which will never be delivered. Shouldn't client get SQL error in this case?