Bug 1344

речь-то про ALTLinux?
в Fedora все нормально с таким ядром

Речь про ALT Linux, ядро std-def.
Надо развёртывать стенд для тестирования, чтобы каждый был в курсе.

(In reply to comment #1)
> речь-то про ALTLinux?
> в Fedora все нормально с таким ядром
> 

Речь про altlinux, ядра wks-smp-alt1 и std-def.
Если можно, то приложите /proc/config.gz, ну или просто конфиг и версию ядра из 
Fedor'ы.

Created attachment 325 [details]
kernel config fc8 

2.6.24.3-34.fc8

по нашим тестам 1с 77 в альте на новом ядре работает исправно

Опишите пожалуйста, что именно тестировалось,
а то мне кажется вы проверяли Ерёму.

(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, то сообщение об ошибке, далее войти с любого клиента не в монопольном режиме невозможно.

по тестам воспроизводится.

(In reply to comment #8)
> по тестам воспроизводится.
> 

Ребят, ровно месяц на подтверждение наличия баги. Это жутко много времени. 

воспроизвелась давно, написал только вчера, когда разгребал

хм, если специалист будет это править, то сентябрь-октябрь.

(In reply to comment #11)
> хм, если специалист будет это править, то
> сентябрь-октябрь.
> 
с ядром 2.6.25 такая же ситуация. Ребят, необходимость в обновлении дистрибутива у клиента созрела давно. Сейчас всё висит из-за не возможности работы на новых ядрах.

Денис, нужно проверить в релизной сборке.

Протестировал на таких ядрах:
2.6.18-ovz-smp-alt24
2.6.25-std-def-alt9.

Если первым входит с 25го, то все ок.
Если с 18го то 2 клиенту выдается ошибка.

Если я всё правильно помню, то эта задача определяет проблему при взаимодействии 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 из сизифа)

(In reply to comment #15)
> Если я всё правильно помню, то эта задача
> определяет проблему при взаимодействии
> OpenVZ-ядра 2.6.18 из бранча 4.0 и стандартных ядер
> из десктопа на общем NFS каталоге.
> 

На сервере было и обычное ядро (не openvz), результат одинаков.

Долго возилась с настройками всего..
Один слейв на 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() . Позже выложу описание теста.

Наверное нужно привлекать админа в таких случаях для настройки, всё же развернуть NFS - сложная задача. Ну и конечно обращаться к документации по WINE@Etersoft, там должен быть подробно расписан порядок.

Корректировка зависимостей.
Актуальна ли еще проблема? Уже давно вышли новые ядра.

(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 выдается сообщение, указанное в начале тикета:

"Программа была завершена аварийно. Для восстановления индексных файлов
запустите программу в монопольном режиме"

(In reply to comment #20)
> 
> Аналогичная проблема на Ubuntu Hardy LTS 8.04.x
> 
> ядро на NFS-сервере и клиентах штатное,
> 2.6.24.x-generic и 2.6.24.x-server
Ситуация другая, создана отдельная бага 4002.

В 1.0.11 исправлено, в новых ядрах изменилось поведение NFS при установке W-блокировки на открытый только для чтения файл.