Укажите отработанное время

Отработанное время:
Продуктивное время:
Bug 9444 - Fedora 17x64: при монтировании по cifs 5.4.7 ошибка загрузки метаданных 1с77   Make a simular bug
Summary: Fedora 17x64: при монтировании по cifs 5.4.7 ошибка загрузки метаданных 1с77
Status: CLOSED FIXED
Alias: None
Product: CIFS@Etersoft
Classification: Продукты (Products)
Component: блокировки файлов и доступ (show other bugs)
Version: не указана
Hardware: PC All
: P2 major
Target Milestone: ---
Assignee: Svetlana Zhukova
QA Contact: Svetlana Zhukova
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 3044
  Show dependency treegraph
 
In work:
Reported: 2013-07-23 15:30 MSK by Svetlana Zhukova
Modified: 2013-11-25 11:30 MSK (History)
3 users (show)

See Also:
Заявки RT: 32011
Связано с:
Дата напоминания:


Attachments
diff -uNr sources/3.8 sources/3.9 (35.46 KB, patch)
2013-10-24 13:48 MSK, Pavel Shilovsky
Details | Diff
git log v3.8..v3.9 -- fs/cifs (33.78 KB, application/octet-stream)
2013-10-24 13:43 MSK, Pavel Shilovsky
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Svetlana Zhukova 2013-07-23 15:30:22 MSK
Установлены WINE@Etersoft Network 2.1.2/2.1.0-eter17/3 и etercifs 5.4.7 
Смонтирована шара с БД для 1с77.
При запуске конфигурации 1с77 на fedora - ошибка загрузки метаданных.На windows работает корректно.
Подробности тут:https://bugs.etersoft.ru/show_bug.cgi?id=7100#c58
Также узнать подробности можно у anton@im.etersoft.ru
Comment 1 Svetlana Zhukova 2013-07-23 15:33:23 MSK
Машины в  vbox:
[T]Fedora_17x64 (по техническим причинам в данный момент в группе sql)
[T]Windowx XP Sv
Снимки на обеих "9444"
Comment 2 Pavel Shilovsky 2013-07-29 20:44:25 MSK
Разобрался с проблемой. Сервер по разному реагирует на вызов query path info (unix) при использовании различных протоколов аутентификации. В нашем случае произошёл переход с NTLM на NTLMSSP, что изменило реакцию сервера на данный запрос. Конкретная причина, изменившая поведение сервера при механизме аутентификации NTLMSSP пока не выяснена. Задал вопрос в рассылку cifs.

Для клиента проблему можно решить следующим образом - указать опцию монтирования sec=ntlm или sec=ntlmv2.
Comment 3 Pavel Shilovsky 2013-08-13 09:26:09 MSK
У клиента возникла новая проблема. Необходимо воспроизвести у нас.
Comment 4 Svetlana Zhukova 2013-09-04 11:48:56 MSK
(В ответ на comment #3)
-\\-
> <piastryyy> всё тоже самое только добавляется эта опция  sec=ntlm

Машины те же:
> [T]Fedora_17x64 (по техническим причинам в данный момент в группе sql)
> [T]Windowx XP Sv
> Снимки на обеих "9444"

Строка монтирования:
mount -t cifs //192.168.4.28/sharewine  /mnt/cifs -o user=guest,pass=123,sec=ntlm,nolock


[sharewine]
   path = /var/local/share
   public = yes
   force user = guest
   force group = users
   writable = yes
   guest ok =no
   browseable = yes
#posix locking = false

   create mask = 0775
   create mask = 0664
    directory mask = 0777
    force directory mask = 0777
   case sensitive = no
..
   default case = lower
   preserve case = no
   short preserve case =no


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

p.s. В настройках федоры выставила везде русский язык, потому что без этого стартовое окно запускалось с ?????? вместо текста и конфигурация не загружалась с ошибкой,которую нельзя было прочесть.

На обеих машинах снимки 9444-1
Comment 5 Svetlana Zhukova 2013-09-04 12:24:37 MSK
при строке монтирования 
mount -t cifs //192.168.4.28/sharewine  /mnt/cifs -o
user=guest,pass=123,sec=ntlm

Всегда под windows в 1с входит пользователь "Новый2",под Федорой "Новый1".

Если сначала запустить конфигурацию  на Федоре, а потом на windows,то работа 1с корректна.
Далее если на федоре 1с закрыть и попытаться запустить заново, то появится ошибка "программа была завершена аварийно, запустите в монопольном режиме", но при запуске в монопольном режиме возникает "ошибка блокировки данных, возможно данные используются другой задачей "

Закрываю 1с на windows.Запускаю на федоре монопольно - работает.
Запускаю на windows - ошибка блокировки данных.

Воспроизводится.
снимки 9444-2
Comment 6 Svetlana Zhukova 2013-09-04 12:35:56 MSK
если просто дописать опцию wine,то 1с  на федоре не запускается совсем   с ошибкой метаданных, и в монопольном режиме. На windows запускается корректно.
Пересоздала базу - не помогло.
Comment 7 Svetlana Zhukova 2013-09-06 13:13:24 MSK
Опции монтирования клиента:
mountopts="-fstype=cifs,sec=ntlm,rw,wine,noperm,nounix,nostrictsync,uid=
${username},gid=502"
Comment 8 Svetlana Zhukova 2013-09-09 12:45:13 MSK
 mount -t cifs //192.168.4.28/sharewine  /mnt/cifs  -o sec=ntlm,rw,wine,noperm,nounix,nostrictsync,gid=502,user=guest,password=123

при и спользовании опции wine все же "ошибка загрузки метаданных" на fedora.
Comment 9 Svetlana Zhukova 2013-09-09 14:17:38 MSK
(В ответ на comment #8)
>  mount -t cifs //192.168.4.28/sharewine  /mnt/cifs  -o
> sec=ntlm,rw,wine,noperm,nounix,nostrictsync,user=guest,password=123
>  при и спользовании опции wine все же "ошибка загрузки метаданных" на fedora.

В режиме конфигуратора загружается с обеих систем как положено (блокировки работают корректно). На windows конфигурация запускается корректно, на федоре - ошибка мета данных, причем не зависимо от опций. Подключла данную базу локально - запускается корректно.
Comment 10 Svetlana Zhukova 2013-09-23 13:49:23 MSK
 При  монтировании по cifs,как и ранее, (попробовала также etermount) возникает ошибка загрузки метаданных.

  Попробовала по nfs простой командой: 
mount   //192.168.4.28/sharewine  /mnt/cifs -o user=guest,pass=123


#mount
//192.168.4.28/sharewine on /mnt/cifs type cifs (rw,nosuid,nodev,noexec,relatime,vers=1.0,sec=ntlmssp,cache=strict,unc=\\192.168.4.28\sharewine,username=guest,domain=LOCALHOST,uid=0,noforceuid,gid=0,noforcegid,addr=192.168.4.28,unix,posixpaths,serverino,acl,rsize=1048576,wsize=65536,actimeo=1)

ошибки не возникает.

попробовала с параметрами:
#  mount -t cifs //192.168.4.28/sharewine /mnt/cifs -onoperm,rw,username=guest,domain=LOCALHOST,sec=ntlm

ошибки не возникает. 

Добавление параметра "wine" к последнему варианту  возобновляет ошибку.
Comment 11 Svetlana Zhukova 2013-09-23 15:30:54 MSK
На более раннем ядре  - 3.8.13-100.fc17.x86_64 +  etercifs-5.4.7-eter1fedora.noarch - аналогично.

На ядре 3.8 + etercifs-5.4.4-eter1fedora.noarch.rpm - аналогично.
Comment 12 Svetlana Zhukova 2013-09-23 15:53:19 MSK
убраны параметры:
case sensitive = no
oplocks = no
short preserve case =no

 mount -t cifs //192.168.4.28/sharewine  /mnt/cifs -o user=guest,pass=123,sec=ntlm,wine

ошибки нет.

но при этом подключаюсь под пользователем новый1 одновременно и с windows и с fedora. Причем этот активный пользователь виден дважды.
Comment 13 Svetlana Zhukova 2013-09-23 16:07:06 MSK
(В ответ на comment #12)

> но при этом подключаюсь под пользователем новый1 одновременно и с windows и
> с fedora. Причем этот активный пользователь виден дважды.
Не зависимо от очередности систем.
Ошибка блокировки данных,как и положено,возникает только в случае запуска 1с из-под конфигуратора.
Comment 14 Pavel Shilovsky 2013-09-23 16:48:40 MSK
Разбирались со Светой с воспроизведением проблемы.
Comment 15 Svetlana Zhukova 2013-09-24 11:41:09 MSK
Пересоздала базу.
выполнила setwineshare
права на базу guest:users

1.Windows-windows
Подключаюсь с 2х машин   windows под одним пользователем к базе под одним и тем же пользователем Новый 1,редактирую один и тот же документ одновременно,недоступна только запись,редактируемая в данный момент на другом клиенте(например,выбор сотрудника в первой строке списка "операции-журнал документов-авансовые отчеты").
Попробовала на 2х базах: 1SBdemoNEW и Test_base.

Подключаюсь под разными пользователями: - аналогично.

Конфигуратор можно запустить только под одним пользователем, при запуске второй копии - ошибка блокировки метаданных (как и положено).

2.windows-linux
строка монтирования:
mount -t cifs //192.168.4.28/sharewine  /mnt/cifs -o user=guest,pass=123,sec=ntlm,wine

  а) Сначала запускаю 1с на linux , затем на windows под одним и тем же пользователем - ситуация аналогичная  windows.
  б) Сначала windows потом linux - аналогично.

3.linux-linux (fedora - [svzhu]Altlinux6) 
etercifs-5.4.4-alt0.M60P.1

при запуске с Altlinux6  смонтированной конфигурации получаю первым делом ошибку:
err:winediag:FILE_CreateFile failed to open L"\\??\\L:\\dir\\1SBDemoNEW\\1Cv7.LCK" because of insufficient access rights
хотя права выставлены корректно, и такой файл не существует.  
Создала его вручную,конфигурация запустилась.
Ситуация аналогичная windows.
Comment 16 Svetlana Zhukova 2013-09-24 14:19:02 MSK
в случае,когда бд находится на windows,с обеих машин windows также вхожу под одним и тем же пользователем.
Comment 17 Svetlana Zhukova 2013-10-02 15:05:38 MSK
Посмотрела как обстоят дела в бутылках  - 1с77  и 1c82  - везде (одна из конфигураций - торговля и склад,к примеру ) можно под одним и тем же пользователем войти несколько раз и редактировать один документ. Но если войти под разными пользователями в одну и ту же базу, то документ редактировать одновременно нельзя - блокировки работают корректно.
eter-2.1
1c77/1c77
1c82/1c82
WINE@Etersoft SQL 2.1.3/2.1.0-eter5/3
Comment 18 Pavel Shilovsky 2013-10-24 10:09:13 MSK
Обсудили со Светой дальнейший план действий. Конфигурация ядро 3.8 + этерцифс 5.4.4 согласно тестированию признана рабочей, что совпадает с тем, что описывает клиент. Далее тестирование необходимо провести в два шага:
1) обновить этерцифс до версии 5.4.7, проверить;
2) обновить ядро до версии 3.9, проверить.
Comment 19 Svetlana Zhukova 2013-10-24 11:22:47 MSK
>теперь надо проверить связки
>3.8 + 5.4.7
>3.9 + 5.4.7

1)  3.8 + 5.4.7

 [T]Fedora_17x64 
 [T]Windowx XP Sv

Уснатовила cifs 5.4.7.

 mount -t cifs //192.168.4.28/sharewine  /mnt/cifs -o user=guest,pass=123,sec=ntlm,wine

1с77 запускается без ошибок на обеих системах, не зависимо от очередности запуска  (также одновременное редактирование одного документа из разных мест недоступно.
Снимок на fedora "3.8+547"

2)3.9 + 5.4.7
В последовательности:
fedora-windows - запускается корректно
windows-fedora - не запускается: "ошибка при запуске журнала регистрации".
Снимок на fedora "3.9 + 5.4.7"
Comment 20 Svetlana Zhukova 2013-10-24 11:26:18 MSK
(В ответ на comment #19)
 default case = lower
  preserve case = yes
Comment 21 Pavel Shilovsky 2013-10-24 13:17:43 MSK
(В ответ на comment #19)
> >теперь надо проверить связки
> >3.8 + 5.4.7
> >3.9 + 5.4.7
> 
> 1)  3.8 + 5.4.7
> 
>  [T]Fedora_17x64 
>  [T]Windowx XP Sv
> 
> Уснатовила cifs 5.4.7.
> 
>  mount -t cifs //192.168.4.28/sharewine  /mnt/cifs -o
> user=guest,pass=123,sec=ntlm,wine
> 
> 1с77 запускается без ошибок на обеих системах, не зависимо от очередности
> запуска  (также одновременное редактирование одного документа из разных мест
> недоступно.
> Снимок на fedora "3.8+547"
> 
> 2)3.9 + 5.4.7
> В последовательности:
> fedora-windows - запускается корректно
> windows-fedora - не запускается: "ошибка при запуске журнала регистрации".
> Снимок на fedora "3.9 + 5.4.7"

Таким образом, проблема возникает при переходе с ядра 3.8 и 3.9 на последнем акутальном etercifs-5.4.7. Начал изучать diff между ядрами.
Comment 22 Pavel Shilovsky 2013-10-24 13:41:29 MSK
Created attachment 2993 [details]
diff -uNr sources/3.8 sources/3.9
Comment 23 Pavel Shilovsky 2013-10-24 13:43:01 MSK
Created attachment 2994 [details]
git log v3.8..v3.9 -- fs/cifs
Comment 24 Pavel Shilovsky 2013-10-24 13:53:46 MSK
Продолжил изучать diff. Добавил diff и список коммитов в багу.
Comment 25 Pavel Shilovsky 2013-11-10 17:09:22 MSK
Обнаружил, что в ядре 3.9 ошибка STATUS_SHARING_VIOLATION транслируется в EBUSY, в то время как раньше было ETXTBSY. WINE транслирует EBUSY в STATUS_FILE_LOCK_CONFLICT, а ETXTBSY - STATUS_SHARING_VIOLATION.

Исправил обратно в ядрах 3.9 и 3.11 и собрал в etercifs-5.4.8. Надо протестировать данную сборку.
Comment 26 Vitaly Lipatov 2013-11-10 18:03:41 MSK
(В ответ на comment #25)
> Обнаружил, что в ядре 3.9 ошибка STATUS_SHARING_VIOLATION транслируется в
> EBUSY, в то время как раньше было ETXTBSY. WINE транслирует EBUSY в
> STATUS_FILE_LOCK_CONFLICT, а ETXTBSY - STATUS_SHARING_VIOLATION.

Я так понял, что обсуждение изменения было здесь:
http://www.spinics.net/lists/linux-cifs/msg07798.html

А, в wine два варианта в sharing violation превращается:
    case ETXTBSY:
    case EAGAIN: set_error( STATUS_SHARING_VIOLATION ); break;

Так нужно что-то решить глобально. Они молодцы, легко так исправили CIFS, чтобы всё сломалось.

А неужели RECT не позволял выявить эту проблему?
Мне не очень нравится что 20 часов по баге потрачено на поиск такого изменения кода.

А неужели нельзя было протестировать с помощью winelocktest?

2svzhu:
Если на какой-то системе появляется проблема, надо тестировать
1. у нас
если проблема воспроизводится,
1. тестировать на предыдущей версии системы (ядра, программы)

Нужно по возможности частную проблему клиента превратить в общее, не зависящее от дистрибутива клиента, и довести до конкретных версий.

Я не понимаю, почему при воспроизведении проблемы полностью проигнорированы наши средства по тестированию файловых систем.
Comment 27 Pavel Shilovsky 2013-11-12 13:08:24 MSK
(В ответ на comment #26)
> Я так понял, что обсуждение изменения было здесь:
> http://www.spinics.net/lists/linux-cifs/msg07798.html
> 
> А, в wine два варианта в sharing violation превращается:
>     case ETXTBSY:
>     case EAGAIN: set_error( STATUS_SHARING_VIOLATION ); break;
> 
> Так нужно что-то решить глобально. Они молодцы, легко так исправили CIFS,
> чтобы всё сломалось.

В etercifs мы можем продолжать подменять, пока не станет ясно что-то со статусом флагов доступа в ядре, так как в случае принятие наших патчей для sharing violation будет отдельный новый код ошибки.

> А неужели RECT не позволял выявить эту проблему?

RECT не проверяет код возврата, он лишь проверяет была ошибка или нет.

> Мне не очень нравится что 20 часов по баге потрачено на поиск такого
> изменения кода.

Из данных 20 часов половина времени была потрачена на обнаружение другой проблемы, появившейся в ядре 3.8 с переходом на новый механизм аутентификации по умолчанию. Другая половина потрачена на воспроизведение и локализацию второй проблемы с кодом ошибки.

Данная бага посвящена проблеме у конкретного клиента. При выделении новой задачи, нужно создавать новую багу, чтобы не мешать всё в одно и не усложнять потом поиск истоков.
Comment 28 Svetlana Zhukova 2013-11-13 09:25:43 MSK
(В ответ на comment #25)
> Обнаружил, что в ядре 3.9 ошибка STATUS_SHARING_VIOLATION транслируется в
> EBUSY, в то время как раньше было ETXTBSY. WINE транслирует EBUSY в
> STATUS_FILE_LOCK_CONFLICT, а ETXTBSY - STATUS_SHARING_VIOLATION.
> 
> Исправил обратно в ядрах 3.9 и 3.11 и собрал в etercifs-5.4.8. Надо
> протестировать данную сборку.

Ядро 3.9.10-100.fc17.x86_64
etercifs-5.4.4-eter1fedora.noarch.rpm

При выполнении build:
make[1]: *** [/tmp/Etercifs.sxVxHBGp/kernel-source-etercifs-3.7-2.0/inode.o] Error 1
make: *** [_module_/tmp/Etercifs.sxVxHBGp/kernel-source-etercifs-3.7-2.0] Error 2
make: Leaving directory `/usr/src/kernels/3.9.10-100.fc17.x86_64'
can't locate built module etercifs.ko

CIFS kernel module status:
    WARNING!!! Kernel module etercifs is not loaded!
Comment 29 Svetlana Zhukova 2013-11-13 09:42:04 MSK
(В ответ на comment #28)

> Ядро 3.9.10-100.fc17.x86_64
> etercifs-5.4.4-eter1fedora.noarch.rpm
> CIFS kernel module status:
>     WARNING!!! Kernel module etercifs is not loaded!

В тестинг оказалась старая версия cifs. 
etercifs 5.4.8-eter1fedora - устанавливается корректно.
Ядро 3.9.10-100.fc17.x86_64

Программа работает корректно, не зависимо от очередности запуска windows-linux,ошибок нет, блокировки работают.
Comment 31 Svetlana Zhukova 2013-11-25 11:30:01 MSK
Закрываю.