Видимо какой-то специфичный sshfs глюк. А почему не nfs? Это же именно юз кейс для nfs.

Так было до меня настроено.Видимо sshfs идет как часть решения ltsp сервера. Если нужны какая информация по версиям, логам и т.д. могу предоставить. Временно сбойных пользователей перевели на firefox, пока работают.

по симптомам, видимо, у хромого тяжелый io при работе с профилем и это наслаивается на sshfs. какая фс на сервере, какой диск? ванговать можно начиная с битой памяти заканчивая бэдами на диске.

На сервере у раздела /home ext4/. Диск не при чем - для сотрудницы, у которой проявлялась проблема делал 2-х новых пользователей. На одном вчера нормально работала, сегодня поймала ошибку. На втором, которого сделали сегодня, ошибка воспроизвелась минут через 10 работы. На Firefox такого не замечено.

По поводу io Хрома - остальной офис работает на тех же условиях - и ни у кого проблем больше нет.

Работают на бездисковых моноблоках. Моноблок сотруднице тоже менял - эффекта 0.

Находящееся под sshfs ssh-соединение отваливается по тайм-ауту? Ты проверял, доступна ли шара после падения хрома? Попроси сотрудника позвать тебя когда хром упадёт и ничего не трогать пока ты не проверишь.

Не по таймауту. Как я и написал - отваливается если сделать в хроме восстановление вкладок. Проверял лично. Шара не доступна. Можно umount -l отмонтировать и примонтировать заново, но чрез некоторое время работы хрома отваливается опять. Я грешил на кэш, поскольку он давно не чистился. Удалил папку .cache/google-chrome/default. На время помогло.

Для понимания - хром крашится как раз таки из-за того, что отваливается шара. Я пытаюсь понять, каким образом хром вызывает падение шары.

sshfs вроде есть fuse, а там был какой то общий интерфейс для логгирования, может включить и посмотреть из-за чего шара по мнению fuse отваливается?

проблема с записью в файл.

Монтирую директорию командой sshfs operator_21@servername:/home/operator_21 /home/operator_21 -o reconnect,allow_other,uid=1022,gid=1022,ServerAliveInterval=15, debug -C >> /home/ltspadm/sshfs_log В терминал начинает выводится лог дебага. Но, когда происходит краш и команда завершается,файл sshfs_log пустой.

Что можно сделать?

Поставить ulimit -c unlimited и посмотреть в корку?

В общем - алгоритм действий примерно такой(на примере бубунты):

sudo apt install sshfs-dbg -y
sudo sysctl kernel.core_pattern=core-%e-%s-%u-%g-%p-%t
ulimit -c unlimited
<твоя команда sshfs> -f
# ждём падения
gdb  $(which sshfs) -c core-sshfs* --batch -ex "bt" -ex "thread apply all bt"

Если лоровские аналитики не помогут, пишем баг авторам sshfs с приложением корки, указанием версии sshfs, дистра и платформы.

Добавь ещё тэги fuse и c, что бы знающий народ позвать, ltsp лучше убрать, дело врят ли в нём, а если и в нём это у тебя в хэдпосте написано.

Worker/CacheStorage/579544fd7d0441717f082c9eb123588966aa57ac/de3873bb-66ac-403a-a886-e1b871df060d/index-dir/the-real-index QUEUE PATH 16050 unique: 41748, success, outsize: 16 DEQUEUE PATH1 16047 (w) PATH2 16042 (w) rename /.config/google-chrome/Default/Service Worker/CacheStorage/579544fd7d0441717f082c9eb123588966aa57ac/57ab13fe-c495-4033-8bae-2b6355f66583/index-dir/temp-index /.config/google-chrome/Default/Service Worker/CacheStorage/579544fd7d0441717f082c9eb123588966aa57ac/57ab13fe-c495-4033-8bae-2b6355f66583/index-dir/the-real-index create[140341344959456] flags: 0x8241 /.config/google-chrome/Default/Service Worker/CacheStorage/579544fd7d0441717f082c9eb123588966aa57ac/ef402d60-256c-4814-9b60-b40a646740d5/index-dir/temp-index fgetattr[140341344959456] /.config/google-chrome/Default/Service Worker/CacheStorage/579544fd7d0441717f082c9eb123588966aa57ac/ef402d60-256c-4814-9b60-b40a646740d5/index-dir/temp-index unique: 41755, opcode: LOOKUP (1), nodeid: 464, insize: 59, pid: 2658 LOOKUP /.cache/google-chrome/Default/Cache/fb590f0a45c55524_0 getattr /.cache/google-chrome/Default/Cache/fb590f0a45c55524_0 unique: 41756, opcode: GETATTR (3), nodeid: 1, insize: 56, pid: 2646 getattr / unique: 41756, success, outsize: 120 unique: 41757, opcode: STATFS (17), nodeid: 82, insize: 40, pid: 2646 statfs /.config/google-chrome/Default unique: 41749, error: -2 (No such file or directory), outsize: 16 unique: 41758, opcode: CREATE (35), nodeid: 438, insize: 67, pid: 2577 create flags: 0x8241 /.config/google-chrome/Default/Service Worker/CacheStorage/579544fd7d0441717f082c9eb123588966aa57ac/69e445fd-7425-4169-8440-28d403bceffb/index-dir/temp-index 0100600 umask=0002 unique: 41755, error: -2 (No such file or directory), outsize: 16 unique: 41757, success, outsize: 96 unique: 41754, success, outsize: 16 unique: 41759, opcode: CREATE (35), nodeid: 464, insize: 75, pid: 2658 unique: 41760, opcode: STATFS (17), nodeid: 82, insize: 40, pid: 2646 DEQUEUE PATH 16050 release[140341814593472] flags: 0x8001 sshfs: fuse.c:920: unlock_path: Assertion `wnode->treelock == -1' failed.

Конец лога sshfs.

Скинь то же самое только в теге code, а то так глаза болят.

Хотя, в общем и целом, похоже известный баг fuse.

Вариантов уйма, начиная от попытки обновить fuse заканчивая сборкой fuse с патчами по ссылке. Как говориться - развлекайся.

Спасибо за ссылку, почитаю. Интересно, почему только ошибку вызывает только Хром да и не у всех.Большой объем кэша? Есть операторы у нас, у которых и по 20 вкладок закреплено, и ничего не отваливается. Да и опять же, делал новых пользователей - ошибка проявлялась у них же через день, как будто дело в самом человеке за компом.

Справится с этой проблемой в принципе не трудно, от переноса кэша хрома в оперативку до тупо использования Огнелиса)))

Я пытаюсь найти рациональное объяснение происходящему - почему только у определенных людей такая проблема.

Вот кстати второй лог, по моему - вообще ничего общего с первым(ну кроме сообщения об ошибке в конце)

writepage[140242090725264] 131072 bytes to 552960 flags: 0x0
unique: 50324, opcode: WRITE (16), nodeid: 54, insize: 131152, pid: 0
writepage[140242090725264] 131072 bytes to 684032 flags: 0x0
unique: 50325, opcode: WRITE (16), nodeid: 54, insize: 131152, pid: 0
writepage[140242090725264] 131072 bytes to 815104 flags: 0x0
unique: 50326, opcode: WRITE (16), nodeid: 54, insize: 4176, pid: 0
writepage[140242090725264] 4096 bytes to 946176 flags: 0x0
unique: 50327, opcode: WRITE (16), nodeid: 54, insize: 131152, pid: 0
writepage[140242090725264] 131072 bytes to 0 flags: 0x0
unique: 50328, opcode: WRITE (16), nodeid: 54, insize: 36944, pid: 0
   unique: 50312, success, outsize: 16
unique: 50319, opcode: FLUSH (25), nodeid: 15670, insize: 64, pid: 4044
flush[140241486949264]
   unique: 50319, success, outsize: 16
writepage[140242090725264] 36864 bytes to 131072 flags: 0x0
writepage[140242090725264] 131072 bytes to 421888 flags: 0x0
unique: 50329, opcode: FORGET (2), nodeid: 15652, insize: 48, pid: 0
FORGET 15652/1
DELETE: 15652
unique: 50330, opcode: RELEASE (18), nodeid: 15670, insize: 64, pid: 0
release[140241486949264] flags: 0x8001
unique: 50331, opcode: RENAME (12), nodeid: 463, insize: 74, pid: 4044
QUEUE PATH1 15670 (w)
      PATH2 15656 (w)
unique: 50332, opcode: ACCESS (34), nodeid: 346, insize: 48, pid: 4042
access /.config/google-chrome/Default/Service Worker/CacheStorage/579544fd7d0441717f082c9eb123588966aa57ac/ae2ba580-591c-4f14-891d-985e9a2b3dc5 00
   unique: 50332, success, outsize: 16
unique: 50333, opcode: OPEN (14), nodeid: 458, insize: 48, pid: 4042
open flags: 0x8000 /.config/google-chrome/Default/Service Worker/CacheStorage/579544fd7d0441717f082c9eb123588966aa57ac/ae2ba580-591c-4f14-891d-985e9a2b3dc5/index
   writepage[140242090725264] 131072 bytes to 290816
   unique: 50321, success, outsize: 24
unique: 50334, opcode: ACCESS (34), nodeid: 343, insize: 48, pid: 4046
access /.config/google-chrome/Default/Service Worker/CacheStorage/579544fd7d0441717f082c9eb123588966aa57ac/f3bdff14-6b08-4174-a8df-6ec3c6e93f81 00
   unique: 50334, success, outsize: 16
unique: 50338, opcode: FORGET (2), nodeid: 15655, insize: 48, pid: 0
FORGET 15655/1
DELETE: 15655
unique: 50335, opcode: RELEASE (18), nodeid: 15671, insize: 64, pid: 0
release[140241419798128] flags: 0x8001
unique: 50336, opcode: RENAME (12), nodeid: 473, insize: 74, pid: 3977
QUEUE PATH1 15671 (w)
      PATH2 15650 (w)
unique: 50339, opcode: OPEN (14), nodeid: 457, insize: 48, pid: 4046
open flags: 0x8000 /.config/google-chrome/Default/Service Worker/CacheStorage/579544fd7d0441717f082c9eb123588966aa57ac/f3bdff14-6b08-4174-a8df-6ec3c6e93f81/index
   unique: 50316, success, outsize: 16
unique: 50337, opcode: RELEASE (18), nodeid: 15661, insize: 64, pid: 0
release[140241486746080] flags: 0x8002
   NODEID: 15675
   unique: 50315, success, outsize: 144
unique: 50340, opcode: FORGET (2), nodeid: 15659, insize: 48, pid: 0
FORGET 15659/1
DELETE: 15659
unique: 50341, opcode: LOOKUP (1), nodeid: 544, insize: 59, pid: 4045
LOOKUP /.cache/google-chrome/Default/Cache/925a648cfd6306ae_0
getattr /.cache/google-chrome/Default/Cache/925a648cfd6306ae_0
unique: 50342, opcode: ACCESS (34), nodeid: 354, insize: 48, pid: 3975
access /.config/google-chrome/Default/Service Worker/CacheStorage/579544fd7d0441717f082c9eb123588966aa57ac/de3873bb-66ac-403a-a886-e1b871df060d 00
sshfs: fuse.c:920: unlock_path: Assertion `wnode->treelock == -1' failed

Ошибка в коде fuse. Ошибка многопоточного программирования, которая при определённой последовательности одновременных операций с fs приводит к возможности dead-lock, которая детектируется, и т.к. дальше работать не вариант(целостность системы нарушена), приложение падает(по задумке автора) в дебажной сборке с сообщением об ошибке, в релизной сборке могут быть разные эффекты, но скорее всего файловая подсистема ядра как-то прибивает fuse шару в итоге.

В общем, нужен либо fuse, где этот баг исправлен, либо версия sshfs, который не допускает возникновения этого бага. Есть не нулевой шанс, что самые актуальные версии одной из них просто решат проблему.

Но это не объясняет, почему эта бага проявляется на конкретных людях)))))

Это типичное поведение таких багов. Они могут проявляться стабильно в одном окружении и не проявляться годами в другом. Так же, если там например deadlock происходит в результате race condition.

Про такие ошибки говорят - «зависит от погоды на марсе» :) По хорошему, тебе надо найти баг на срабатывание этого assert'a в трекере fuse и посмотреть пофиксили ли его и в какой версии. Потом поставить эту версию всем.

Чет я седня капец какой добрый:)

https://github.com/libfuse/libfuse/commit/3a2bd4da6b0b713276528d0c818f9e7be51...

Спасибо тебе, милчеловек)

Для очистки совести - скинь версию fuse на машине с проблемой.

2.9.2

Похоже, тебе видимо нужно 2.9.4 и выше.