Transport endpoint is not connected что делать
Краш NTFS-3G с последующим transport endpoint is not connected до ребута
Семь лет штабильно работал, и тут внезапно:
Почему — непонятно. Заметили аж через полчаса. Ставили примерно в тот момент обновления, но вроде ничего связанного не обновляли: ни fuse, ни glibc, mount разве что. До этого более трёх месяцев аптайма было.
Думали, раздел накрылся. Загрузились в винду, прогнали chkdsk /I D: — вроде всё чисто. Загрузились обратно — работает.
Куда это репортить-то вообще (и есть ли смысл?) Форум Tuxera анально огорожен вроде, да и глухо там. Драйвер три года не обновлялся, 1:2017.3.23AR.3-3 стоит.
Когда-то проходил через стадию дуалбута и все пользовательские данные держал на NTFS-разделе. Так вот, виндовый checkdisk периодически ругался на ошибки ФС. Изредка с раздела пропадали отдельные файлы. Поэтому, как только я освоился в Linux, так сразу переразбил диск, затерев винду. Старые данные залил на вновь созданный хомяк на XFS (сейчас везде использую ext4, но тогда мне это казалось разумным). Файлы пропадать перестали. Сейчас даже для флешек почти не использую NTFS-3G, потому как свои форматирую в ExFAT.
Насколько я понял, вы этот безусловно нужный, но до конца не доделанный и предназначенный скорее для разового использования, преимущественно в режиме чтения, инструмент зачем-то 7 лет использовали в продакшене. Думаю, вы легко отделались. Репортить, конечно, нужно. Если не добьешься исправления бага, то хотя бы сподвигнешь кого-то на принятие менее рискованных инфраструктурных решений.
NTFS-3G работает, говорили они…
Изредка с раздела пропадали отдельные файлы
зачем-то 7 лет использовали в продакшене
Да ещё и под приличной нагрузкой!
А не громко ли домашнюю машинку продакшном обзывать? Ещё и с Debian Testing?
Если не добьешься исправления бага
Так есть ли баг, вот в чём вопрос. Мало ли чего оно упало. Там вон libc старый использовался, это уже фактор UB (при том, что обновляли его месяц назад где-то, и так и не перезагрузились). Аллокация мог сфейлиться. Собственно, это само по себе не странно, вопрос скорее в том, какого хрена оно зависло до ребута и не давало читать даже ядрёному драйверу. Надо было, прежде чем грузиться в оффтопик, проверить из-под онтопика ещё раз, вдруг таки ФС сломалась, а оффтопик при загрузке молча починил.
а как же работет нитрожь?
Ваш prelockd может быть к этому причастен? OOM killer в dmesg не было точно
Хз каким образом. prelockd работает от юзера prelockd и всего-лишь аккуратно мемлочит файлы на чтение, никуда особо не вмешивается.
На дебиан у меня работает, проблем с ним не было.
как известно, прелокд ускоряет приход ядерного киллера и способствует пропуску фазы предоомного дедлока. Иногда при запуске множества tail /dev/zero падали иксы после оом. Но в основном все ок. У вас же оом не было, так что хз.
вообще-то прелокд няшка.
из-за нехватки памяти сам завалиться мог, жручий же.
How to fix permanently transport end point is not connected in S3fs #152
Comments
mitosistech commented Mar 16, 2015
I have one s3 bucket and two EC2 instance.I have mounted S3 bucket in EC2 instance.We are acessing all file of S3 bucket through our App.Now a days «Tansport end point is not connected» to s3fs is coming frequently.For fix this issue I am unmounting and mount again s3 bucket in EC2 instance.But I need the root cause of this issue.Why its coming frequently.Please help me.
The text was updated successfully, but these errors were encountered:
rehoehle commented Mar 17, 2015
I have the same problem its killing my mount point. Is there a solution its very annoying?
@mitosistech which version do you use?
mitosistech commented Mar 17, 2015
I have used s3fs 1.74
rehoehle commented Mar 17, 2015
ok 🙁 i have used the newest version 1.78.. hmm
mitosistech commented Mar 17, 2015
For you also same Tranport endpoint is not connected error?
rehoehle commented Mar 17, 2015
mitosistech commented Mar 17, 2015
boazrf commented Mar 18, 2015
mitosistech commented Mar 18, 2015
rehoehle commented Mar 18, 2015
I think your can set that parameter in your fstab file i have test it now
use allow_other,multireq_max=5 0 0
I don’t know if its correct but its working.
mitosistech commented Mar 18, 2015
But I have set use user allow_other in fuse.conf
boazrf commented Mar 18, 2015
mitosistech commented Mar 19, 2015
darrencruse commented Mar 19, 2015
Just fwiw we’ve been migrating a bunch of php content from some old apache servers to amazon s3 w/s3fs and I’d had this problem 2 or 3 times in the last few months.
But we changed our configurations to about double our load of requests on tuesday and this problem has went to happening about 2 or 3 times now per day.
Glad to see the suggestion about multireq_max am getting ready to try it.
Will this hurt performance? i.e. response times?
darrencruse commented Apr 1, 2015
Transport endpoint is not connected #169
Comments
ANaumann85 commented Jan 13, 2020
Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)
Description
podman run leads to the error message Transport endpoint is not connected after some commands.
Steps to reproduce the issue:
build an image (with base image debian:jessie-slim) and install EasyBuild
It stops after the configuration. At the moment, I cannot reduce the steps for reproduction. The error occurs only with fuse-overlayfs. I did not try without fuse (and as root).
Describe the results you received:
The installation of the easybuild configuration breaks. After the last command, I got the error message Transport endpoint is not connected
Describe the results you expected:
no error message
Additional information you deem important (e.g. issue happens only occasionally):
Output of podman version :
Additional environment details (AWS, VirtualBox, physical, etc.):
The text was updated successfully, but these errors were encountered:
mheon commented Jan 14, 2020
Is the Podman container still running after this? If so, can you attach to it again via podman attach (and if you do so, is everything back to normal?).
The error in question is ENOTCONN. I’m honestly not sure what that means in the context of a Unix socket; it certainly seems like the container or Conmon is going down, but I would expect attach to exit cleanly as the socket went down, not remain pseudo-connected and issue strange errors when we try to read from it.
ANaumann85 commented Jan 14, 2020
Yes, the container keeps running. But attaching to it does not work. I do not get any response.
Instead I tried to exec an additional shell, but then I get the error message
Error: unable to find user root: no matching entries in passwd file
There is something wrong with the filesystem inside the container.
mheon commented Jan 14, 2020
Can you check if the conmon executable is still running on the post? Also, would it be possible to run this test as root, so we can confirm this is fuse-overlayfs and kernel overlayfs is not affected?
ANaumann85 commented Jan 14, 2020
mheon commented Jan 14, 2020
giuseppe commented Jan 14, 2020
@ANaumann85 do you have a Dockerfile you could share?
ANaumann85 commented Jan 14, 2020
I was not able to reduce the error to a minmal container with only a Dockerfile. Therefore, I provide the archive transport_endpoint_not_connected.tar.gz, which contains :
What I see from the python trace is:
Transport endpoint is not connected
I currently have my mount points setup like this, I’m not sure what other details I should add here so let me know if I missed anything..
7 Answers 7
I have exactly the same problem. I haven’t found a solution anywhere, but I have been able to fix it without rebooting by simply unmounting and remounting the mountpoint.
For your system the commands would be:
fusermount: entry for /data not found in /etc/mtab
I get this error from the sshfs command from Fedora 17 linux to debian linux on the Mindstorms EV3 brick over the LAN and through a wireless connection.
This is remedied with the following command and trying again:
These additional sshfs options prevent the above error from concurring:
In order to use allow_other above, you need to uncomment the last line in /etc/fuse.conf :
There is a segmentation fault problem which was introduced in 0.1.39. You may check my repository that fixed this one meanwhile: https://github.com/vdudouyt/mhddfs-nosegfault
Now this answer is for those lost souls that got here with this problem because they force-unmounted the drive but their hard drive is NTFS Formatted. Assuming you have ntfs-3g installed (sudo apt-get install ntfs-3g).
Where hdd is the hard drive in question and the «/mnt/mount_point» directory exists.
Leaving my answer here in case this fix can aid anyone!
«transport endpoint is not connected» error after a write to a mounted volume crashes docker container. Docker Destop 2.2.0.0 #5584
Comments
plaht commented Jan 24, 2020
Expected behavior
I am able to mount a scala sbt docker image based on ubuntu to a volume and the sbt is able to create directories inside the mounted volume.
Actual behavior
I get an error that I am unable to create directory
Could not create directory /root/src/target/streams/compile/$global/$global/discoveredMainClasses
When rerunning a container, I am unable to perform basic bash operations such as «ls»
ls: cannot open directory ‘.’: Transport endpoint is not connected
Information
Steps to reproduce the behavior
The text was updated successfully, but these errors were encountered:
plaht commented Jan 24, 2020
I’ve reverted back to Docker Desktop 2.1.0.5 with no issue.
ulrich commented Jan 27, 2020 •
@plaht Really sorry for the bug, we tried to reproduce the trouble but without success. Can you give an another way to reproduce the issue via a docker public image?
Thank you again for your feedback,
plaht commented Jan 27, 2020
I will try to reproduce with a public docker image on 2.2.0.0 and revert back.
ulrich commented Jan 27, 2020 •
I will try to reproduce with a public docker image on 2.2.0.0 and revert back.
Waiting your feedback!
Thank you,
ulrich commented Jan 29, 2020
@plaht don’t hesitate to come back toward us.
Thank you.
iwilliamson commented Feb 2, 2020 •
I’m having a very similar issue using 2.2.0.0.
In my case, I have a tree of source code mounted on /src. During the compile, the volume is dropped and I can only get the «Transport endpoint is not connected» message. The only way to fix it seems to be restarting docker desktop. The log contains the following errors: