Firebird 1.5_2 && FreeBSD

[Vladimir D Belousov]

Приветсвую!

Обнаружено крайне неприятное поведение Firebird (а может IBExpert?)

ПО:
Сервер: FreeBSD 5.4, Firebird 1.5_2 (порт сегодняшний).
Клиент: WinXP + IBExpert 2005.06.07

При создании БД из isql на сервер простым
create database /var/db/firebird/links.gdb
файл БД создается, а владельцем его становится root. Но при подключении по сети, inetd меняет UID процесса firebird на UID, соответствующий пользователю firebird. Это не то, чтобы крайне неприятно, но как минимум неудобно.

А что реально неприятно, это то, что при создании БД на сервере с путем (например) /var/db/firebird/links.gdb и последующей регистрациеи этой БД в IBExpert, при попытке коннекта выскакивает ошибка, что мол reading error (удаленный сервер разорвал соединение).
Однако если путь будет короче (/var/db/links.gdb) - такой ошибки не возникает.

При исследовании данной проблемы ktrace-ом, последние вызовы ib_inet_service такие:
1165 fb_inet_server CALL __sysctl(0xbfbfea38,0x2,0xbfbfea60,0xbfbfea54,0,0)
1165 fb_inet_server RET __sysctl 0
1165 fb_inet_server CALL setsockopt(0,0xffff,0x8,0xbfbfead8,0x4)
1165 fb_inet_server RET setsockopt -1 errno 38 Socket operation on non-socket
1165 fb_inet_server CALL select(0x1,0xbfbfe3e0,0,0,0xbfbfe158)
1165 fb_inet_server RET select -1 errno 4 Interrupted system call
1165 fb_inet_server PSIG SIGINT SIG_DFL

Как вариант - бьется память при слишком длинном пути БД?

Может кто ткнет носом, в чем я не прав? Я уже замучался.

[kdv]

Это не то, чтобы крайне неприятно, но как минимум неудобно.

а нефиг при создании БД использовать локальный коннект. Не нравится - смени юзера firebird на root. короче, пиши всегда localhost:/var/db... и будет тебе щастье.

[dimitr]

Дим, что ты имеешь против локального коннекта в классике? Он жил, жив и будет жить.

[dimitr]

При создании БД из isql на сервер простым
create database /var/db/firebird/links.gdb
файл БД создается, а владельцем его становится root.

естественно. Под кем запускаешь ISQL, тот и становится владельцем файла.

Но при подключении по сети, inetd меняет UID процесса firebird на UID, соответствующий пользователю firebird. Это не то, чтобы крайне неприятно, но как минимум неудобно.

Чем неудобно? По мне, так вполне логично. Если кто-то ломится по сети, то использовать надо какой-либо локальный эккаунт. По умолчанию это firebird.

А что реально неприятно, это то, что при создании БД на сервере с путем (например) /var/db/firebird/links.gdb и последующей регистрациеи этой БД в IBExpert, при попытке коннекта выскакивает ошибка, что мол reading error (удаленный сервер разорвал соединение).
Однако если путь будет короче (/var/db/links.gdb) - такой ошибки не возникает.

Тут ты пишешь локальную строку коннекта, а ниже про fb_inet_server. Так что полагаю, что подключаешься все-таки через TCP/IP с указанием имени хоста. Если так, то наверняка ты нарвался на какой-либо баг с переполнением буфера. Причем есть подозрение, что он исправлен в FB2.

[Vladimir D Belousov]

При создании БД из isql на сервер простым
create database /var/db/firebird/links.gdb
файл БД создается, а владельцем его становится root.

естественно. Под кем запускаешь ISQL, тот и становится владельцем файла.

Да, это логично. Согласен.
Конечно, правильнее было бы сначала свой UID менять на firebird, или как мне указали выше, использвать dsn вида localhost:/path/to/db

Господа, я вас неумышленно обманул с обстоятельствами ошибки.
При более подробном изучении проблемы, оказалось что описанная мною ошибка - fb_inet_service убивается по 11 сигналу не в описанном мню случае, а лишь при условии, что я ставлю кодировку по умолчанию для БД = WIN1251 (при удаленном соединении).
При этом остается висеть процесс /usr/local/firebird/bin/fb_lock_mgr