Для добавления к комментарию BruceCran выше причиной для моего проявления этой проблемы сейчас была устаревшая обратная петля, монтируются. Я уже проверил вывод fuser -vm
/lsof +D
, mount
и cat /proc/mounts
, проверил, работал ли некоторый старый сервер ядра nfs, выключил квоты, предпринятые (но перестал работать), a umount -f
и почти примирившийся я с отказом от времени работы 924 дней прежде наконец проверить вывод losetup
и нахождение двух устаревших configured-but-not-mounted обратных петель:
parsley:/mnt# cat /proc/mounts
rootfs / rootfs rw 0 0
none /sys sysfs rw,nosuid,nodev,noexec 0 0
none /proc proc rw,nosuid,nodev,noexec 0 0
udev /dev tmpfs rw,size=10240k,mode=755 0 0
/dev/mapper/stuff-root / ext3 rw,errors=remount-ro,data=ordered 0 0
tmpfs /lib/init/rw tmpfs rw,nosuid,mode=755 0 0
usbfs /proc/bus/usb usbfs rw,nosuid,nodev,noexec 0 0
tmpfs /dev/shm tmpfs rw,nosuid,nodev 0 0
devpts /dev/pts devpts rw,nosuid,noexec,gid=5,mode=620 0 0
fusectl /sys/fs/fuse/connections fusectl rw 0 0
/dev/dm-2 /mnt/big ext3 rw,errors=remount-ro,data=ordered,jqfmt=vfsv0,usrjquota=aquota.user 0 0
затем
parsley:/mnt# fuser -vm /mnt/big/
parsley:/mnt# lsof +D big
parsley:/mnt# umount -f /mnt/big/
umount2: Device or resource busy
umount: /mnt/big: device is busy
umount2: Device or resource busy
umount: /mnt/big: device is busy
parsley:/mnt# losetup -a
/dev/loop0: [fd02]:59 (/mnt/big/dot-dropbox.ext2)
/dev/loop1: [fd02]:59 (/mnt/big/dot-dropbox.ext2)
parsley:/mnt# losetup -d /dev/loop0
parsley:/mnt# losetup -d /dev/loop1
parsley:/mnt# losetup -a
parsley:/mnt# umount big/
parsley:/mnt#
Хинду сообщение форума также перечисляет своп-файлы как потенциального преступника; хотя свопинг в файлы, вероятно, довольно редок в эти дни, не может повредить проверять вывод cat /proc/swaps
. Я не уверен, могли ли квоты когда-либо предотвращать размонтирование — я хватался за соломинку.
Если файл журнала имеет поток земельного участка данных и отбрасываний соединения, то причиной является любой A. Ваш брандмауэр, имеет максимальное время сеанса TCP. B. Существует некоторый случай сброса, такой имеет отклонение в Wi-Fi.
При управлении обеими сторонами можно установить mosh: http://mosh.mit.edu/, который снова соединится, даже если Вы измените дюйм/с или поместите Ваш компьютер для сна.
С другой стороны, если поток данных имеет длинные паузы, то можно поражать макс. неактивный тайм-аут. Можно добавить это к ~/.ssh/config
Host *
TCPKeepAlive yes
Попробуйте конфигурацию SSH, как предложено ответом Georgyo. Если это не сработает, вы, вероятно, работаете против какого-то вроде ограничения времени подключения, налагаемый брандмауэром где-то. Если это так, и у вас нет способа удаления тайм-аута, вы можете попробовать использовать что-то вроде экрана, чтобы поддерживать процесс, даже когда ваша сессия SSH отключается. Я использую Byobu почти на все в любом случае.