Тут ( http://bugs.etersoft.ru/show_bug.cgi?id=2599#c25 ) я тестировал запуск 1сv8 при различных параметрах монтирования. Выяснилось, что если отключены LinuxExtensions (а при использовании linux-cifs они отключены по умолчанию), то при неуказании file_mode при монтировании шары возникает ситуация, когда процесс 1cv8.exe отжирает почти все процессорное время одного процессора и висит. Описано подробно в http://bugs.etersoft.ru/show_bug.cgi?id=2599#c7 и далее
Этот вопрос может быть объяснён тем, что по умолчанию, если эту опцию не указывать, file_mode устанавливается так: cifs/connect.c () ... <------>/* 2767 perms indicate mandatory locking support */ <------>vol->file_mode = (S_IRWXUGO | S_ISGID) & (~S_IXGRP); ... Если это сопоставить с тем, что 1cv8 активно использует блокировки внутри файла базы и уточнить семантику, которую дополнительно накладывает флаг Set-Gid на включение вынужденных блокировок, а также на то, что по умолчанию cifsmount добавляет опцию mand, включающую эти вынужденные блокировки, то что-то начинает прояснятся... Не совсем понятно почему происходит зависание... Вроде бы всё должно просто повиснуть, в крайнем случае... Но может быть всё дело в том, что wine-server, эмулирующий логику блокировок, "зависает" в долгом ожидании ресурса, в неком не предусмотренном deadlock'е? Нижу привожу выдержки мана о вынужденных блокировках. $ man fcntl ... Обязательная (mandatory) блокировка (Не-POSIX.) Описанные выше блокировки могут быть или совместные или обязательные и по умолчанию используются совместные. Чтобы использовать обязательные блокировки, они должны быть разрешены (с помощью опции "-o mand" в mount(8)) для файловой системы, содержащей файл, который должен быть заблокирован, а также разрешены для самого файла (с помощью запрещения прав на выполнение группой и установки set-GID бита в правах доступа к файлу). ... Подробнее это указано на английском $ LANG=C man fcntl ... Mandatory locks are enforced for all processes. If a process tries to perform an incompatible access (e.g., read(2) or write(2)) on a file region that has an incompatible mandatory lock, then the result depends upon whether the O_NONBLOCK flag is enabled for its open file description. If the O_NONBLOCK flag is not enabled, then system call is blocked until the lock is removed or converted to a mode that is compatible with the access. If the O_NONBLOCK flag is enabled, then the system call fails with the error EAGAIN or EWOULDBLOCK. To make use of mandatory locks, mandatory locking must be enabled both on the file system that contains the file to be locked, and on the file itself. Mandatory locking is enabled on a file system using the "-o mand" option to mount(8), or the MS_MANDLOCK flag for mount(2). Mandatory locking is enabled on a file by disabling group execute permission on the file and enabling the set-group-ID permission bit (see chmod(1) and chmod(2)). ...
Сегодня пробовали с новой опцией - forcemandatory - проблема осталась. Нужно наверное было делать проще - попробовать указать опцию nomand.
(In reply to comment #2) > Сегодня пробовали с новой опцией - forcemandatory - > проблема осталась. > Нужно наверное было делать проще - > попробовать указать опцию nomand. > Не помогло.
Думаю, что задача потеряла актуальность в связи с тем, что мы больше не отключаем LinuxExtensions.
Закрываю - решено в баге 5181. *** This bug has been marked as a duplicate of bug 5181 ***
