Created attachment 279 [details] ошибка Сообщение из заявки 3689: Здраствуйте! Два дня назад мы получили ваш продукт wine@etersoft Network 1.0.8 Mandriva для испытания, но обнаружили глюк при печати: при открытии счёта двойным щелчком (для чтения и записи), если напечатать и попытаться заново открыть этот счёт, то 1С выдаёт "Запись заблокирована!". Однако если открыть для просмотра и печатать в таком режиме, то всё нормально. Для нормальной работы наших сотрудников требуется чтобы такой ошибки не было.. База находится на сервере win2000, подключается в fstab: //j/1980 /mnt/j/2008 cifs iocharset=utf8,codepage=cp1251,user=syst,password=12345,nounix,noperm 0 0 У нас не воспроизвелась. У клиента возникает на wine 1.0.8, OC Mandriva.
Похоже, что в заявке 3662 точно такая же ошибка возникает.
У нас тоже монтировали с nounix ? А версии linux-cifs сравнивали?
*** Bug 1404 has been marked as a duplicate of this bug. ***
Данная ошибка возникает в заявке №5702.
Сообщение из заявки №6602: по ходу, эта проблема связана именно с тем, что документ печатают, так как если его просто открыть, посмотреть и закрыть, то никаких проблем не возникает
OpenSuse 10.3 1С 7.7 После печати из 1С при открытом документе (необязательно этого документа) и его закрытии, документ блокируется, и открыть его можно только для просмотра. Пользователь блокирует документы сам от себя и приходить для исправлениядокумента завершать работу 1С и запускать программу снова. Данная проблема только при базе в формате DBF на ресурсе CIFS.
ASPLinux 12, CentOS 5.1 1C 7.7 WINE@Etersoft Network 1.0.8 (пробовали и 1.0.9) Проблема с блокировкой документа, после вывода на печать осталась. Частично исправлено следующими настройками smb.conf [global] ... ... kernel oplocks = yes [sharedbase] blocking locks = yes locking = no oplocks = yes level2 oplocks = yes posix locking = yes strict locking = yes share modes = yes comment = sharedbase path = /var/local/sharedbase writeable = yes ; browseable = yes guest ok = yes Но возникла проблема !!! При многопользовательской работе разрушается индексный файл регистра остаков RA113.CDX (два, три раза в день). Для решения - перезагрузка сервера, переиндексация базы. Раздражает пользователей, отнимает много времени.
Вы отключили (locking = on) исполнение блокировок сервером напрочь. В этом режиме индексы будут разрушаться и сохранность данных непредсказуема.
Проблема когда примерно будет решена?
Проблема повторилась: http://rt.etersoft.ru/Ticket/Display.html?id=8080
Хотелось бы узнать о более точных сроках решения, потому что возникают недовольства со стороны клиентов.
1. Денис, нужно как-то воспроизвести эту багу, если она есть.
Не удалось воспроизвести проблему, может она исправлена в новой версии CIFS? Тестировал: kernel-source-linux-cifs-2.6.23-1.50-alt5 kernel-source-linux-cifs-2.6.24-1.52-alt4 kernel-source-linux-cifs-2.6.25-1.52-alt6 linux-cifs-3.1-alt4 kernel-source-linux-cifs-legacy-1.50c-alt1 Монтировал с noperm.
(In reply to comment #13) > Не удалось воспроизвести проблему, может > она исправлена в новой версии CIFS? Глеб, а что с аналогичными пакетами у клиентов?
Ответа клиента нет уже неделю после запроса. Считаем исправленной, иначе потом переоткроем.
может он просто перестал пользоваться? посмотрите сколько времени то прошло... Мне кажется это долго... если надо работать а не ждать когда может быть исправят то что уже сейчас нужно.
Сейчас проблема в том, что мы всё исправили и больше не можем воспроизвести ошибку у себя :) Опровержения принимаются тут. Пожалуйста.
Значит закрываем, потом если что переоткроем.
У клиента (http://rt.etersoft.ru/Ticket/Display.html?id=6643) На версии linux-cifs 3.6.1-alt.M40.1, 3.4.1-alt0.M40.1 - проблема воспроизводится. Suse 10.3 1c77
Надо бы перепроверить на новой сборке.
Еще раз переустановил etercifs, открываю документ (реализация) печатаю накладную, закрываю и при попытке снова открыть - запись заблокирована. В тестовой базе я один. Рабочая станция: ALT 4.0 , все что приходит по заказу сборки 1.0.9, 1C:Предприятие 7.7 для SQL (7.70.027) конфиг. Резон:Мясокомбинат 3.1 Сервер: 1) SUSE 10.3 samba 3.0.26a-3 или 2) Windows XP
Не могу воспоризвести, может у них ssh попросить!?
Появился доступ по ssh, описание в заявке.
(In reply to comment #7) > ASPLinux 12, CentOS 5.1 > 1C 7.7 > WINE@Etersoft Network 1.0.8 (пробовали и 1.0.9) > > Проблема с блокировкой документа, после > вывода на печать осталась. > Частично исправлено следующими > настройками smb.conf Максим, пожалуйста откликнитесь о проверке на релизе WINE@Etersoft 1.0.9 + etercifs >= 3.7 Также уберите все параметры из конфига smb.conf, содержащие слово lock - для работы 1С вполне подходят параметры по умолчанию. При установке других параметров может происходить всё, что угодно, это никто не тестировал. К тому же похоже, что вы просто поставили все параметры, которые нашли в документации.
Ко всем участникам баги - просьба перенести обсуждение в соответствующие заявки. Заявки передать kipruss. Я предполагаю, что проблема лежит в области неправильной настройки SAMBA. Наша документация по настройке выложена здесь: http://www.etersoft.ru/content/view/56/156/#cifs
В общем багу считаю закрытой. Тестируем на новых сборках с корректными настройками SAMBA, если возникают проблемы пишем заявку в саппорт.
(In reply to comment #24) > Максим, пожалуйста откликнитесь о проверке > на релизе WINE@Etersoft 1.0.9 + etercifs >= 3.7 > Также уберите все параметры из конфига > smb.conf, содержащие слово lock - для работы 1С > вполне подходят параметры по умолчанию. > При установке других параметров может > происходить всё, что угодно, это никто не > тестировал. К тому же похоже, что вы просто > поставили все параметры, которые нашли в > документации. Сервер терминалов на базе CentOS 5.2 2.6.18-92.1.18.el5PAE #1 SMP wine.i586 1:1.0.9-eter36centos wine-etersoft-sql.i586 1.0.9-eter14centos libwine.i586 1:1.0.9-eter36centos dkms-etercifs.noarch 3.8.0-eter1centos etercifs.noarch 3.8.0-eter7centos "1С: Предприятие 7.7 7.70.027" smb.conf: [sharewine] path = /var/localdatanet public = yes force user = maxim force group = wine writable = yes guest ok = yes # lsmod | grep eter etercifs 224244 1 Для всех клиентов терминала + на отдельной Linux машине: mount -t cifs //power/sharewine /mnt/powershare/ -o noperm,user=,pass= ln -s /mnt/powershare ~/.wine/dosdevices/w: База, соответственно цепляется с w: Очень интересная ситуация: Запуск ОДНОГО клиента Linux + один клиент с Windows машины - все ок. Запуск ДВУХ клиентов Linux с отключенным или подключенным клиентом Windows - один Linux-клиент - ок, на втором "Программа была завершена аварийно. Для восстановления индексных файлов запустите прграмму в монопольном режиме".
Откатывался на версию CIFS - linux-cifs-3.4.1-eter1centos.noarch.rpm Получилось запустить одновременно два linux клиента на расшаренной базе. Но блокирование документа, после печати, осталось 8-[ Перепробовал все версии пакетов etercifs, проблема точно воспроизводится как в моем комменте #27.
(In reply to comment #28) > Откатывался на версию CIFS - > linux-cifs-3.4.1-eter1centos.noarch.rpm > Получилось запустить одновременно два linux > клиента на расшаренной базе. > Но блокирование документа, после печати, > осталось 8-[ > Перепробовал все версии пакетов etercifs, > проблема точно воспроизводится как в моем > комменте #27. > У нас в документации строчка на монтирование выглядит так: # mount -t cifs //<сервер>/<ресурс> <локальный каталог> \ -o user=<workgroup/user>,pass=<passwd>,file_mode=0660,dir_mode=02770,uid=<user>,gid=<group>,iocharset=utf8 Попробуйте с ней (именно с такими правами) http://www.etersoft.ru/content/view/56/156/#x26
(In reply to comment #29) > (In reply to comment #28) > > Откатывался на версию CIFS - > > linux-cifs-3.4.1-eter1centos.noarch.rpm > > Получилось запустить одновременно два linux > > клиента на расшаренной базе. > > Но блокирование документа, после печати, > > осталось 8-[ > > Перепробовал все версии пакетов etercifs, > > проблема точно воспроизводится как в моем > > комменте #27. > > > > У нас в документации строчка на > монтирование выглядит так: > # mount -t cifs //<сервер>/<ресурс> <локальный > каталог> \ -o > user=<workgroup/user>,pass=<passwd>,file_mode=0660,dir_mode=02770,uid=<user>,gid=<group>,iocharset=utf8 > > Попробуйте с ней (именно с такими правами) > http://www.etersoft.ru/content/view/56/156/#x26 > Попробовал и с etercifs-3.8.0 и с linux-cifs-3.4.1: mount -t cifs //power/sharewine /mnt/powershare -o user=maxim,pass=,file_mode=0660,dir_mode=02770,uid=500,gid=104,iocharset=utf8 Ничего не изменилось.
Да, еще одна замечательная особенность. При ошибке из коммента #26 беру на втором linux-клиенте запускаю 1С в монопольном режиме, переиндексирую базы, остаюсь в монопольном режиме и без проблем запускаю 1C на первом linux-клиенте 8-0 С виндового клиента зайти на расшаренную базу уже не могу, требует входа в монопольном режиме и переиндексации даных. Зайти с него в монопольном режиме не удалось - 1С без сообщений вываливается.
(In reply to comment #31) > Да, еще одна замечательная особенность. > При ошибке из коммента #26 > беру на втором linux-клиенте запускаю 1С в > монопольном режиме, переиндексирую базы, > остаюсь в монопольном режиме и без проблем > запускаю 1C на первом linux-клиенте 8-0 > > С виндового клиента зайти на расшаренную > базу уже не могу, требует входа в > монопольном режиме и переиндексации даных. > Зайти с него в монопольном режиме не > удалось - 1С без сообщений вываливается. > Ошибочка, ошибка с моего коммента #27
Максим, посмотрите, пожалуйста, что происходит в "Сервис-Активные пользователи" при подключении следующих в различных вариациях.
Created attachment 937 [details] Дамп wine
(In reply to comment #34) > Created an attachment (id=937) [details] > Дамп wine > Для всех вариаций: Пользователь maxim (группы wine, wineadmin) на сервере терминалов Пользователь user01 (группа wine) на сервере терминалов Пользователь на Windows машине Мои сокращения сообщений ошибок: Ошибка1: "Программа была завершена аварийно. Для восстановления индексных файлов запустите прграмму в монопольном режиме". Ошибка2: «Ошибка блокировки данных. Возможно данные используются другой задачей» Ошибка3: После печати документа "Запись заблокирована!" Конфиг samba на сервере: /etc/smb.conf smb.conf: [global] ... kernel oplocks = no use sendfile = yes [sharewine] path = /var/local/datanet public = yes force user = maxim force group = wine writable = yes guest ok = yes Далее для каждого пользователя сервера терминалов: ln -s /mnt/powershare ~/.wine/dosdevices/w: И установлена "1С: Предприятие 7.7 7.70.027" Вариация 1: etercifs-3.8.0 mount -t cifs //power/sharewine /mnt/powershare -o user=maxim,pass=,file_mode=0660,dir_mode=02770,uid=500,gid=104,iocharset=utf8 maxim — старт ок, Windows — старт ок, user01 — Ошибка1 maxim — старт ок, user01 — Ошибка1, Windows — старт ок "Сервис - Активные пользователи" — честно отображает двух пользователей. Вариация 2: etercifs-3.8.0 mount -t cifs //power/sharewine /mnt/powershare -o user=maxim,pass=,file_mode=0660,dir_mode=02770,uid=500,gid=104,iocharset=utf8 maxim — в монопольном режиме ок, user01 — в обычном режиме, Ошибка2, Windows — в обычном режиме тоже Ошибка2 "Сервис - Активные пользователи" — честно отображает одного пользователя. maxim — в обычном режиме, ок; user01 — в монопольном режиме, ок; Windows — в обычном режиме Ошибка2 А вот "Сервис - Активные пользователи" на maxim пуст, а на user01 — честно отображает одного пользователя. К тому же, при обновлении окна "Сервис - Активные пользователи" на maxim, на user01 повисла 1С и wine вывалился в winedbg. Закрыл 1С, вышел из терминальной сессии, под рутом сделал skill -u user01. Залогинился в терминальную сессию под user01, попытка запустить 1С в любом режиме - «Ошибка при запуске журнала регистрации». 1С под maxim запущена, "Сервис - Активные пользователи" НЕ отображает ниодного пользователя, Windows — вылетает при попытке подключения без всяких сообщений. Закрыл все копии 1С, перемонтировал ресурс: maxim — старт ок, Windows — старт ок, user01 — Ошибка1 "Сервис - Активные пользователи" — честно отображает двух пользователей. Закинул вывод winedbg в аттач wine-dump.txt. Варьировать еще? :-)
Примечание: Во Время "Вариация 1:" когда у user01 на экране "Программа была завершена аварийно. Для восстановления индексных файлов запустите прграмму в монопольном режиме". и не нажимать кнопку "ок", то "Сервис - Активные пользователи" — честно отображает троих пользователей.
Всё достаточно! :-) Будем смотреть теперь у себя.
На данный момент проблема, заявленная в данной баге исчерпала себя (блокировка документа). Эту ошибку закрываю. С вашей проблемой вы можете обратиться в саппорт.
> С вашей проблемой вы можете обратиться в > саппорт. > заведена бага http://bugs.etersoft.ru/show_bug.cgi?id=3053
(In reply to comment #0) > при открытии счёта двойным щелчком (для > чтения и записи), если > напечатать и попытаться заново открыть > этот счёт, то 1С выдаёт "Запись > заблокирована!". Однако если открыть для > просмотра и печатать в таком > режиме, то всё нормально. Возникла аналогичная ошибка на Alt Linux Desktop 4.0. Версии установленных пакетов: [root@localhost alex]# rpm -qa | grep wine libwine-1.0.9-alt39.M40.40 wine-1.0.9-alt39.M40.40 wine-etersoft-network-1.0.9-alt16.M40.17 [root@localhost alex]# rpm -qa | grep cifs etercifs-4.1.1-alt0.M40.1 Вывод winediag: Программа проверки WINE@Etersoft. 06.11.08 © 2005, 2006, 2007, 2008 Etersoft Проверяем libwine.so.1... ИМЕЕТСЯ. (версия 20080705) Проверяем /usr/bin/winelog ... пакет WINE@Etersoft: УСТАНОВЛЕН Проверяем libwine-etersoft.so.1... NETWORK ИМЕЕТСЯ (сборка 0x211) ------- WINE@Etersoft 1.0 Network (1.0.9), registration number is XXXX-XXXX. Legality check is available on the page http://sales.etersoft.ru/product/. ------- Проверяем libcups.so.2... ИМЕЕТСЯ. Проверяем libfreetype.so.6...ИМЕЕТСЯ (версия 2.3.4) Установлено соединение с Икс-сервером на :0.0 Расширение GLX имеется (3D поддерживается) Используемая модель потоков (thread): pthread (NPTL) Ядро: Linux, версия: 2.6.18-wks-smp-alt2 Максимальное число файловых дескрипторов в системе: 104854 (3072 используется) Максимально доступное количество открытых файлов для одного процесса: 5000 Число тиков таймера в секунду (CLK_TCK): 100 Нет ограничений виртуальной памяти Check for futimes: OK Количество бит для смещения в файле: 64 Установка блокировки на смещение более 512Мб прошла успешно Установка блокировки на смещение более 4Гб прошла успешно Текущая локаль: ru_RU.UTF-8 Информация о модуле etercifs: [root@localhost ~]# lsmod | grep cifs etercifs 249716 1 nls_base 8448 10 nls_cp866,vfat,fat,isofs,udf,nls_cp1251,smbfs,nls_koi8_r,nls_utf8,etercifs [root@localhost ~]# /sbin/modinfo etercifs filename: /lib/modules/2.6.18-wks-smp-alt2/kernel/fs/cifs/etercifs.ko version: 1.51 description: VFS to access servers complying with the SNIA CIFS Specification e.g. Samba and Windows license: GPL author: Steve French <sfrench@us.ibm.com> srcversion: 03DA04FA9AFB8DC48596B6B depends: nls_base vermagic: 2.6.18-wks-smp-alt2 SMP mod_unload 586 REGPARM gcc-4.1 parm: CIFSMaxBufSize:Network buffer size (not including header). Default: 16384 Range: 8192 to 130048 (int) parm: cifs_min_rcv:Network buffers in pool. Default: 4 Range: 1 to 64 (int) parm: cifs_min_small:Small network buffers in pool. Default: 30 Range: 2 to 256 (int) parm: cifs_max_pending:Simultaneous requests to server. Default: 50 Range: 2 to 256 (int)
Открываю для повторной проверки на новой сборке etercifs
Протестировал, ошибку не удалось воспроизвести, монтировал: mount -t cifs //server/share /mnt/cifs -o uid=user,gid=user,file_mode=0660,dir_mode=0770,nounix Etercifs: etercifs-4.1.1-alt1 Wine: wine-etersoft-sql-1.0.9-alt18 wine-1.0.9-alt42 libwine-1.0.9-alt42
(In reply to comment #42) > Протестировал, ошибку не удалось > воспроизвести, монтировал: > mount -t cifs //server/share /mnt/cifs -o > uid=user,gid=user,file_mode=0660,dir_mode=0770,nounix Монтирование делал согласно документации в двух вариантах: mount -t cifs //server/base /mnt/base -o user=user, pass=pass, file_mode=0660, dir_mode=2770, uid=user, gid=user, iocharset=utf8, forcemand mount -t cifs //server/base /mnt/base -o user=user, pass=, forcemand, noperm, iocharset=utf8 Попробую с параметрами монтирования как в посте #42, по результатам отпишусь.
(In reply to comment #43) > Попробую с параметрами монтирования как в > посте #42, по результатам отпишусь. > Ну как результаты?
(In reply to comment #44) > Ну как результаты? С параметрами монтирования из поста #42 блокировка записи при печати документа и повторном его открытии осталась. Сейчас проблема не актуальна так как перевели всех пользователей в терминальный режим работы. При файловом режиме был использован следующий конфиг Samba: [global] workgroup = ALTDOMAIN netbios name = 1CServer server string = File Server on %h interfaces = 192.168.44.2/24 bind interfaces only = yes preferred master = yes domain master = no security = share encrypt passwords = true template shell = /bin/false hosts allow = 192.168.1. 192.168.2. 192.168.44. hosts deny = all null passwords = yes guest account = smb display charset = utf-8 dos charset = 866 unix charset = utf-8 use sendfile = yes kernel oplocks = no load printers = no #log level = 0 #log file = /var/log/samba/%I.log #max log size = 500 #socket options = TCP_NODELAY SO_SNDBUF=8192 SO_RCVBUF=8192 [base] comment = 1C base path = /var/db/1c force group = wine read only = no create mask = 0660 directory mask = 0770 browseable = yes guest ok = yes guest only = yes
на сколько я помню, через smb/cifs оно ни когда нормально не работало. Для себя в свое время выход найден был в NFS... и то оно периодически подглюкивало... ИМХО сейчас, если не на поиграться, а реально работать, то терминал... И тут думаю не важно, на win или lin терминальном сервере... Но я с lin. терминалом конкретно это не заводил. Но думаю не должно быть проблем, т.к. просто без терминала, локально, работает отлично...
Ну что, год не можем воспроизвести простую проблему и сформулировать хотя бы, от чего она точно не зависит? Я предполагаю, что дело в конкретной SAMBA. Уже давно можно зайти к клиенту, или точно воспроизвести его окружение.
Проверил у клиента, воспроизводится. rpm -qa | grep cifs etercifs-4.1.1-alt0.M41.1 [alex@alex BIN]$ rpm -qa | grep samba samba-common-3.0.30-alt3 samba-3.0.30-alt3 samba-client-control-1.2-alt1 samba-client-3.0.30-alt3 samba-client-cups-3.0.30-alt3 [alex@alex BIN]$ rpm -qa | grep wine libwine-1.0.9-alt41.M41.42 docs-wine_intro-0.1.1-alt0.M41.1 wine-etersoft-network-1.0.9-alt17.M41.18 wine-1.0.9-alt41.M41.42 [alex@alex BIN]$ uname -a Linux alex.exprof 2.6.25-std-def-alt8.M41.4 #1 SMP Sat Dec 6 14:42:12 MSK 2008 i686 GNU/Linux
Выяснилось почему мы не могли воспроизвести: 1) Воспроизводили всегда печатая документ в файл 2) Проблема оказывается проявляется только при печати именно на принтер.
Воспроизвёл. Буду решать.
Отличие состоит в том, что при печати на принтер печать осуществляется с помощью команды lpr. Работает это примерно следующим образом: 1) создаётся pipe 2) создаётся новый поток, в котором запускается комманда lpr 3) ввод/вывод нового потока через pipe связывается с файловым дескриптором. Таким образом получаем файловый дескриптор fd. Всё, что пишем в файл отправляется через pipe запущенной команде lpr. Проверил. Сама комманда lpr тут не причём. Если её заменить на 'cat > /dev/null', то ничего не изменится, файл по-прежнему блокируется.
Возможно проблема в функции fork(). Она создаёт создаёт процесс - копию текущего. По идее дескрипторы файлов тоже должны наследоваться. Но по документации: "Блокировки файлов и сигналы, ожидающие обработки, не наследуются" И вообще, на первый взгляд всё должно работать. При вызове exec вся область данных процесса перезаписывается
Заметил одну особенность: В потоке порождённом fork() убрал вызов exec, и добавил бесконечный цикл, постоянно считывающий сообщения из входного буфера. В итоге: 1) если порождаемый поток не завершается, то баги нет 2) если порождаемый поток завершается, то бага есть 3) если в порождаемом потоке вызывать exec(), то бага тоже есть. Получается проблема возникает при закрытии потока. Возможно проблема возникает ещё при замещении текущего процесса другой программой (вызов exec). Но в этом случае трудно определить реальную причину: 1) по документации для exec "Все файлы, открытые вызывающей программой, остаются открытыми" 2) Бага может возникать когда завершается программа, вызванная exec, и убивает поток. Точно определить появляется ли бага ПРИ вызове exec или ПОСЛЕ его завершения не получается
нашёл в документации: "Завершение процесса, или выполнение новой программы в процессе, уничтожает все потоки в процессе. Если описатели, связанные с этими потоками сохраняются в других процессах, их файловые позиции станут неопределенными. Чтобы предотвратить это, Вы должны очистить потоки перед их разрушением. " попробовал закрывать все файлы преред вызовом exec: for (i = 3; i < 255; i++) if (i!=fds[0] && i!=fds[1]) close(i); в таком варианте ничего не происходит, и блокировка остаётся. Если пробегать не 256 файлов, а больше, то печать + 1с повисает.
Пробовал использовать функцию popen: fil = popen(psCmdP,"we"); fd = fileno(fil); ,которая заменяет pipe() и fork(). Но файл по-прежнему блокируется
Написал тестовую программу. Проблему пока воспроизвести не удалось: 1)Для потока, создающего блокировку, файл всегда разблокирован 2) ни после клонирования потока, ни после завершения клонированого потока, для исходного потока файл всегда разблокирован.
написал ещё один тест: 1) устанавливается блокировка на файл (на запись) 2) с помощью fork порождается новый процесс 3) и в потомке, и в родителе проверяется блокировка на файл Результаты: *Запуск на ext3: Родитель - блокировка отсутствует Потомок - стоит блокировка на запись *Запуск на cifs: Родитель - блокировка отсутствует Потомок - стоит блокировка на ЧТЕНИЕ
Написал ещё один тест. Выяснил: 1) (как и ожидалось) Если файл закрыть в одном из потоков, то во втором потоке он остаётся закрытым. 2) Если файл закрыть в родителе, то для порождённого процесса блокировка на файл снимается. 3) Результаты не зависят от файловой системы. (Различите только в том, что для cifs блокировка считывается как блокировка на чтение вместо блокировки на запись)
(In reply to comment #57) > *Запуск на cifs: > Родитель - блокировка отсутствует > Потомок - стоит блокировка на ЧТЕНИЕ > Завёл новую багу #3660
В wine немного другой механизм действия блокировки. Пишу тест на WINAPI функции блокировки. Встретился с некоторыми особенностями: * Функции LockFile() и UnlockFile позволяют ставить блокировку на определённый регион файла, но тип блокировка (чтение или запись) задавать нельзя * Пока не знаю как проверить стоил ли на файле блокировка. Пробовал просто писать в файл - в результате оба процесса (и родитель и потомок) пишут в файл без проблем.
с тестом на блокировку пока ничего не получается. Зато появилась идея вместо fork() использовать WINAPI функцию CreateProcess. Если я правильно понимаю, потоки ввода-вывода (stdin и stdout) ей можно задавать принудительно.
1)частично реализовал печать через CreateProcess(). Реализация немного не корректная, вместо линуксового дескриптора файла функция CreatePipe возвращает винапишный HANDLE. Файл не блокируется! 2) Далее пришлось сильно изменить работу с файлами: везде заменять write на WriteFile, сlose на Closefile, open на CreateFile. В итоге 1с зависает. Но не сразу, успевает ещё отправить в pipe начало документа.
Разобрался с проблемой. CreateProcess() возвращает FALSE. Процесс не запускается. Причина в том, что этой функцией нельзя запустить линуксовые комманды
(In reply to comment #60) > * Пока не знаю как проверить стоил ли на > файле блокировка. Пробовал просто писать в > файл - в результате оба процесса (и родитель > и потомок) пишут в файл без проблем. > Разобрался. Блокировка можно проверить только выставлением блокировки. Если блокировку нельзя выставить, значит она уже есть, если можно, то её нет. Переписал тест. Результаты: 1) Блокировка видна как в родительском процессе, так и в порождённом 2) После снятия блокировки в родительском процессе, она снимается и для порождённого 3) Если порождённый процесс завершается при снятой блокировке, то она так и остаётся снятой. Результаты идентичны для ext3 и для cifs
Посмотрел трейс при запуске 1с на функции LockFile и Unlock file. Интересующая нас блокировка ставится при открытии документа (ещё до формирования версии для печати): fixme:file:LockFile 0x128 03fffff35 000000001 Блокировка снимается сразу после закрытия документа: fixme:file:UnlockFile handle = 0x128 offs = 0x3fffff35, count = 0x1 Во время печати функции (раз)блокироки не вызываются с дескриптором 0x128 Далее, при повторном открытии, снова ставится блокировка: fixme:file:LockFile 0x128 03fffff35 000000001 При этом 1с выдаёт ошибку.
* Дескриптор 0х128 соответствует файлу H:\1C77\DemoDB\1SJOURN.CDX * Пробовал печатать в файл (при этом бага не проявляется) - трейсы в консоле ничем не отличаются от печати на принтер.
в функции fd_destroy есть специальный case для cifs. Пробовал закомментировать - ничего не изменилось
(In reply to comment #66) > * Дескриптор 0х128 соответствует файлу > H:\1C77\DemoDB\1SJOURN.CDX > > * Пробовал печатать в файл (при этом бага не > проявляется) - трейсы в консоле ничем не > отличаются от печати на принтер. > То есть так же при печати в файле не вызывается > fixme:file:UnlockFile handle = 0x128 offs = 0x3fffff35, count = 0x1 ? Возможно происходят какие-то ещё вызовы других файловых функций с этим хэндлом? О, вот что важно! Блокировка происходит на сервере, а не просто в wineserver или локально, поскольку с другой машины (с винды) документ также не открыть.
Насколько я понимаю, надо включить логи на клиенте/сервере и посмотреть, что происходит в момент завершения порождённого процесса. Похоже, что по какой-то причине не воспринимается UnLock, выполняемый при закрытии документа. Возможно etercifs смущает сервер изменением пидов (серверу же передаётся идентификатор клиента, в которых входит pid?) Чем более будет предложений и гипотез, тем лучше. Проблема очень важная, практически последняя по etercifs на текущий момент.
> > Чем более будет предложений и гипотез, тем > лучше. Проблема очень важная, практически > последняя по etercifs на текущий момент. Могу сказать, что испытываем потребность в приобретении wine@etersoft но приобратать счас такой продукт сами помаете невозможно. Очень ждем исправления.
что значит "практически последняя"? озвучьте весь список, пожалуйста. даже редко встречающиеся проблемы, т.к. у меня плохая карма и я полюбому наткнусь... :)
(In reply to comment #60) > В wine немного другой механизм действия > блокировки. > > Пишу тест на WINAPI функции блокировки. > Встретился с некоторыми особенностями: > * Функции LockFile() и UnlockFile позволяют ставить > блокировку на определённый регион файла, > но тип блокировка (чтение или запись) > задавать нельзя > * Пока не знаю как проверить стоил ли на > файле блокировка. Пробовал просто писать в > файл - в результате оба процесса (и родитель > и потомок) пишут в файл без проблем. > Есть функция LockFileEx, которая умеет ставить блокировки на чтение.
(In reply to comment #72) > Есть функция LockFileEx, которая умеет ставить > блокировки на чтение. В данном случае это не важно, она не может использоваться в 1С 7.7, поскольку появилась позже.
(In reply to comment #65) > Посмотрел трейс при запуске 1с на функции > LockFile и Unlock file. > > Интересующая нас блокировка ставится при > открытии документа (ещё до формирования > версии для печати): > fixme:file:LockFile 0x128 03fffff35 000000001 > > Блокировка снимается сразу после закрытия > документа: > fixme:file:UnlockFile handle = 0x128 offs = 0x3fffff35, count = 0x1 > Это как? Разве можно снять блокировку после закрытия файла? Ведь handle уже становится не валидным. Или имеется ввиду что-то другое? > Во время печати функции (раз)блокироки не > вызываются с дескриптором 0x128 > > Далее, при повторном открытии, снова > ставится блокировка: > fixme:file:LockFile 0x128 03fffff35 000000001 > При этом 1с выдаёт ошибку. >
(In reply to comment #74) > > Блокировка снимается сразу после закрытия > > документа: > > fixme:file:UnlockFile handle = 0x128 offs = 0x3fffff35, count = 0x1 > > > > Это как? Разве можно снять блокировку после > закрытия файла? Ведь handle уже становится не > валидным. Или имеется ввиду что-то другое? Все файлы в 1С (DBF и CDX) открываются при запуске программы и больше не закрываются до выхода. Речь шла о закрытии документа. Схема ведь такая: 1. открываем документ (ставится блокировка на участок файла, что документ заблокирован) 2. делаем fork 3. при завершении порождённого процесса происходит нечто (хотя по POSIX тоже плохо, должны сброситься блокировки, установленные родительским процессом) 4. далее мы закрываем документ (блокировка снимается с участка файла) 5. и тут почему-то обнаруживается, что блокировка эта осталась на самба-сервере (возможно он путает хозяев блокировки).
Сделан тестовый пакет. См. http://bugs.etersoft.ru/show_bug.cgi?id=3660#c13 Надо потестировать. Перевешиваю на отдел тестирования.
(In reply to comment #76) > Сделан тестовый пакет. См. > http://bugs.etersoft.ru/show_bug.cgi?id=3660#c13 > Надо потестировать. Перевешиваю на отдел > тестирования. > Протестировал ошибку на 1С77 - не проявляется. http://bugs.etersoft.ru/show_bug.cgi?id=3746
(In reply to comment #77) > http://bugs.etersoft.ru/show_bug.cgi?id=3746 > Не то написал, etercifs-4.2.1-alt1.testing1
(In reply to comment #78) > (In reply to comment #77) > > http://bugs.etersoft.ru/show_bug.cgi?id=3746 > > > Не то написал, > etercifs-4.2.1-alt1.testing1 > После повторной проверки обнаружилась что ошибка не исправлена и по прежнему воспоризводится.
Тестировалось с опцией forcemand или без неё?
Нужно протестировать etercifs-4.2.1-alt1.testing2 ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs-testing/noarch/RPMS.default/etercifs-4.2.1-alt1.testing2.noarch.rpm
Честно говоря я не вижу никакой связи между залипанием блокировки на сервере после завершения форкнутого процесса и обнаруженного неправильного поведения F_GETLK.
(In reply to comment #82) > Честно говоря я не вижу никакой связи между > залипанием блокировки на сервере после > завершения форкнутого процесса и > обнаруженного неправильного поведения > F_GETLK. > После тестирования будет видно. Если проблема первоначальная ушла, то связь есть, если нет, то, соответственно, надо дальше разбираться. Осталось только не заблудиться в такой длинной баге...
(In reply to comment #81) > Нужно протестировать etercifs-4.2.1-alt1.testing2 > > ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs-testing/noarch/RPMS.default/etercifs-4.2.1-alt1.testing2.noarch.rpm > Проверил в 1с77, заявленной проблемы нет.
см. http://bugs.etersoft.ru/show_bug.cgi?id=3755#c1 выпущен 4.3.0, содержащий все, что было в 4.2.1-testing2
(In reply to comment #85) > см. http://bugs.etersoft.ru/show_bug.cgi?id=3755#c1 > выпущен 4.3.0, содержащий все, что было в > 4.2.1-testing2 Проверил еще раз, выяснилось что на тестовой сборке и на 4.3.0 данная ошибка проявляется если монтировать: 1)с опцией forcemand и direct одновременно 2)с опцией forcemand ошибка НЕ проявляется если монтировать только с опцией direct.
(In reply to comment #86) > ошибка НЕ проявляется если монтировать > только с опцией direct. > Проверялось с сервером на Linux машине. Проверил с Windows сервером и получилось что с любыми параметрами ошибка проявляется!
(In reply to comment #87) ... > Проверил с Windows сервером и получилось что с > любыми параметрами ошибка проявляется! Что насчёт монтирования с noperm?
(In reply to comment #88) > Что насчёт монтирования с noperm? > 1) noperm 2) noperm,direct 3) noperm,direct,forcemand Во всех 3 случаях ошибка стабильно проявляется.
Я так понимаю, что раз для Linux сервера без опции forcemand(она делает его по сути windows сервером с точки зрения блокировок) патч для F_GETLK проблему решил, я прав?
слово "раз" в предыдущем посте было лишним)
Вышел etercifs-4.3.1 - см. http://bugs.etersoft.ru/show_bug.cgi?id=3725#c26 Я не уверен, что он решает эту проблему, скорее он должен решить 3725, и если повезёт, то и эту. Надо тестировать и если не получится, смотреть уже конкретно эту багу, отталкиваясь от того, что есть.
Поясню. В предыдущем testing2 решили багу 3660, которая была производной от этой баги. Во время этого процесса появилась бага 3725, которую тоже попытались решить и есть надежда, что решили, заодно обнаружив, что наши оплочные патчи заменяются опцией монтирования direct. Собственно, теперь их и нет. Это вообще проблемы разные и путать их не надо. Но учитывать изменения надо. Надеюсь я никого не запутал. Если что - будем распутывать.
Проверил. Баги нет.
С какими параметрами монтирования и на какой версии этерцифса?
etercifs-4.3.2-alt1.etermount монтировалось без параметров
> etercifs-4.3.2-alt1.etermount > > монтировалось без параметров > без парметров эт оне дело. Провел тестирование с рекомендоваными параметрами direct,noperm,forcemand на etercifs-4.3.2. Результат: бага воспроизводится 100% при монтировании с Linux и Windows серверов. Вдобавок ко всему если в таком сеансе была заблокирована запись, то 1Ска вылетает с сообщением об ошибке (см скрин1). Сделан трейс по +file (см лог в прилож.)(In reply to comment #96)
Created attachment 1125 [details] скрин1
Created attachment 1126 [details] трейс на закрытие
>> Комментарий #97 Монтирование производилось с Windows машины.
Проведено тестирование с Linux сервером с разными вариациями параметров: Ошибка не воспроизвелась только если монтировать с параметрами: 1) direct 2) noperm 3) noperm, direct Видимо forcemand что то портит.
Параметр direct больше не обязателен в 4.3.2.
Воспроизвёл багу с помощью программы на си.
Отлично. Вложением к баге?
Сделал табличку по тому что есть сейчас: http://wiki.office.etersoft.ru/testing/cifs/printblock
(In reply to comment #105) > Сделал табличку по тому что есть сейчас: > http://wiki.office.etersoft.ru/testing/cifs/printblock > Про direct можно уже забыть. Только лишняя работа.
Created attachment 1132 [details] воспроизводит багу
Последний коммит из http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/v2.6.27-testing должен решить проблему.
(In reply to comment #101) > Проведено тестирование с Linux сервером с > разными вариациями параметров: > Ошибка не воспроизвелась только если > монтировать с параметрами: > 1) direct > 2) noperm > 3) noperm, direct > > Видимо forcemand что то портит. > etercifs 4.3.2 Схема сети такая: WinXP SP2 - 3-и машины Mandriva 2009.0 Free - 2-е машины Базы расположены на одной из WinXP или одной из Mandriva Linux машин Ресурсы монтируются 1. noperm 2. fircemand проблема всплывает при любом из параметров
(In reply to comment #108) > Последний коммит из > > http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/v2.6.27-testing > > должен решить проблему. > ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs/noarch/RPMS.default/etercifs-4.3.3-alt1.noarch.rpm Пакет не только содержит патч, но и решается проблема сборки на ядре 2.6.29 (RT#9966), обновлены исходники до 2.6.29.1 и доработан скрипт так, что если есть новый пакет etercifs, то старый модуль грузиться не будет. С CentOS пока неудачно.
(In reply to comment #108) > Последний коммит из > > http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/v2.6.27-testing > > должен решить проблему. > Проверил новую сборку на 1С 77, проблема с блокировкой документа после печати больше не проявляется. Как появлюсь в офисе потестирую более тщательно, вдруг чтото сломалось. P.S. to Лена, прогоните rect тесты.
(In reply to comment #110) > (In reply to comment #108) > > Последний коммит из > > > > http://git.etersoft.ru/people/piastry/packages/?p=cifs-2.6.git;a=shortlog;h=refs/heads/v2.6.27-testing > > > > должен решить проблему. > > > > ftp://ftp.etersoft.ru/pub/Etersoft/LINUX@Etersoft/Boxes/etercifs/noarch/RPMS.default/etercifs-4.3.3-alt1.noarch.rpm > > Пакет не только содержит патч, но и > решается проблема сборки на ядре 2.6.29 (RT#9966), > обновлены исходники до 2.6.29.1 и доработан > скрипт так, что если есть новый пакет etercifs, > то старый модуль грузиться не будет. > > С CentOS пока неудачно. > Пакетики для мандривы 2009.0 соберите пожалуйста. Смогу посмотреть в реальной работе.
(In reply to comment #112) ... > Пакетики для мандривы 2009.0 соберите > пожалуйста. Смогу посмотреть в реальной > работе. > Готово: ftp://updates.etersoft.ru/pub/Etersoft/CIFS%40Etersoft/4.3.3
(In reply to comment #113) > (In reply to comment #112) > ... > > Пакетики для мандривы 2009.0 соберите > > пожалуйста. Смогу посмотреть в реальной > > работе. > > > Готово: > ftp://updates.etersoft.ru/pub/Etersoft/CIFS%40Etersoft/4.3.3 > Надо бы ещё для Мандривы собрать dkms-etercifs.
(In reply to comment #113) > (In reply to comment #112) > ... > > Пакетики для мандривы 2009.0 соберите > > пожалуйста. Смогу посмотреть в реальной > > работе. > > > Готово: > ftp://updates.etersoft.ru/pub/Etersoft/CIFS%40Etersoft/4.3.3 > (In reply to comment #114) > (In reply to comment #113) > > (In reply to comment #112) > > ... > > > Пакетики для мандривы 2009.0 соберите > > > пожалуйста. Смогу посмотреть в реальной > > > работе. > > > > > Готово: > > ftp://updates.etersoft.ru/pub/Etersoft/CIFS%40Etersoft/4.3.3 > > > > Надо бы ещё для Мандривы собрать dkms-etercifs. > Установил из предыдущего пакета для альта, пересобрал модуль, перемонтировал ресурсы Все равно после печати всех выкинуло из базы
(In reply to comment #115) > > Надо бы ещё для Мандривы собрать dkms-etercifs. > > > > Установил из предыдущего пакета для альта, > пересобрал модуль, перемонтировал ресурсы > > Все равно после печати всех выкинуло из > базы > А версию 4.3.2 в файле dkms.conf заменили на 4.3.3? Всё же дождитесь пакета потому что там есть ещё и постинсталл-скрипты, которые добавляют в dkms-дерево информацию о модуле и, соответственно, после удаления пакета, удаляют её и модуль. Для проверки можно запустить service etercifs status
(In reply to comment #116) > (In reply to comment #115) > > > Надо бы ещё для Мандривы собрать dkms-etercifs. > > > > > > > Установил из предыдущего пакета для альта, > > пересобрал модуль, перемонтировал ресурсы > > > > Все равно после печати всех выкинуло из > > базы > > > > А версию 4.3.2 в файле dkms.conf заменили на 4.3.3? > > Всё же дождитесь пакета потому что там есть > ещё и постинсталл-скрипты, которые > добавляют в dkms-дерево информацию о модуле > и, соответственно, после удаления пакета, > удаляют её и модуль. > > Для проверки можно запустить service etercifs status > service etercifs status CIFS module status: modinfo: could not open etercifs: Permission denied package etercifs version 4.3.3 kernel module etercifs is built kernel module etercifs version 4.3.3 is loaded Монтирую с noperm, без forsemand Результат: Ошибка ввода-вывода
Вот как можно обойтись без свежего пакета dkms-etercifs: 0. Удаляю старый dkms-etercifs командой rpm -e dkms-etercifs 1. Скачиваю etercifs-4.3.3-eter1mdv.noarch.rpm 2. Обновляю этот пакет: rpm -Uhv ./etercifs-4.3.3-eter1mdv.noarch.rpm 3. Поскольку теперь у меня нет установленного пакета dkms-etercifs произвожу операцию руками: 4. Создаем каталог /usr/src/etercifs-4.3.3 5. Копируем файл dkms.conf из старого пакета в файл /usr/src/etercifs-4.3.3/dkms.conf, не забыв заменить старую версию модуля на 4.3.3 6. Запускаем команду dkms add -m etercifs -v 4.3.3 --rpm_safe_upgrade 7. Собираем модуль Если нужное ядро загружено, то: service etercifs build А потом запустить service etercifs restart и проверить service etercifs status Примечание 0. Всё же проще дождаться пакета dkms-etercifs нужной версии. Да и надёжнее. Примечание 1. А если надо собрать для другого ядра, то сперва надо нужные исходники из /usr/share/etercifs/sources распаковать в /usr/src/etercifs-4.3.3, в потом запустить команды (пример для ядра 2.6.29-desktop-1mnb): dkms build -m etercifs -v 4.3.3 -k 2.6.29-desktop-1mnb --rpm_safe_upgrade dkms install -m etercifs -v 4.3.3 -k 2.6.29-desktop-1mnb --rpm_safe_upgrade Примечание 2. Нашел мелкую багу в скриптах при выводе service etercifs status - выводятся некие ненужные сообщения. Буду смотреть.
ftp://ftp.etersoft.ru/pub/Etersoft/CIFS@Etersoft/4.3.3/Mandriva/2009.0/dkms-etercifs-4.3.3-eter1mdv.noarch.rpm
Итак протестировал еще раз более подрочбно etercifs 4.3.3 Монтировал с парамерами noperm,forcemand Проблема с блокировкой после закрытие не воспоризводится. Был проверен совместный доступ по мотивам http://wiki.office.etersoft.ru/testing/cifs/dostup, результат положительный на Windows и Linux серверах. Проверялось на WINE 1.0.9 и на 1.0.10 Данная бага исчерпана, так что думаю пора закрывать и переносить дополнительные обсуждения в другое место. P.S. рекомендовано монтировать с forcemand всегда!
(In reply to comment #120) > Итак протестировал еще раз более подрочбно > etercifs 4.3.3 > Монтировал с парамерами noperm,forcemand > Проблема с блокировкой после закрытие не > воспоризводится. > Был проверен совместный доступ по мотивам > http://wiki.office.etersoft.ru/testing/cifs/dostup, результат > положительный на Windows и Linux серверах. > > Проверялось на WINE 1.0.9 и на 1.0.10 > > Данная бага исчерпана, так что думаю пора > закрывать и переносить дополнительные > обсуждения в другое место. > > > P.S. рекомендовано монтировать с forcemand > всегда! > Протестирую утром с указанными параметрами. Так как с noperm без forcemand выдает ошибку ввода-вывода, в конфигурации 2 - WinXP x 2 - Linux, с Linux сервером.
etercifs - 4.3.3mdv, модули собраны и загружены. Базы на Linux-е. Монтирую с noperm,forcemand После плучаса работы, на проведении документа, выкинуло сначала одного Win клиента, затем выкинуло всех остальных. При повторном проведении того же докумнета выкидывает всех. В результате разрушение базы. Посмотрю что будет после исправления баз. Но ошибка показала себя снова. Не вижу смысла закрывать эту багу до тех пор пока окончательно не будет решена проблема.
После исправлений снова выкидывает
(In reply to comment #123) > После исправлений снова выкидывает Я правильно понимаю, что ошибка с печатью не происходит? Что значит "выкидывает"? Или это та же ошибка, которая возникает реже? Что значит "после получаса работы"? То есть первые полчаса всё работало?
Просьба больше не писать в эту багу, которая посвящена исключительно блокированию документа (зависанию блокировок) после печати, вызванному fork'ом процесса. Если есть другие проблемы с etercifs, их надо написать либо в support@, либо завести новую багу, с условиями воспроизведения.
