wine:current(eter8/eter18). При запуске(во время соединения с сервером): Ошибка при выполнении операции с информационной базой. Внутренняя ошибка. На других дистрибутивах не воспроизводится.
Надо поднять windows servert с MS SQL 2000/2005, там же развернуть 1с кластер(у клиента серверная часть 8.1.13.41).
Выяснилось, что тестировать надо было на Windows 2003. Поднял Windows Server 2003 [T] (общая для тестирования). 192.168.4.82 . w2k3 не работает кончилась лицензия. Там все поднял 1с server. MS SQL Server использовал тоже Windows 2003-MS-SQL-2005 База называется: testwin2k3serv81mssql
Все работает во всех вариация. Если вписывать ip, хосты на сервере и клиенте, все равно. Если сервер запустился к нему можно подключиться.
Протестировал на машине с самыми последними обновлениями - воспроизводится.
Что бы начать тестирование надо vbox start 76da821c-1ffe-44dc-9a7c-cc8dee1d5621 vbox start 5190bb35-19f8-47f0-8d78-a3028c082132 Для подключения 1с сервер 192.168.4.82 база testwin2k3serv81mssql
до обновления ubuntu 10.10 vbox соединения с сервером устанавливается.
Обновить ubuntu не получилосьб почему отлетели все репозитории. Подождем пару часов.
Результаты такие. Обновил vm Ubuntu 10.10(32 бита) - 1с конектится и работает. Обновил машину kompas ubuntu 10.10(32 бита) - 1с конектится и работает. Обновил Свой ноут Ubuntu 10.10(32 бита) - 1с НЕ коннектится и не работает. Установил и обновил голую систему Ubuntu 10.10 x86_64 [T] - 1с не коннектится и не работает. Итого, думаю, что можно искать причину на машине Ubuntu 10.10 x86_64 [T]
(В ответ на comment #10) ... > Итого, думаю, что можно искать причину на машине Ubuntu 10.10 x86_64 [T] Ну это может быть просто. Там могут не все 32-битные библиотеки присутствовать. Можно попробовать сначала обычный wine установить в систему, а потом наш.
Так я не понял — потестировали и бросили.
Я виду, что нету разницы по заявкам, что в 36-х битной или 64. В заявке 18035 написано, что использовался debian lenny. Надо поставить debian lenny 86, все обновить, поставить wine@etersoft. Если ошибка воспроизводится, поставить wine от winehq, посмотреть, какие пакеты он вытянет за собой и повторить тест.
Протестировал на [T] Debian 5.0.8. Обновил эту машину с 5.0.6. Там стоял предыдущий WINE@ из ветки testing. Обновил WINE@Etersoft до eter8/eter18. Все работает, то есть 1с запускается и подключается к севреру. Не воспроизводится.
Можно попросить, чтобы нам прислали образ виртуальной машины, в которой это воспроизводится - так нам будет легче воспроизводить.
В Ubuntu 10.10 х86_64 [T] при установке wineHQ из стандартных репозиториев: Будут установлены следующие дополнительные пакеты: cabextract gnome-exe-thumbnailer icoutils imagemagick lib32nss-mdns libcdt4 libgraph4 libgvc5 libilmbase6 libmagickcore3-extra libnetpbm10 libopenexr6 libpathplan4 libxdot4 netpbm ttf-droid ttf-mscorefonts-installer ttf-symbol-replacement ttf-umefont winbind wine1.2 wine1.2-gecko Предлагаемые пакеты: libterm-readline-gnu-perl libterm-readline-perl-perl imagemagick-doc autotrace curl enscript ffmpeg gimp gnuplot grads hp2xx html2ps libwmf-bin mplayer povray radiance texlive-base-bin transfig ufraw-batch Рекомендуемые пакеты: winetricks wisotool НОВЫЕ пакеты, которые будут установлены: cabextract gnome-exe-thumbnailer icoutils imagemagick lib32nss-mdns libcdt4 libgraph4 libgvc5 libilmbase6 libmagickcore3-extra libnetpbm10 libopenexr6 libpathplan4 libxdot4 netpbm ttf-droid ttf-mscorefonts-installer ttf-symbol-replacement ttf-umefont winbind wine wine1.2 wine1.2-gecko После этого удалил его и поставил WINE@Etersoft. Теперь ничего не запускается вообще guest@guest-VirtualBox:~$ winediag winediag: error while loading shared libraries: libwine-etersoft.so.1: cannot open shared object file: No such file or directory
(В ответ на comment #17) > После этого удалил его и поставил WINE@Etersoft. > Теперь ничего не запускается вообще > guest@guest-VirtualBox:~$ winediag > winediag: error while loading shared libraries: libwine-etersoft.so.1: cannot > open shared object file: No such file or directory Ну видимо надо проверить, что за пакеты поставил, и куда делся libwine-etersoft.so.1. Всё-таки они с winediag в одном пакете. И уж с предыдущими действиями по обновлению это не связано.
(В ответ на comment #11) > > Итого, думаю, что можно искать причину на машине Ubuntu 10.10 x86_64 [T] > Ну это может быть просто. Там могут не все 32-битные библиотеки присутствовать. > > Можно попробовать сначала обычный wine установить в систему, а потом наш. Естественно пробовал. ----- Мы так и не получили образа виртуальной машины, на которой это воспроизводится. Проблема не воспроизводится на наших конейнерах, 1с клиент, сервер и бд находятся в одной подсети x.x.4.x. Я так же тестировал на своем ноутбуке, у меня не происходит подключения, мой ноут находится в x.x.8.x. Проблем с маршрутизацией нет, так как ssh на все контейнеры пробрасывается. Но это может быть частным случаем. Если бы проблема была исключительно на стороне WINE@, тогда бы и в других дистрибутивах не происходило бы подключения, да и вообще проблема была бы видна не вооруженным глазом. Проблема в каком-то недостающем пакете/либе? Почему тогда в кроссовере работает? У меня нет соображений на эту тему.
Необходимо обратить внимание на содержимое /etc/resolv.conf, оно должно иметь такой вид: domain office.etersoft.ru search office.etersoft.ru nameserver 192.168.0.1
Заходил на машину клиента с данной проблемой с помощью teamviewer. Поставил winbind. Скопировал список пакетов и лог запуска 1С на машине клиента в /var/ftp/pvt/Windows/Testing/Bugs/6900. Хотел попробовать запустить wine с другими библиотеками (libc и т.п.), но, к сожалению, они там не загрузились из-за отсутствия нужного символа в ld-linux.so.2. Запустить через другой ld-linux.so.2 не получилось (cannot open shared object file).
Что-то поменялись все ip-шники. Что бы начать тестирование надо vbox start 76da821c-1ffe-44dc-9a7c-cc8dee1d5621 vbox start 5190bb35-19f8-47f0-8d78-a3028c082132 Для подключения 1с сервер 192.168.4.239 база testwin2k3serv81mssql
Получил лог 1С, положил в /var/ftp/pvt/Windows/Testing/Bugs/6900. Ничего интересного в логе вроде бы нет. Заканчивается так: 39:17.4301-0,EXCP,0,process=1cv8,Exception=Exception,Descr='Ошибка при выполнении операции с информационной базой Внутренняя ошибка.'
Сделал 1с82 Виртуальная машина "Windows 2003 1c82 Server" (f8f35a05-ec5e-4669-afb7-b17baa7f88ee) Сделал базу на той же машине SQL 1с сервер 192.168.4.237 база testwin2k3serv82mssql
Сравнил лог, полученный у клиента с проблемой подключения 1С8.2 к базе, с логом, полученным у нас. У нас после первого recv, вызванного для сокета 0x484, посылается 0x272 байта, а у клиента 4. [amorozov@atlant tmp]$ grep 484 ws2_32_ok.log 002d:Ret ws2_32.socket() retval=00000484 ret=28854cac 002d:Call ws2_32.bind(00000484,28946ed8,00000010) ret=28854ce9 002d:Call ws2_32.closesocket(00000484) ret=28854cfa 003e:Ret ws2_32.socket() retval=00000484 ret=4d100bb9 003e:Call ws2_32.connect(00000484,0245dc9c,00000010) ret=4d100d44 003e:Call ws2_32.getsockname(00000484,0245dcac,0032d684) ret=4d100ebd 003e:Call ws2_32.setsockopt(00000484,00000006,00000001,0032d60c,00000004) ret=4d0f6c56 003e:Call ws2_32.recv(00000484,0032d66c,00000005,00000000) ret=4d101b47 003e:Call ws2_32.send(00000484,0245dd40,00000272,00000000) ret=4d101991 003e:Call ws2_32.recv(00000484,02465d60,00008000,00000000) ret=4d101b47 003e:Call ws2_32.send(00000484,0245dd40,000001fe,00000000) ret=4d101991 003e:Call ws2_32.recv(00000484,02465d60,00008000,00000000) ret=4d101b47 003e:Call ws2_32.send(00000484,0245dd40,00000060,00000000) ret=4d101991 003e:Call ws2_32.recv(00000484,02465d60,00008000,00000000) ret=4d101b47 003e:Call ws2_32.send(00000484,0245dd40,0000009c,00000000) ret=4d101991 003e:Call ws2_32.recv(00000484,02465d60,00008000,00000000) ret=4d101b47 003e:Call ws2_32.send(00000484,0245dd40,0000001d,00000000) ret=4d101991 003e:Call ws2_32.recv(00000484,02465d60,00008000,00000000) ret=4d101b47 003e:Call ws2_32.closesocket(00000484) ret=4d101cc2 002d:Ret ws2_32.socket() retval=00000484 ret=28854cac 002d:Call ws2_32.bind(00000484,28946ed8,00000010) ret=28854ce9 002d:Call ws2_32.closesocket(00000484) ret=28854cfa 002d:Ret ws2_32.socket() retval=00000484 ret=28854cac 002d:Call ws2_32.bind(00000484,28946ed8,00000010) ret=28854ce9 002d:Call ws2_32.closesocket(00000484) ret=28854cfa [amorozov@atlant tmp]$ grep 484 ws2_32_bad.log 0042:Ret ws2_32.socket() retval=00000484 ret=28854cac 0042:Call ws2_32.bind(00000484,28946ed8,00000010) ret=28854ce9 0042:Call ws2_32.closesocket(00000484) ret=28854cfa 003a:Ret ws2_32.socket() retval=00000484 ret=4d100bb9 003a:Call ws2_32.connect(00000484,0161dde4,00000010) ret=4d100d44 003a:Call ws2_32.getsockname(00000484,0161ddf4,0032d684) ret=4d100ebd 003a:Call ws2_32.setsockopt(00000484,00000006,00000001,0032d60c,00000004) ret=4d0f6c56 003a:Call ws2_32.recv(00000484,0032d66c,00000005,00000000) ret=4d101b47 003a:Call ws2_32.send(00000484,0161de88,00000004,00000000) ret=4d101991 003a:Call ws2_32.closesocket(00000484) ret=4d101cc2 0042:Ret ws2_32.socket() retval=00000484 ret=28854cac 0042:Call ws2_32.bind(00000484,28946ed8,00000010) ret=28854ce9 0042:Call ws2_32.closesocket(00000484) ret=28854cfa 0042:Ret ws2_32.socket() retval=00000484 ret=28854cac 0042:Call ws2_32.bind(00000484,28946ed8,00000010) ret=28854ce9 0042:Call ws2_32.closesocket(00000484) ret=28854cfa
Что-то в этот раз какие-то проблемы с подключением к машине клиента. Мышка беспорядочно дёргается и не управляется с моей машины. Блокирование средств ввода удалённой машины не работает: удалённый TeamViewer не поддерживает эту функцию.
Вырезал из нашего и клиентского relay-логов участок между первыми recv и send для сокета 484. В клиентском логе в этом участке есть генерация исключения: $ grep RaiseException recv_send_bad.log 0042:Call KERNEL32.RaiseException(e06d7363,00000001,00000003,0032d3f0) ret=7857dbf9 $ grep RaiseException recv_send_ok.log recv_send_bad.log - клиентский лог recv_send_ok.log - лог у нас Также различается grep по advapi32: $ grep advapi32 recv_send_bad.log 0042:Call advapi32.CryptAcquireContextW(0032adbc,00000000,00000000,00000001,f0000000) ret=2568957a 0042:Call advapi32.RegOpenKeyW(80000002,6154e980 L"Software\\Microsoft\\Cryptography\\OID\\EncodingType 0\\CryptDllFindOIDInfo",0032a774) ret=6153776b 0042:Ret advapi32.RegOpenKeyW() retval=00000002 ret=6153776b 0042:Call advapi32.GetUserNameA(0032aa08,0032a900) ret=614d0905 0042:Ret advapi32.GetUserNameA() retval=00000001 ret=614d0905 0042:Ret advapi32.CryptAcquireContextW() retval=00000001 ret=2568957a 0042:Call advapi32.CryptGenRandom(001b6bd8,00000040,0032ae58) ret=25689591 0042:Call advapi32.SystemFunction036(0032ae58,00000040) ret=614c4200 0042:Ret advapi32.SystemFunction036() retval=00000001 ret=614c4200 0042:Ret advapi32.CryptGenRandom() retval=00000001 ret=25689591 0042:Call advapi32.CryptReleaseContext(001b6bd8,00000000) ret=256895c2 0042:Ret advapi32.CryptReleaseContext() retval=00000001 ret=256895c2 0042:Call advapi32.CryptAcquireContextW(0032adbc,00000000,2570e900 L"Intel Hardware Cryptographic Service Provider",00000016,00000000) ret=256895d4 0042:Ret advapi32.CryptAcquireContextW() retval=00000000 ret=256895d4 0042:Call advapi32.InitializeSecurityDescriptor(0032c934,00000001) ret=4a83c6c1 0042:Ret advapi32.InitializeSecurityDescriptor() retval=00000001 ret=4a83c6c1 0042:Call advapi32.SetSecurityDescriptorDacl(0032c934,00000001,00000000,00000000) ret=4a83c6d3 0042:Ret advapi32.SetSecurityDescriptorDacl() retval=00000001 ret=4a83c6d3 0042:Call advapi32.InitializeSecurityDescriptor(0032c95c,00000001) ret=4a83c6c1 0042:Ret advapi32.InitializeSecurityDescriptor() retval=00000001 ret=4a83c6c1 0042:Call advapi32.SetSecurityDescriptorDacl(0032c95c,00000001,00000000,00000000) ret=4a83c6d3 0042:Ret advapi32.SetSecurityDescriptorDacl() retval=00000001 ret=4a83c6d3 $ grep advapi32 recv_send_ok.log 000b:Call advapi32.CryptAcquireContextW(0032adbc,00000000,00000000,00000001,f0000000) ret=2568957a 000b:Call advapi32.RegOpenKeyW(80000002,7d41a980 L"Software\\Microsoft\\Cryptography\\OID\\EncodingType 0\\CryptDllFindOIDInfo",0032a774) ret=7d40376b 000b:Ret advapi32.RegOpenKeyW() retval=00000002 ret=7d40376b 000b:Call advapi32.GetUserNameA(0032aa08,0032a900) ret=7d464905 000b:Ret advapi32.GetUserNameA() retval=00000001 ret=7d464905 000b:Ret advapi32.CryptAcquireContextW() retval=00000001 ret=2568957a 000b:Call advapi32.CryptGenRandom(001b2010,00000040,0032ae58) ret=25689591 000b:Call advapi32.SystemFunction036(0032ae58,00000040) ret=7d458200 000b:Ret advapi32.SystemFunction036() retval=00000001 ret=7d458200 000b:Ret advapi32.CryptGenRandom() retval=00000001 ret=25689591 000b:Call advapi32.CryptReleaseContext(001b2010,00000000) ret=256895c2 000b:Ret advapi32.CryptReleaseContext() retval=00000001 ret=256895c2 000b:Call advapi32.CryptAcquireContextW(0032adbc,00000000,2570e900 L"Intel Hardware Cryptographic Service Provider",00000016,00000000) ret=256895d4 000b:Ret advapi32.CryptAcquireContextW() retval=00000000 ret=256895d4 У клиента 1С 8.2.13.202, а у нас 8.2.13.205. Поставил у нас 8.2.13.202. К базе не подключается, пишет, что различаются версии клиента и сервера.
> У клиента 1С 8.2.13.202, а у нас 8.2.13.205. Поставил у нас 8.2.13.202. К базе > не подключается, пишет, что различаются версии клиента и сервера. Воспроизвёл и на 8.2.13.205, поставив то же ядро, что у клиента: 2.6.35-28-generic. До этого у нас стояло 2.6.37.
На eterhack проблема не воспроизводится
В ванильном wine проблема исправлена где-то между wine-1.3.2 и wine-1.3.4.
Перенёс на 1.0.12 следующие патчи: ntdll: Avoid the close-on-exec race with recvmsg() on kernels that support this. server: Make the fd passing code slightly more portable. ntdll: Add support for retrieving the server pid from the socket credentials. ntdll: Add a workaround for Ubuntu's stupid ptrace breakage. У последнего патча довольно говорящее название.
