Bug 1344

Summary: Не работает 1С 7.7 на ядре 2.6.24 в ALT Linux при подключении через NFS
Product: WINE@Etersoft Reporter: Sergey Lebedev <lebedev.v.sergey>
Component: Сетевые файловые системыAssignee: Денис Баранов <baraka>
Status: CLOSED FIXED QA Contact: Денис Баранов <baraka>
Severity: major    
Priority: P2 CC: baraka, boris, kondratyuk, kostenko.e, lav, lbeasty, sin, vostok
Version: 1.0.8   
Target Milestone: ---   
Hardware: PC   
OS: ALT Linux   
Whiteboard:
Заявки RT: Связано с:
Дата напоминания:
Bug Depends on: 1450, 1553, 2509    
Bug Blocks: 760, 1838, 2305, 3589    
Attachments: kernel config fc8

Description Sergey Lebedev 2008-03-12 12:37:52 MSK
При попытке входа в 1с получаем
"Программа была завершена аварийно
Для восстановления индексных файлов запустите программу в монопольном режиме.

На сервере стоит 2.6.18
по nfs-у раздается база.
К серверу подключается до 10 клиентов с 2.6.18, проблем нет.

Попытка подключения к базе клиента с ядром 2.6.24, получаем такую ошибку
Comment 1 Boris Savelev 2008-03-12 13:45:42 MSK
речь-то про ALTLinux?
в Fedora все нормально с таким ядром
Comment 2 Vitaly Lipatov 2008-03-12 17:37:21 MSK
Речь про ALT Linux, ядро std-def.
Надо развёртывать стенд для тестирования, чтобы каждый был в курсе.
Comment 3 Sergey Lebedev 2008-03-12 18:52:11 MSK
(In reply to comment #1)
> речь-то про ALTLinux?
> в Fedora все нормально с таким ядром
> 

Речь про altlinux, ядра wks-smp-alt1 и std-def.
Если можно, то приложите /proc/config.gz, ну или просто конфиг и версию ядра из 
Fedor'ы.
Comment 4 Boris Savelev 2008-03-18 13:34:50 MSK
Created attachment 325 [details]
kernel config fc8 

2.6.24.3-34.fc8
Comment 5 Boris Savelev 2008-03-25 22:03:08 MSK
по нашим тестам 1с 77 в альте на новом ядре работает исправно
Comment 6 Vitaly Lipatov 2008-03-25 22:08:59 MSK
Опишите пожалуйста, что именно тестировалось,
а то мне кажется вы проверяли Ерёму.
Comment 7 Sergey Lebedev 2008-03-26 01:56:15 MSK
(In reply to comment #6)
> Опишите пожалуйста, что именно
> тестировалось,
> а то мне кажется вы проверяли Ерёму.
> 

Мы ничего не тестировали. Мы успешно настроили систему клиенту. 
Как оно есть.

Далее все системы 32х битные.

Сервер с ALTLinux Server 4.0. обновлённый до последнего среза branch'а. На сервере ядро 2.6.18-std-smp-alt12 (2.6.24-wks-smp-alt2). На сервере nfs-share, на которой лежит файловый 1с77.

Клиенты 10 АРМ, с altlinux desktop 4.0.2. Монтируют удалённый каталог по nfs. На каждом клиенте установлен wine@etersoft 1.0.8. Ядро у клиентов 2.6.18-std-smp-alt10. 1с77 успешно работает на этих машинах.

Клиенты 2 АРМ, материнские платы asus m2n-mx plus (на 18тых ядрах эти платы виснут глухо и надолго). Установлен desktop 4.0.2, обновлён до branch'а недельной давности. При использовании любого ядра 2.6.24-(def/wks) приводит к следующему эффекту:

10 АРМ работают с 1с. Подключаюсь из любой АРМ с новым ядром, запускаю 1с77, меня спрашивают логин и пароль, ввожу, получаю ошибку о повреждённых базах и просьбе зайти в монопольном режиме. После чего на 10 рабочих АРМ 1с отказывается запускаться. Требует зайти в монопольном режиме. Выход всех клиентов, закрытие клиента на сбойном АРМ и запуск 1с в монопольном режиме исправляет ситауцию. Т.е. 10 АРМ могут работать.

Воспроизводимость 100ная.

На сервере пробовали ядро 2.6.24-wks-smp-alt2, проблема остаётся.


Предположительный стенд.
сервер машина с ALT Server 4.0.1 и любым ядром.
клиент с 2.6.18
клиент с 2.6.24
1с по nfs
войти с клиента (2.6.24) в 1с 
войти с клиента (2.6.18) в 1с 

Если первый 2.6.18, то пускает. Если первым пытается войти 2.6.24, то сообщение об ошибке, далее войти с любого клиента не в монопольном режиме невозможно.
Comment 8 Boris Savelev 2008-04-16 20:09:56 MSD
по тестам воспроизводится.
Comment 9 Sergey Lebedev 2008-04-17 02:05:26 MSD
(In reply to comment #8)
> по тестам воспроизводится.
> 

Ребят, ровно месяц на подтверждение наличия баги. Это жутко много времени. 
Comment 10 Boris Savelev 2008-04-17 12:11:21 MSD
воспроизвелась давно, написал только вчера, когда разгребал
Comment 11 Анатолий Лютин 2008-05-21 19:55:24 MSD
хм, если специалист будет это править, то сентябрь-октябрь.
Comment 12 Sergey Lebedev 2008-10-16 16:48:17 MSD
(In reply to comment #11)
> хм, если специалист будет это править, то
> сентябрь-октябрь.
> 
с ядром 2.6.25 такая же ситуация. Ребят, необходимость в обновлении дистрибутива у клиента созрела давно. Сейчас всё висит из-за не возможности работы на новых ядрах.
Comment 13 Константин Кондратюк 2008-10-30 15:34:12 MSK
Денис, нужно проверить в релизной сборке.
Comment 14 Денис Баранов 2008-10-30 19:13:44 MSK
Протестировал на таких ядрах:
2.6.18-ovz-smp-alt24
2.6.25-std-def-alt9.

Если первым входит с 25го, то все ок.
Если с 18го то 2 клиенту выдается ошибка.
Comment 15 Евгений Синельников 2009-02-25 16:40:01 MSK
Если я всё правильно помню, то эта задача определяет проблему при взаимодействии OpenVZ-ядра 2.6.18 из бранча 4.0 и стандартных ядер из десктопа на общем NFS каталоге.

Мне пока непонятно как решить эту проблему. Если она не потеряла актуальности, то нужно пробовать повторить её на тестах. Как должно выглядеть решение мне пока тоже непонятно... Я думаю, что проблема в 18-том ядре (я уже много видел в нём проблем)... В качестве адекватного решения я вижу - бекпорт в ядро кода из более старших версий... Возможно лучше, всё-таки собрать новое OVZ-ядро... Но вот какой версии, ведь нужно, чтобы оно завелось на 4.0...

Повторить у себя проблему с 1С нам пока её не удалось, поскольку мы пробовали на виртуальных машинах (VirtualBox), а в них не работает Wine - виснет на стадии инициализации среды с ошибкой:
ALSA lib seq_hw.c:457:(snd_seq_hw_open) open /dev/snd/seq failed: Нет
такого файла или каталога

Думаю, нужно, для начала прогнать тесты на 2.6.18... Для этого нужно:
1) Вариант 1. собрать rect под бранч 4.0, а лучше статиком, как это давно предлагает Иван.
2) установить старое на новых библиотеках (на тот же бранч 4.1)

В общем сначала нужно выполнить тесты на двух слейвах:
2.6.18 ovz из бранча и новых (2.6.25 из 4.1 и 2.6.27 из сизифа)
Comment 16 Sergey Lebedev 2009-03-10 14:08:12 MSK
(In reply to comment #15)
> Если я всё правильно помню, то эта задача
> определяет проблему при взаимодействии
> OpenVZ-ядра 2.6.18 из бранча 4.0 и стандартных ядер
> из десктопа на общем NFS каталоге.
> 

На сервере было и обычное ядро (не openvz), результат одинаков.
Comment 17 Elena V. Gurevich 2009-03-16 19:01:18 MSK
Долго возилась с настройками всего..
Один слейв на 2.6.18-std-smp-alt12. Второй на 2.6.27-std-def-alt11.
Рект собран статически, версия 0.0.12 alt1. Тесты rect-tests-0.0.7-alt1.
В качестве сервера используется ximinez:/home/lena/public

[lena@ximinez public]$ cat /etc/exports
/home/lena/public *(rw) 

На блокировки прошли все тесты.Хорошо прошли. Кроме одного теста, который использует flush() . Позже выложу описание теста.
Comment 18 Vitaly Lipatov 2009-03-16 20:21:46 MSK
Наверное нужно привлекать админа в таких случаях для настройки, всё же развернуть NFS - сложная задача. Ну и конечно обращаться к документации по WINE@Etersoft, там должен быть подробно расписан порядок.
Comment 19 Денис Баранов 2009-04-22 19:09:12 MSD
Корректировка зависимостей.
Актуальна ли еще проблема? Уже давно вышли новые ядра.
Comment 20 Костенко Евгений 2009-06-03 10:52:47 MSD
(In reply to comment #19)
> Корректировка зависимостей.
> Актуальна ли еще проблема? Уже давно вышли
> новые ядра.
> 

Аналогичная проблема на Ubuntu Hardy LTS 8.04.x

ядро на NFS-сервере и клиентах штатное, 2.6.24.x-generic и 2.6.24.x-server
схема следующая:

- часть клиентов с Thinstation через XDMCP/Windows через NX
- часть клиентов с Ubuntu Hardy 8.04.x через NFS+LDAP

если в базу 7.7 зашли "терминальные" клиенты, то при попытке доступа к базе через NFS выдается сообщение, указанное в начале тикета:

"Программа была завершена аварийно. Для восстановления индексных файлов
запустите программу в монопольном режиме"
Comment 21 Vitaly Lipatov 2009-06-04 23:30:26 MSD
(In reply to comment #20)
> 
> Аналогичная проблема на Ubuntu Hardy LTS 8.04.x
> 
> ядро на NFS-сервере и клиентах штатное,
> 2.6.24.x-generic и 2.6.24.x-server
Ситуация другая, создана отдельная бага 4002.
Comment 22 Vitaly Lipatov 2009-07-30 22:16:24 MSD
В 1.0.11 исправлено, в новых ядрах изменилось поведение NFS при установке W-блокировки на открытый только для чтения файл.