С сервера server каталог БД 1С экспортируется по NFS (версия 3) на рабочих станциях wkst1 и wkst2 смонтирован каталог БД 1С на станции wkst1 пользователь usr1 первым запускает 1С на станции wkst2 пользователь usr2 запускает 1С и видит сообщение: "Программа была завершена аварийно. Для восстановления индексных файлов запустите программу в монопольном режиме." Опробовано в нескольких вариантах (все системы с последними обновлениями): server, wkst1, wkst2 - CentOS 5.3 server, wkst1, wkst2 - Fedora 11 server - Fedora 9, wkst1, wkst2 - CentOS 5.3 NFS настраивался в соответствии с инструкциями в manual.html, http://www.bog.pp.ru/work/NFS.html 1С используется только в Linux. На сервер server 1С не запускается (только экспорт NFS). Опции экспорта NFS: rw,no_root_squash,async,insecure,no_subtree_check,acl Опции монтирования NFS: nosuid,nodev,soft,udp,rsize=8192,wsize=8192,acregmin=30,noatime,nodiratime На сервере запущены службы: CentOS 5.3: portmap, nfslock, nfs Fedora: rpcbind, nfslock, nfs На клиентах запущены службы: CentOS 5.3: portmap, nfslock Fedora: rpcbind, nfslock Не работает с версиями WINE@Etersoft: 1.0.10 (wine-etersoft-1.0.10-eter23, wine-etersoft-network-1.0.10-eter16) 1.0.10 (wine-etersoft-1.0.10-eter25, wine-etersoft-network-1.0.10-eter18) Вывод команды winelocktest Info: Running on NFS filesystem G_R G_R G_R G_W G_W G_W G_R|W G_R|W G_R|W S_R S_W S_R|W S_R S_W S_R|W S_R S_W S_R|W G_R lVL l. lVL l. l. l. l. l. l. S_R G_R l. l. l. lVL l. lVL l. l. l. S_W G_R lVL l. lVL lVL l. lVL lVL l. lVL S_R|W G_W l. lVL lVL l. l. l. l. l. l. S_R G_W l. l. l. l. lVL lVL l. l. l. S_W G_W l. lVL lVL l. lVL lVL l. lVL lVL S_R|W G_R|W l. l. lVL l. l. l. l. l. l. S_R G_R|W l. l. l. l. l. lVL l. l. l. S_W G_R|W l. l. lVL l. l. lVL l. l. lVL S_R|W Количество строк в файлах /proc/locks До запуска 1С на wkst1 и wkst2 wkst1 5 wkst2 15 server 2405 После запуска 1С на wkst1 wkst1 806 wkst2 15 server 3189 После запуска 1С на wkst2 и появления сообщения "Программа была завершена аварийно..." wkst1 806 wkst2 567 server 3956 После закрытия 1С по нажатию кнопки "ОК" в диалоге сообщения об ошибке на wkst2 wkst1 806 wkst2 15 server 3189 При запуске 1С пользователями usr1, usr2 на одной рабочей станции wkst1 - все нормально.
(In reply to comment #0) [...] > Опробовано в нескольких вариантах (все > системы с последними обновлениями): > server, wkst1, wkst2 - CentOS 5.3 > server, wkst1, wkst2 - Fedora 11 > server - Fedora 9, wkst1, wkst2 - CentOS 5.3 Подскажите, какие версии ядер в последних обновлениях? > NFS настраивался в соответствии с > инструкциями в manual.html, http://www.bog.pp.ru/work/NFS.html Тут всё туманно, то как там описано можно в разных вариациях сделать. Я так понимаю основная особенность описанного в статье, состоит в том, что NFS настраивается для работы по фиксированным портам. У вас так настроено? > 1С используется только в Linux. На сервер server > 1С не запускается (только экспорт NFS). > > Опции экспорта NFS: > rw,no_root_squash,async,insecure,no_subtree_check,acl > Опции монтирования NFS: > nosuid,nodev,soft,udp,rsize=8192,wsize=8192,acregmin=30,noatime,nodiratime > > На сервере запущены службы: > CentOS 5.3: portmap, nfslock, nfs > Fedora: rpcbind, nfslock, nfs > На клиентах запущены службы: > CentOS 5.3: portmap, nfslock > Fedora: rpcbind, nfslock Приведите, пожалуйста, вывод команды: # rpcinfo -p для каждого из тестируемых хостов. > Не работает с версиями WINE@Etersoft: > 1.0.10 (wine-etersoft-1.0.10-eter23, wine-etersoft-network-1.0.10-eter16) > 1.0.10 (wine-etersoft-1.0.10-eter25, wine-etersoft-network-1.0.10-eter18) Для старых версий кто-нибудь проверял? Работало же... > При запуске 1С пользователями usr1, usr2 на > одной рабочей станции wkst1 - все нормально. > OK, будем смотреть.
(In reply to comment #1) > (In reply to comment #0) > [...] > Подскажите, какие версии ядер в последних > обновлениях? CentOS 5.3: kernel-PAE-2.6.18-128.1.10 Fedora 9: kernel-PAE-2.6.27.24-170.2.68 Fedora 11: kernel-PAE-2.6.29.4-167 > Тут всё туманно, то как там описано можно в > разных вариациях сделать. Я так понимаю > основная особенность описанного в статье, > состоит в том, что NFS настраивается для > работы по фиксированным портам. У вас так > настроено? На самом деле, Вашей документации подобная "туманность" не помешала бы, т.к. в manual.html описание работы по NFS несколько непоследовательное и без рекомендаций (в одной строке у Вас используются опции sync,wdelay в другой async; упоминается только portmap, в то время как начиная с Fedora 8 он заменен на rpcbind и т.д.). Могу только сказать, что с данной проблемой я безрезультатно обращался на support@etersoft.ru и за неделю успел просмотреть кучу материала по тонкостям настройки NFS, предлагаемых патчах к ядру (для нормальной работы lockd на multihomed хостах) и списков рассылки по проблемам с блокировками NFS. А также попробовать различные варианты настройки и различные системы. По поводу фиксированных портов - пробовал и с фиксированными портами и без: результат все тот же. При проверке на Fedora 11 использовались машины, имеющие по одному сетевому интерфейсу и по одному IP адресу. > Приведите, пожалуйста, вывод команды: > # rpcinfo -p > для каждого из тестируемых хостов. CentOS 5.3 (NFS сервер) 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 10002 status 100024 1 tcp 10002 status 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100021 1 udp 43920 nlockmgr 100021 3 udp 43920 nlockmgr 100021 4 udp 43920 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100021 1 tcp 35887 nlockmgr 100021 3 tcp 35887 nlockmgr 100021 4 tcp 35887 nlockmgr 100005 3 udp 10004 mountd 100005 3 tcp 10004 mountd CentOS 5.3 (NFS клиент) 100000 2 tcp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 10002 status 100024 1 tcp 10002 status 100021 1 udp 39377 nlockmgr 100021 3 udp 39377 nlockmgr 100021 4 udp 39377 nlockmgr Fedora 9 (NFS сервер) 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 10002 status 100024 1 tcp 10002 status 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100021 1 udp 10001 nlockmgr 100021 3 udp 10001 nlockmgr 100021 4 udp 10001 nlockmgr 100021 1 tcp 10001 nlockmgr 100021 3 tcp 10001 nlockmgr 100021 4 tcp 10001 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100005 3 udp 10004 mountd 100005 3 tcp 10004 mountd Fedora 11 (NFS сервер) 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 32931 status 100024 1 tcp 39369 status 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 4 udp 2049 nfs 100021 1 udp 53314 nlockmgr 100021 3 udp 53314 nlockmgr 100021 4 udp 53314 nlockmgr 100021 1 tcp 35476 nlockmgr 100021 3 tcp 35476 nlockmgr 100021 4 tcp 35476 nlockmgr 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100003 4 tcp 2049 nfs 100005 1 udp 47836 mountd 100005 1 tcp 35380 mountd 100005 2 udp 47836 mountd 100005 2 tcp 35380 mountd 100005 3 udp 47836 mountd 100005 3 tcp 35380 mountd Fedora 11 (NFS клиент) 100000 4 tcp 111 portmapper 100000 3 tcp 111 portmapper 100000 2 tcp 111 portmapper 100000 4 udp 111 portmapper 100000 3 udp 111 portmapper 100000 2 udp 111 portmapper 100024 1 udp 42157 status 100024 1 tcp 51962 status 100021 1 udp 52923 nlockmgr 100021 3 udp 52923 nlockmgr 100021 4 udp 52923 nlockmgr 100021 1 tcp 43392 nlockmgr 100021 3 tcp 43392 nlockmgr 100021 4 tcp 43392 nlockmgr > > Не работает с версиями WINE@Etersoft: > > 1.0.10 (wine-etersoft-1.0.10-eter23, wine-etersoft-network-1.0.10-eter16) > > 1.0.10 (wine-etersoft-1.0.10-eter25, wine-etersoft-network-1.0.10-eter18) > > Для старых версий кто-нибудь проверял? > Работало же... Если возникнут вопросы по воспроизведению ситуации - я на них отвечу. > OK, будем смотреть. Спасибо.
Возможно, эта информация будет полезна. При включении отладки (echo 32767 > /proc/sys/sunrpc/nlm_debug) видно, что несколько вызовов блокировки не успешны (LOCK status 1). Ниже пример из /var/log/messages kernel: lockd: request from 10.111.100.3, port=714 kernel: lockd: LOCK called kernel: lockd: nlmsvc_lookup_host(host='wkst2', vers=4, proto=udp) kernel: lockd: get host wkst2 kernel: lockd: nlm_lookup_host found host wkst2 (10.111.100.3) kernel: lockd: nsm_monitor(wkst2) kernel: lockd: nlm_lookup_file (01070001 00010002 00000000 655cf276 5c477fb6 95341896 24a95828 00004195) kernel: lockd: found file cadb73c0 (count 0) kernel: lockd: nlmsvc_lock(sda1/16789, ty=1, pi=23, 10000000-10000000, bl=0) kernel: lockd: nlmsvc_lookup_block f=cadb73c0 pd=23 10000000-10000000 ty=1 kernel: lockd: get host wkst2 kernel: lockd: created block cb059d00... kernel: lockd: vfs_lock_file returned -11 kernel: lockd: freeing block cb059d00... kernel: lockd: release host wkst2 kernel: lockd: nlm_release_file(cadb73c0, ct = 2) kernel: lockd: nlmsvc_lock returned 16777216 kernel: lockd: LOCK status 1 kernel: lockd: release host wkst2 kernel: lockd: nlm_release_file(cadb73c0, ct = 1) Обратите внимание на параметр bl=0 вызова nlmsvc_lock: при попытке блокировки ядро возвращает -11 (-EAGAIN). В коде kernel-src/fs/lockd/svclock.c происводится проверка параметра wait и при значении 0 (bl=0 выше) вызов nlmsvc_lock возвращает nlm_lck_denied, а при других значениях nlm_lck_blocked.
Баг воспроизводится. База в /var/ftp/tmp/amorozov/test2. Из вывода mount на cellar: server:/var/ftp/tmp on /var/ftp/tmp type nfs (rw,bg,soft,udp,rsize=8192,wsize=8192,timeo=14,intr,nfsvers=3,addr=192.168.0.1) Из вывода mount на atlant: server:/var/ftp/tmp on /var/ftp/tmp type nfs (rw,addr=192.168.0.1) Запускаем 1С 7.7 в бутылке на cellar и заходим в базу. Запускаем 1C 7.7 на atlant и при входе в базу получаем сообщение о том, что программа была завершена аварийно и надо запустить её в монопольном режиме. При этом в монопольном режиме с atlant зайти можно.
Если запускать две 1С 7.7 в одном wine-окружении, то блокировки работают. Winelocktest от root также работает (насколько я понял, это вариант с 2-мя wine-окружениями на одной машине).
Если одна 1С работает на той же машине, где находится база, а другая использует базу по nfs, то проблема также воспроизводится. Проверил на server и cellar.
(In reply to comment #5) > Если запускать две 1С 7.7 в одном > wine-окружении, то блокировки работают. > Winelocktest от root также работает (насколько я > понял, это вариант с 2-мя wine-окружениями на > одной машине). > 2 и более wine-окружения (т.е. 2 и более пользователей) на одной машине (NFS-клиенте) работают.
Доработал winelocktest так, чтобы его можно было запускать на разных машинах (не закоммитил, так как с git.office.etersoft.ru что-то случилось). Мастер на atlant, слэйв на cellar, NFS на server: Start test as MASTER for lockfile.wine file... Info: Running on NFS filesystem G_R G_R G_R G_W G_W G_W G_R|W G_R|W G_R|W S_R S_W S_R|W S_R S_W S_R|W S_R S_W S_R|W G_R uVX uCX uVX uCL uCL uCL uCL uCL uCL S_R G_R uCX uCX uCX uVL uCL uVL uCL uCL uCL S_W G_R uVX uCX uVX uVL uCL uVL uVL uCL uVL S_R|W G_W u. lVL lVL l. l. l. l. l. l. S_R G_W l. l. l. l. lVL lVL l. l. l. S_W G_W l. lVL lVL l. lVL lVL l. lVL lVL S_R|W G_R|W lCL lCL lVL lCL lCL lCL lCL lCL lCL S_R G_R|W lCL lCL lCL lCL lCL lVL lCL lCL lCL S_W G_R|W lCL lCL lVL lCL lCL lVL lCL lCL lVL S_R|W В случае, когда мастер и NFS на server, а слэйв на atlant таблица такая же.
Мастер на atlant, слэйв и NFS на server: Start test as MASTER for lockfile.wine file... Info: Running on NFS filesystem G_R G_R G_R G_W G_W G_W G_R|W G_R|W G_R|W S_R S_W S_R|W S_R S_W S_R|W S_R S_W S_R|W G_R lVL l. lVL l. l. l. l. l. l. S_R G_R l. l. l. lVL l. lVL l. l. l. S_W G_R lVL l. lVL lVL l. lVL lVL l. lVL S_R|W G_W l. lVL lVL l. l. l. l. l. l. S_R G_W l. l. l. l. lVL lVL l. l. l. S_W G_W l. lVL lVL l. lVL lVL l. lVL lVL S_R|W G_R|W l. l. lVL l. l. l. l. l. l. S_R G_R|W l. l. l. l. l. lVL l. l. l. S_W G_R|W l. l. lVL l. l. lVL l. l. lVL S_R|W
Удалось найти работающую связку: Server cellar 2.6.27-ovz-smp-alt7 Client1 alt41vb 2.6.25-std-def-alt8 Client2 локальная учетная запись. Блокировки работают.
Написал пару простых программ: wine-etersoft-devel/locks/linlock и lockinfo. Первая устанавливает блокировку на файл, вторая выводит информацию об установленных блокировках. Из вывода mount на atlant: server:/var/ftp/tmp on /var/ftp/tmp type nfs (rw,bg,soft,udp,rsize=8192,wsize=8192,timeo=14,intr,nfsvers=3,addr=192.168.0.1) Если на server мы устанавливаем read-блокировку на файл, то на atlant с помощью F_GETLK её не видно, но при этом поставить write-блокировку нельзя: [amorozov@server test]$ ./linlock r test_file press Ctrl-C... [amorozov@atlant test]$ ./lockinfo test_file F_UNLCK SEEK_SET start 0 len 0 [amorozov@atlant test]$ ./linlock w test_file fcntl: Resource temporarily unavailable Если поменять машины местами, то всё работает: [amorozov@atlant test]$ ./linlock r test_file press Ctrl-C... [amorozov@server test]$ ./lockinfo test_file F_RDLCK SEEK_SET start 0 len 0 pid 7220
Создал баг: https://bugzilla.altlinux.org/show_bug.cgi?id=20694
а на всяких там убунтах и федорах работает на .30 ядре?
> а на всяких там убунтах и федорах работает > на .30 ядре? Это ты к тому, почему именно в багзиллу AltLinux-а баг добавлен? Просто я на AltLinux-е проверял, но наверняка баг и в других дистрибутивах есть.
Ускорил работу winelocktest через NFS.
Если в закрытой части в getc_lock() вместо F_GETLK использовать F_SETLK с дескриптором, открытым на запись специально для проверки блокировок, то можно получить вот такой результат: Start test as MASTER for lockfile.wine file... Info: Running on NFS filesystem G_R G_R G_R G_W G_W G_W G_R|W G_R|W G_R|W S_R S_W S_R|W S_R S_W S_R|W S_R S_W S_R|W G_R uVX u. uVX u. u. u. u. u. u. S_R G_R u. u. u. uVL u. uVL u. u. u. S_W G_R uVX u. uVX uVL u. uVL uVL u. uVL S_R|W G_W u. lVL lVL l. l. l. l. l. l. S_R G_W l. l. l. l. lVL lVL l. l. l. S_W G_W l. lVL lVL l. lVL lVL l. lVL lVL S_R|W G_R|W l. l. lVL l. l. l. l. l. l. S_R G_R|W l. l. l. l. l. lVL l. l. l. S_W G_R|W l. l. lVL l. l. lVL l. l. lVL S_R|W Мастер на cellar, слэйв на atlant, NFS на server.
То, что встречаются X, по-видимому, связано с использованием F_GETLK в set_unix_lock() при выполнении условия (fd->access == FILE_GENERIC_READ && type == F_WRLCK).
Сегодня прогнал с помощью rect тесты на NFS. Ни один тест на блокировки не проходит. ====================================================================== ERROR: Set a write lock on a write lock (Denied) (shares: ['share1'], slaves: ['slave1']) ---------------------------------------------------------------------- Traceback (most recent call last): File "/usr/share/rect-tests/SetLock.py", line 113, in testSetWriteLockOnWriteLock file1.lock(Lock(LockRange(0, 500), LockType.LOCKWRITE)) File "/usr/lib/python2.5/site-packages/RECT/api.py", line 92, in lock return self._prx.setLock(l) File "/usr/share/rect/slice/linux.ice", line 649, in setLock Error: exception ::RectIce::Linux::Error { reason = No locks available code = 37 } Системный вызов возвращает ошибку. Думаю, что копать стоит в сторону совместимости NFS'ных утилит и ядерных модулей.
(In reply to comment #18) > Сегодня прогнал с помощью rect тесты на NFS. > Ни один тест на блокировки не проходит. Ну тут уж может всё же что-то с lockd? ... > reason = No locks available > code = 37 > } > > Системный вызов возвращает ошибку. > > Думаю, что копать стоит в сторону > совместимости NFS'ных утилит и ядерных > модулей. Есть интересный ресурс, где собрано всё по NFS, думаю, надо плясать от него. http://wiki.linux-nfs.org/wiki/index.php/Testing_tools Думаю, правильной стратегией будет не копание в коде и программах, а собирание доказательной базы с целью аргументировнано обратить внимание сообщества на проблему.
Реализовал воркэраунд, не использующий F_GETLK. Start test as MASTER for lockfile.wine file... Info: Running on NFS filesystem G_R G_R G_R G_W G_W G_W G_R|W G_R|W G_R|W S_R S_W S_R|W S_R S_W S_R|W S_R S_W S_R|W G_R uVL u. uVL u. u. u. u. u. u. S_R G_R u. u. u. uVL u. uVL u. u. u. S_W G_R uVL u. uVL uVL u. uVL uVL u. uVL S_R|W G_W u. lVL lVL l. l. l. l. l. l. S_R G_W l. l. l. l. lVL lVL l. l. l. S_W G_W l. lVL lVL l. lVL lVL l. lVL lVL S_R|W G_R|W l. l. lVL l. l. l. l. l. l. S_R G_R|W l. l. l. l. l. lVL l. l. l. S_W G_R|W l. l. lVL l. l. lVL l. l. lVL S_R|W Мастер на atlant, слэйв на cellar, NFS на server.
Исправил работу winelocktest в Network Lite. Доработал функцию set_concurlock(), ответственную за ограничение на число совместно работающих пользователей. Проверял только на NFS.
Тест не проходит, но в 1С блокировки работают. winelocktest -s connect: Connection refused connect: Connection refused err:usbhub:usbhub_internal_ioctl could not set config 1: Device or resource busy err:usbhub:usbhub_internal_ioctl could not set config 1: Device or resource busy err:usbhub:usbhub_internal_ioctl could not set config 1: Device or resource busy Check N:SBDemo in single user mode... Checked: This filesystem in usual, case sensitivity mode Start test as SLAVE for lockfile.wine file... Test failed: couldn't create file "lockfile.wine" (err=32): Sharing violation Test failed: couldn't create file "lockfile.wine" (err=32): Sharing violation !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! WINE LOCK TEST FAILED for /home/baraka/.wine/dosdevices/n:/1SBDemo! (see table above) !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> Тест не проходит На каких машинах это можно увидеть?
(In reply to comment #23) > > Тест не проходит > > На каких машинах это можно увидеть? > Это модно увидеть на cellar, например в 2 бутылках: 1c77/1c7727, 1c77/1c77-27; там есть диски l:, которые ссылаются на смонтированный по NFS ресурс.
> Это модно увидеть на cellar, например в 2 > бутылках: 1c77/1c7727, 1c77/1c77-27; там есть диски l:, > которые ссылаются на смонтированный по NFS > ресурс. Проверил. Winelocktest нормально работает.
NFS по прежнему работает в 1С77 и тупит или не работает при запуске winelocktest.
WINE@Etersoft 1.0.11 eter3/eter2 winelocktest корректно проходит проверку, совместный режим в разных вариантах (NFS-NFS, NFS-local) работает
