При запуске Linux-клиента 1С 8.3 на NFS, при логине в базу, после длительного ожидания, пишет об ошибке блокировки "Ошибка совместного доступа к файлу 'v8stg://c:/8/DBNames'" Из strace: [pid 5551] stat("/home/lav/.1cv8/1C/1cv8/a1685f9a-f50a-11e6-c593-c8be1927c5d1/SICache/cacheStorage", {st_mode=S_IFREG|0660, st_size=1952863, ...}) = 0 [pid 5551] open("/home/lav/.1cv8/1C/1cv8/a1685f9a-f50a-11e6-c593-c8be1927c5d1/SICache/cacheStorage", O_RDWR) = 23</home/lav/.1cv8/1C/1cv8/a1685f9a-f50a-11e6-c593-c8be1927c5d1/SICache/cacheStorage> [pid 5551] fcntl(23</home/lav/.1cv8/1C/1cv8/a1685f9a-f50a-11e6-c593-c8be1927c5d1/SICache/cacheStorage>, F_GETFD) = 0 [pid 5551] fcntl(23</home/lav/.1cv8/1C/1cv8/a1685f9a-f50a-11e6-c593-c8be1927c5d1/SICache/cacheStorage>, F_SETFD, FD_CLOEXEC) = 0 [pid 5551] flock(23</home/lav/.1cv8/1C/1cv8/a1685f9a-f50a-11e6-c593-c8be1927c5d1/SICache/cacheStorage>, LOCK_SH|LOCK_NB) = 0 [pid 5551] open("/home/lav/.1cv8/1C/1cv8/a1685f9a-f50a-11e6-c593-c8be1927c5d1/SICache/cacheStorage", O_RDWR) = 25</home/lav/.1cv8/1C/1cv8/a1685f9a-f50a-11e6-c593-c8be1927c5d1/SICache/cacheStorage> [pid 5551] fcntl(25</home/lav/.1cv8/1C/1cv8/a1685f9a-f50a-11e6-c593-c8be1927c5d1/SICache/cacheStorage>, F_GETFD) = 0 [pid 5551] fcntl(25</home/lav/.1cv8/1C/1cv8/a1685f9a-f50a-11e6-c593-c8be1927c5d1/SICache/cacheStorage>, F_SETFD, FD_CLOEXEC) = 0 [pid 5551] lseek(23</home/lav/.1cv8/1C/1cv8/a1685f9a-f50a-11e6-c593-c8be1927c5d1/SICache/cacheStorage>, 0, SEEK_END) = 1952863 [pid 5551] fcntl(25</home/lav/.1cv8/1C/1cv8/a1685f9a-f50a-11e6-c593-c8be1927c5d1/SICache/cacheStorage>, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=4294967296, l_len=1}) = -1 EAGAIN (Resource temporarily unavailable) Программа, воспроизводящая проблему: #include <unistd.h> #include <fcntl.h> #include <sys/file.h> int main () { int fd1, res; struct flock lock = {F_WRLCK, SEEK_SET, 4294967296, 1}; fd1 = open("cacheStorage",O_RDWR|O_CREAT, 0664); flock(fd1, LOCK_SH|LOCK_NB); res = fcntl(fd1, F_SETLK, &lock); return 0; } Проблема в том, что 1С зачем-то ставит блокировку через flock и fcntl одновременно, и на NFS это недопустимо по какой-то причине (вообще по POSIX принято блокировок, установленных своим процессов, не видеть). Надо разбираться в причинах поведения NFS. Для 1С: нехорошо использовать flock, стоит его выкинуть.
The NFS client in 2.6.12 provides support for flock()/BSD locks on NFS files by emulating the BSD-style locks in terms of POSIX byte range locks. Other NFS clients that use the same emulation mechanism, or that use fcntl()/POSIX locks, will then see the same locks that the Linux NFS client sees. On local Linux filesystems, POSIX locks and BSD locks are invisible to one another. Thus, due to this emulation, applications running on a Linux NFS server will still see files locked by NFS clients as being locked with a fcntl()/POSIX lock, whether the application on the client is using a BSD-style or a POSIX-style lock. If the server application uses flock()BSD locks, it will not see the locks the NFS clients use. http://nfs.sourceforge.net/#faq_d10 То есть на NFS flock реализован через POSIX locks, а на локальных ФС блокировки POFIX и flock не видят друг друга. Отсюда и порблема.
NFS вроде не позволяет управлять режимом блокировки. В общем, реализация через один механизм и flock и posix lock это свойство всех сетевых ФС (проверил ещё на glusterfs), и это логично. Странно обратное, что они не пересекаются на локальных ФС. Я бы это изменил. Варианта решения два: хранить ~/.1cv8 на локальной ФС или сделать враппер, отключающий работу flock.
Сделал игнорование вызова flock: https://github.com/Etersoft/ignoreflock У нас можно запускать так: /srv/lav/Projects/git-eter/ignoreflock/ignoreflock /opt/1C/v8.3/x86_64/1cestart
Собрал в пакет, $ epmi ignoreflock
(Ответ Vitaly Lipatov на комментарий4) > Собрал в пакет, $ epmi ignoreflock https://packages.altlinux.org/ru/Sisyphus/srpms/ignoreflock
Created attachment 3529 [details] Окна, в которых путается фокус