Steven Peterson wrote:

> This last happened when I was using isql -- The application using the
> database had been zipping along fine all day. I mistyped a select
> query and rather than wait for all the output, I ctrl-Z'd the isql
> window back to the shell prompt. Then when I tried to start a new
> isql session, any query I submitted just hung there with no output or
> error. What was worse, the application which was using the same
> database was completely unable to execute any queries against the
> database.
>
> I tried to kill -TERM the isql session

You should kill fb_inet_server instead, and isql would lock out itself.

> tried 'killall -TERM
> fb_iniet_server", shutdown the firebird server (/etc/init.d/xinetd
> stop), restarted it

/etc/init.d/xinetd does not restart the firebird server, only the port
listener. In fact, there is not reason to restart xinetd.

killall -9 fb_inet_server should kill all running classic servers.
However, it is possible that the lock manager got stuck for some reason,
so you should also do "killall -9 fb_lock_mgr" to be safe.

After these kill commands, make sure you run ps and see if they are
really killed. If some of them is still there and reports z (zombie)
status, than maybe you have some hardware problem. Try to find out if
anything strange is happening with dmesg command.

> Before rebooting, I noticed the the isc_lock1... file had expanded
> from its default of 1meg to 1.5meg. I am assuming that this is some
> kind of locking issue but have no idea how to fix it. It has happened
> in the past without me ctrl-Zing out of isql, so there is some lurking
> problem there.

Yes, this looks like problem with lock manager that I wrote about above.

Regards,

--
Milan Babuskov
http://www.flamerobin.org
http://www.guacosoft.com