Воспроизводится на cellar, бутылка 1c77/1c77-27
База называется CIFS_print

<wine@cellar bottle 1c77/1c77-27>$ rpm -qa|grep wine
wine-etersoft-1.0.11-alt8.5
wine-etersoft-gl-1.0.11-alt8.5
wine-etersoft-sql-1.0.11-alt5

<wine@cellar bottle 1c77/1c77-27>$ rpm -qa|grep etercifs
etercifs-4.3.8-alt5

Как 1С-ник рискну предположить, что бага проявляется/не проявляется в зависимости от:
1) Монопольно-не монопольно (маловероятно)
2) Печатная форма идёт в составе конфигурации/идёт в качестве внешней печатной формы (каталог ExtForms/PrnForms)
а по существу это всё та-же старая бага из-за которой как я понял к вам так и не пришла пара клиентов.

Могу даже уточнить- проявляется только в разделенном режиме и только через cifs. А также влияет на клиентов windows 98\me - в лог базы при обращении к заблокированному документу валится сообщение вида 
[2009/10/09 12:44:37,  0] smbd/blocking.c:push_blocking_lock_request(170)
push_blocking_lock_request: cannot queue a chained request (currently).
и через какое-то время 1с, а потом и комп намертво зависают на случайной операции, время зависания прямо пропорционально объему работы на этом компе. На XP такой ситуации не возникает- клиенты работают быстро, 1с не виснет, в лог samba сообщения не сыпятся, но документы все равно заблокированы. Документ разблокируется сразу же после того, как выходит пользователь, который его печатал. Если выгнать всех пользователей под wine и снова нустить- до первой печати под wine все работает нормально. Печатные формы и внешние и внутренние.
Для повторения ошибки надо зайти в базу с windows и linux, в linux открыть любой документ с печатной формой, открыть форму, обязательно послать на печать, а не просто закрыть окно. После этого документ заблокирован и под windows и под linux. В ситуации напрягает больше всего именно зависание windows me. C блокировкой документов не все так страшно. Такое чувство что windows me как-то по другому с блокировками работает. На днях попробую откатиться на более старую версию samba чтобы исключить ее из списка подозреваемых.

Created attachment 1337 [details]
Небольшая программа, воспроизводящая проблему

Проблема не воспроизводится с новым etercifs с патчами от Синельникова.

Монтировать при этом надо с noperm,forcemand,direct.
Настройки те же, что приведены в баге 4346.

Очень интересно! А где этот новый cifs с патчами взять можно? А то какбэ в понедельник надо гендиру решение выдавать.

(In reply to comment #8)
> Очень интересно! А где этот новый cifs с
> патчами взять можно? А то какбэ в
> понедельник надо гендиру решение выдавать.
> 

Так, давайте определимся с версией ядра. Нам тоже будет полезно, если вы проверите сборку нового etercifs.

Осталось только мне уточнить какой конкретно вариант патчей имеется в виду... ;)

PS: вышлите мне на почту (лично) разницу между текущим вариантом и рабочим или свяжитесь иначе на счёт патчей.

(In reply to comment #8)
> Так, давайте определимся с версией ядра.
>

В принципе подойдет любое из стандартного набора mandriva 2009.1
kernel-server-2.6.29.1-4mnb-1-1mnb2
kernel-server-2.6.29.3-1mnb-1-1mnb2
kernel-server-2.6.29.6-1mnb-1-1mnb2
kernel-server-2.6.29.6-2mnb-1-1mnb2
все они отлично поддаются тюнингу без пересборки(во всяком случае у меня))

> Нам тоже будет полезно, если вы проверите
> сборку нового etercifs.
>   

Я только за!

> Осталось только мне уточнить какой
> конкретно вариант патчей имеется в виду... ;)
>   

Вот тут я в тупике... Видимо не понял вопроса- что значит какой вариант?
У нас есть проблема с блокировкой документов после печати, Александр Морозов сказал что "Проблема не воспроизводится с новым etercifs с патчами от Синельникова." вот их бы и хотелось пощупать))


> PS: вышлите мне на почту (лично) разницу
> между текущим вариантом и рабочим или
> свяжитесь иначе на счёт патчей.
>

Да не вопрос!  Вот только что еще я сейчас могу сообщить? На данный момент стоит
[root@terminal sysadmin]# rpm -qa|grep wine
wine-etersoft-network-1.0.11-eter3mdv
wine-etersoft-1.0.11-eter8mdv
wine-etersoft-twain-1.0.11-eter8mdv
wine-etersoft-gl-1.0.11-eter8mdv
[root@terminal sysadmin]# rpm -qa|grep etercifs
dkms-etercifs-4.3.8-eter1mdv
etercifs-4.3.8-eter5mdv
испытывал также Network-1.0.10 (блокировки не работают вообще- одновременный вход windows и linux пользователей рушит индексы) и Network-testing (Разница с Network-1.0.11 только в некорректной работе переиндексации- ругается на разрушенный dbf сейчас уже не вспомню как, но если нужно-воспроизведу, при том что база точно рабочая) и во всех трех блокируется документ и зависают windows me. Если вы мне сообщите что конкретно нужно сообщить- я сообщу.

(In reply to comment #10)

Ответил лично - я тоже предпочитаю форумам рассылки ;)

Жаль, что багзила не умеет то, что умеет googlegroups.

В общем, вопросы адресованы Саше...

Отмечу, что нам, для тестов, можно проверить и без полного переезда патча на все ядра. Я могу сделать отдельный тестовый вариант для 2.6.29.

> Осталось только мне уточнить какой
> конкретно вариант патчей имеется в виду... ;)

Имеется в виду тот модуль, который ты собирал на atlant.

Я могу надеяться что тест будет в понедельник к обеду? Просто после обеда возможность проверить будет только на следующий день, бухи у нас трудолюбивые)))

Я не хочу показаться назойливым- но что-то надо делать... Дайте cifs поносить, мне начальству надо работу показать((

Я выслал (In reply to comment #14)
> Я не хочу показаться назойливым- но что-то
> надо делать... Дайте cifs поносить, мне
> начальству надо работу показать((
> 

Прошу прощения, я выслал вам на почту, вариант для 2.6.29 - давайте пробовать.

> Для проверки новой версии драйвера высылаю 
> вам файл для 2.6.29, который нужно скопировать в каталог: 
> /usr/share/etercifs/sources 
> заменив текущий. 
> Далее его нужно пересобрать: 
> # service etercifs build 
> и перезагрузить 
> # service etercifs restart 
> как обычно... 
> PS: Сборку для 2.6.29 я не проверял, но собираться модуль должен... 

Спасибо! Документы больше не блокируются. Пока вроде глюков других нет, 
только небольшая поправка- после копирования исходника модуля еще надо 
было сделать dkms remove -m etercifs -v 4.3.8 --all , а то хитрый dkms 
видел старый скомпиленный модуль и радостно отказывался по второму разу 
напрягаться, просто использовал ранее собраный))

> Спасибо! Документы больше не блокируются. Пока вроде глюков других нет, 
> только небольшая поправка- после копирования исходника модуля еще надо 
> было сделать dkms remove -m etercifs -v 4.3.8 --all , а то хитрый dkms 
> видел старый скомпиленый модуль и радостно отказывался по второму разу 
> напрягаться, просто использовал ранее собраный))

Как выяснилось- глюки есть. Хотя и не такие мощные... После печати документ разблокируется сразу же- то есть с момента отправки на печать сразу же все могут зайти в этот документ, при том что сам печатавший все еще не вышел. Я пытался выяснить последствия, но пока вроде все более-менее корректно работает- после проведения любым из двух зашедших в документ сохраняется последнее изменение целиком. Еще периодически теряются из монитора пользователи, работающие из-под wine , видимо после печати их отрубает, но не с первого раза.

(In reply to comment #17)
> Как выяснилось- глюки есть.
[...]

В новом wine (начиная с версии 1.0.10) есть дополнительные ограничения на логику блокировок - более близкую к NT и не соответствующую POSIX.
Попробуйте выставить, в smb.conf, для шары с базой опцию:
posix locking = false

(In reply to comment #18)

> Попробуйте выставить, в smb.conf, для шары с
> базой опцию:
> posix locking = false
> 

Параметр не помог,пользователи под wine по прежнему выпадают из монитора. Но я выяснил что при установке blocking locks = no пропадают сообщения в логе samba 
[2009/10/15 10:46:01,  0] smbd/blocking.c:push_blocking_lock_request(170)
  push_blocking_lock_request: cannot queue a chained request (currently).
хотя машины под 9x по прежнему виснут(( Сейчас мы переводим на xp особо активных зависателей, потом докупим нормальные машины тем, кто сейчас xp не тянет, тогда можно будет судить- кто виноват и что делать... Но ситуация нифига не красиво выглядит... Кто-нибудь может сказать- чем так 9x отличается от xp в плане работы с 1с? Ведь изначально 1с писалась под 9x и не думаю что при шаре на wondows такой глюк имел бы место... Я могу точно воспроизвести ситуацию с появлением этого сообщения- надо с двух компов зайти в 1с, на одном зайти в любой документ, а на машине с 9x в обработке документов перепровести группу документов, в которую точно входит тот, в который зашли с другого компа. Когда 1с вывалит мессагу о том что документ занят- в лог сваливаются вышеуказанные строчки, и со временем машина с 9x подвисает. Под xp этого нет. И еще есть вопрос- winelog почему- то не хочет запускать пользователей в разделенном режиме. Хотел собрать логи по пользователям под wine в момент выпадания из монитора, но так как все прописаны через административную установку и в режиме rootless запускают один и тот же скрипт- удобнее всего было всех в этом скрипте переключить на winelog, а потом спокойно сверить логи. Может есть какая-нибудь особенность неявная? Запуск 1с происходит строкой #env WINEPREFIX="$HOME/.wine" wine "C:\\Program Files\\1Cv77\\BIN\\1cv7.exe" enterprise.
Извините за сумбурность, если что))
Спасибо что возитесь со мной))

(In reply to comment #19)
> (In reply to comment #18)
> 
> > Попробуйте выставить, в smb.conf, для шары с
> > базой опцию:
> > posix locking = false
> > 
> 
> Параметр не помог,пользователи под wine по
> прежнему выпадают из монитора. Но я выяснил
> что при установке blocking locks = no пропадают
> сообщения в логе samba 
> [2009/10/15 10:46:01,  0] smbd/blocking.c:push_blocking_lock_request(170)
>   push_blocking_lock_request: cannot queue a chained request (currently).

Так. То есть как пропадают? Вы разве уже сообщали про них? :)

Итого возникает вопрос, когда они возникают? Всегда ли это, в вашем случае, сопровождается проблемами?

> хотя машины под 9x по прежнему виснут((
> Сейчас мы переводим на xp особо активных
> зависателей, потом докупим нормальные
> машины тем, кто сейчас xp не тянет, тогда
> можно будет судить- кто виноват и что
> делать... Но ситуация нифига не красиво
> выглядит... Кто-нибудь может сказать- чем
> так 9x отличается от xp в плане работы с 1с?

Конечно, это две совершенно различные системы. XP - это развитие ветки NT, которая появилась ещё до выпуска поделий серии 9x...

В 9x очень много кривых архитектурных решений, реализация драйвера CIFS тоже другая, так что ничего удивительного...

> Ведь изначально 1с писалась под 9x и не думаю
> что при шаре на wondows такой глюк имел бы
> место... Я могу точно воспроизвести

Да, но у них, для этого могут быть и свои костыли...

> ситуацию с появлением этого сообщения-
> надо с двух компов зайти в 1с, на одном зайти
> в любой документ, а на машине с 9x в
> обработке документов перепровести группу
> документов, в которую точно входит тот, в
> который зашли с другого компа. Когда 1с
> вывалит мессагу о том что документ занят- в
> лог сваливаются вышеуказанные строчки, и
> со временем машина с 9x подвисает. Под xp

Таким образом без 9x всё работает... Правильно?

> этого нет. И еще есть вопрос- winelog почему- то
> не хочет запускать пользователей в
> разделенном режиме. Хотел собрать логи по
> пользователям под wine в момент выпадания из
> монитора, но так как все прописаны через
> административную установку и в режиме rootless
> запускают один и тот же скрипт- удобнее
> всего было всех в этом скрипте переключить
> на winelog, а потом спокойно сверить логи.
> Может есть какая-нибудь особенность
> неявная? Запуск 1с происходит строкой #env
> WINEPREFIX="$HOME/.wine" wine "C:\\Program Files\\1Cv77\\BIN\\1cv7.exe"
> enterprise.

Если проблема только в 9x, то  предлагаю создать новую, более чётко сформулировать проблему и решать её уже отдельно от текущей...

PS: от себя могу добавить, что поддержка 9x - это задача, которая себя может не оправдать, но нужно разобраться в чём проблема...

> Так. То есть как пропадают? Вы разве уже
> сообщали про них? :)
> 
Сообщал- в четвертом комментарии

> Итого возникает вопрос, когда они
> возникают? Всегда ли это, в вашем случае,
> сопровождается проблемами?
> 
Четко различить сложно, проверить работу без 9x очень проблематично- самые активные под 9x работают, а в "лабораторных условиях" воспроизвести такую нагрузку не получается, но в процессе перенос всех на xp, так что как закончу- будет ясно. Количество сообщений 
[2009/10/15 10:46:01, 0] smbd/blocking.c:push_blocking_lock_request(170)
> push_blocking_lock_request: cannot queue a chained request (currently).
прямо влияет на зависание: чем больше сообщений- тем быстрее повиснет комп. А как их спровоцировать я уже писал.

> В 9x очень много кривых архитектурных
> решений, реализация драйвера CIFS тоже
> другая, так что ничего удивительного...
> 
Вот я и пытаюсь этот хаос как-то упорядочить)) Развел его не я, а предшественники, но разгребать все равно мне))

> Таким образом без 9x всё работает...
> Правильно?
> 
Не совсем- пользователи под wine все равно из монитора вываливаются. Даже если взять двоих под wine вдвоем в базе- периодически возникает ситуация когда в мониторе одного два пользователя, а второй видит только себя. Причины выяснить не удалось- самому получилось повторить только два раза и притом каждый раз делалось много разнообразных операций- проведение,печать,записи в справочник, обработка с перепроведением, просто висение без дела и т.д.

> PS: от себя могу добавить, что поддержка 9x -
> это задача, которая себя может не
> оправдать, но нужно разобраться в чём
> проблема...
> 
Тут я согласен- скорее всего не оправдает)) Но в ближайшую неделю от 9x не избавиться, а начальство нервничает.Как повторить появление сообщений в логах я описывал, могу еще какие-нибудь тесты провести, если скажете что и как. Сейчас вышла новая samba в релиз- вечером попробую ее поставить и проверить. Вполне возможно что в самой samba что-то поломали, посчитав что 9x уже вымерло))

по мотивам заявки №11936:

"Воспроизведение путём создания документа, печати любой
печатной формы НЕ НАХОДЯЩЕЙСЯ в составе конфигурации, закрытие
документа"

прошу воспроизвести у нас и исправить

Проверять надо на W@E 1.0.12 и etercifs 4.4.2
Мне недавно жаловались на эту проблему.

> "Воспроизведение путём создания документа,
> печати любой
> печатной формы НЕ НАХОДЯЩЕЙСЯ в составе
> конфигурации, закрытие
> документа"

Как создать форму, не находящуюся в составе конфигурации?

(In reply to comment #24)
> Как создать форму, не находящуюся в составе
> конфигурации?

например создать из другой конфигурации

Мгм. На самом деле в составе конфигураций до фига печатных форм внешних. 
Например (берём бухгалтерию) Сервис->Регистрация внешних печатных форм, смотрим документ счет-фактура выданный, видим что есть внешняя печатная форма Счф2003, значит, с этой печатной формой ошибка воспроизведётся, т.е. берём счф выданную и печатаем счф2003 года. (ессно, когда каталог БД лежит на серваке, локально не знаю).

С уважением,
ЛЭПКОС.

Попробовал воспроизвести с базой, лежащей в /mnt/cifs123/amorozov/1SBDB вот таким образом:
Сервис -> Регистрация внешних печатных форм -> Счет-фактура выданный, нажимаем Открыть, в появившемся окне щёлкаем на кнопке с многоточием, затем дважды щёлкаем на первом пункте в списке, нажимаем Печать, затем Ctrl-P, печатаем.
Из двух 1С-ок на разных машинах, работающих с базой по cifs, можно печатать.
То ли я сделал, что требовалось?

Created attachment 1471 [details]
Две 1С в одной базе

Раз уж открыли снова баг- и мои пять копеек. У нас после печати раблокируются документы полностью- то есть зашел человек в док(для остальных заблокирован), поковырялся, поизменял(для остальных все еще заблокирован), нажал напечатать, еще поковырялся(для остальных документ уже не заблокирован). Со временем пользователи под wine вываливаются из монитора, а также периодически вылетают с ошибкой, какой счас не скажу, но могу позже написать.

(In reply to comment #27)
> Попробовал воспроизвести с базой, лежащей
> в /mnt/cifs123/amorozov/1SBDB вот таким образом:
> Сервис -> Регистрация внешних печатных форм
> -> Счет-фактура выданный, нажимаем Открыть,
> в появившемся окне щёлкаем на кнопке с
> многоточием, затем дважды щёлкаем на
> первом пункте в списке, нажимаем Печать,
> затем Ctrl-P, печатаем.
> Из двух 1С-ок на разных машинах, работающих
> с базой по cifs, можно печатать.
> То ли я сделал, что требовалось?
> 

Нет. совсем не так.

Пример (воспроизводится на /lib/modules/2.6.18-6-686/kernel/fs/cifs/etercifs.ko,  ver 4.3.8, параметры монтирования: uid=&,iocharset=utf8,serverino,forcemand,direct, параметры сервера высылали неоднократно)

1) Открываем любой документ, имеющий внешнюю печатную форму (см. выше, например Счф выданный)
2) Выводим печатную форму. (в данном примере СчФ2003)
3) Отправляем печатную форму на печать.
4) Закрываем печатную форму.
5) Закрываем документ.
6) Пытаемся открыть документ снова - он заблокирован.

Хочу заметить, что проиведённый порядок действий, как практика показывает, самый естественный для пользователей, когда они печатают документы именно в таком порядке они и действуют.

Пункты меню Сервис-бла-бла были приведены просто в качестве подсказки, как определить на каких печатных формах документа будет вылет.

Исходя из постоянно приводимых примеров нерабочести следующей версии цифса (в частности, в этой ветке) пожалуй воспользоваться рекомендацией обновить цифс до 4.4.2 не сможем-с, по крайней мере до тех пор, пока она не будет поддерживать нормальную блокировку доков.:))

> 1) Открываем любой документ, имеющий
> внешнюю печатную форму (см. выше, например
> Счф выданный)
> 2) Выводим печатную форму. (в данном примере
> СчФ2003)
> 3) Отправляем печатную форму на печать.
> 4) Закрываем печатную форму.
> 5) Закрываем документ.
> 6) Пытаемся открыть документ снова - он
> заблокирован.

А при такой последовательности действий ошибка должна воспроизводиться?
Операции -> Журналы документов... -> Счета-фактуры выданные, дважды щёлкнуть на первом пункте в списке -> Печать -> Ctrl-P, закрываем все окна, повторяем снова.

2 Alexey: приведённый выше способ воспроизведения ошибки правильный?

Смотря какая печатная форма стоит повешенная на кнопку печать по умолчанию. Обычно там стоит не внешняя печатная форма, если пользователем не было переопределено. Соответственно если говорить про счет фактуры у меня к вам будет вопрос: какую печатную форму вы используете в качестве печатной формы по умолчанию? Встроенную или внешнюю? Метод проверки я описывал выше.:))

Created attachment 1492 [details]
Внешние печатные формы

С настройками на скриншоте выше проблема должна быть?

Если на кнопке у вас написано просто "печать", то тогда нет, не должна быть.
Я же вам описал последовательность, стабильно воспроизводящую ошибку, зачем изобретать велосипед?

> Если на кнопке у вас написано просто
> "печать", то тогда нет, не должна быть.
То есть с настройками как у меня на скриншоте чтобы напечатать я должен нажать стрелку вниз рядом с кнопкой "Печать" и выбрать "Т-1 (Поставновление N26) 2001"?

Угу.Как я понимаю. После чего кнопочка изменит своё название с Печать на Т-1..., и соответственно будет воспроизводиться как я понимаю уже без нажатия на стрелочку.
Алгоритм 100% попадания приведён выше.

Попробовал воспроизвести. Проблем с открытием документа после печати его другим клиентом не возникло.

Сервер: cellar (2.6.27-ovz-smp-alt9), samba-3.0.33-alt4
smb.conf:
[global]
   dos charset = CP866
   unix charset = koi8-r
   display charset = LOCALE
   workgroup = ETERSOFT
   netbios name = cellar
   server string =  Samba server on %h (v. %v)
   lock spin time = 0
   log file = /var/log/samba/log.%m
   log level = 0
   hosts allow = 192.168.0. 127.
   guest account = wine
   security = share
   encrypt passwords = yes
   smb passwd file = /etc/samba/smbpasswd
   socket options = TCP_NODELAY
   use sendfile = yes
   strict locking = no
[sharewine]
   path = /var/local/share
   public = yes
   force user = wine
   force group = winetester
   writable = yes
   guest ok = yes
   posix locking = false

Клиенты: atlant (AltLinux с ядром 2.6.30-std-def-alt15), debian(Debian 5.0.3 с ядром 2.6.26-2-686), etercifs-4.4.2
Монтировал командой
etermount //cellar/sharewine /mnt/cifs
etercifs.conf:
DATADIR=/usr/share/etercifs
SRC_DIR=/usr/src/etercifs-4.4.2
MODULENAME=etercifs
MODULEVERSION=4.4.2
MOUNT_OPTIONS=user=guest,pass=,rw,iocharset=utf8,noperm,forcemand,direct
DEFAULT_MOUNTPOINT=/net/sharebase
# CHECK_VERSION=0

Попробовал также зайти в базу 3-м клиентом (WinXP). Проблем с заходом в документ после печати не появилось.

Забыл указать версию wine: SQL 1.0.12-eter1.3/1

С etercifs-4.3.8 воспроизводится.

Насколько я помню в 4.4.2 блокировки самопроизвольно отваливаются, что наглядно видно по постам выше про не отображение пользователей в мониторе, что, как я понимаю, может привести к разрушению базы.:)))

> Насколько я помню в 4.4.2 блокировки
> самопроизвольно отваливаются, что
> наглядно видно по постам выше про не
> отображение пользователей в мониторе, что,
> как я понимаю, может привести к разрушению
> базы.:)))

По этой проблеме создал отдельный баг: 4987.

Ну вообще-то у меня стоит 
[root@terminal ~]# rpm -qa|grep cifs
dkms-etercifs-4.3.9-eter1mdv
mount-cifs-3.3.2-3mdv2009.1
etercifs-4.3.9-eter3mdv
[root@terminal ~]# rpm -qa|grep wine
wine-etersoft-1.0.11-eter11mdv
wine-etersoft-gl-1.0.11-eter11mdv
wine-etersoft-twain-1.0.11-eter11mdv
wine-etersoft-network-1.0.11-eter6mdv
И я так понимаю 4.4.2 - это бета? Я не хочу рисковать ставить бету на рабочий сервер... А насчет отваливающихся пользователей- разрушения базы не происходит... Наоборот- пока работали только под windows и с netware сервером ошибки периодически вылезали, а счас за 6 месяцев ни одной)) Вот только вылетающие пользователи напрягають.

Принято.
WINE@Etersoft 1.0.12 eter4/eter3