search

efrecon / docker-s3fs-client

Alpine-based s3fs client: mount from container, make available to other containers
BSD 3-Clause "New" or "Revised" License
173 stars 62 forks source link

Socket not connected #8

Closed vcombey closed 3 years ago

vcombey commented 3 years ago

I got 2 times

ls: /opt/s3fs/bucket: Socket not connected after a while.

relaunching the docker image fix the problem. this disconnection is really problematic for me, maybe related to that issue https://github.com/s3fs-fuse/s3fs-fuse/issues/152

gaul commented 3 years ago

Please ensure that you use the latest version 1.87 which fixes several race conditions. You can help the s3fs team diagnose the symptom by attaching gdb to the process and capturing the backtrace from the crash.

gaul commented 3 years ago

I see, s3fs-fuse/s3fs-fuse#1365 prevents using 1.87. I will try to release 1.88 in the coming weeks.

vcombey commented 3 years ago

ok thanks a lot, meanwhile, do you have any workaround? maybe using the s3fs_fuse master branch ? detect the disconnection and reconnect? but relaunching this container doesn't suffice, I need to relaunch the container which uses is also, otherwise I get: mkdir: cannot create directory '/s3data': Transport endpoint is not connected in the other container.

efrecon commented 3 years ago

s3fs-fuse 1.88 is out and I fixed a bug (c1780b0) so new images got published with corresponding tags at the docker hub. @vcombey, tell me if 1.88 fixes your problems.

vcombey commented 3 years ago

nice !, I used the master branch of s3fs-fuse since our discussion and it didn't disconnect, so it should work. will test

efrecon commented 3 years ago

Thanks! Please return here once you have tested so i can close the issue.

gaul commented 3 years ago

Glad that 1.88 helps! The upstream s3fs receives issues about the use of containers/k8s that we lack the expertise to understand. It would be great if we could collaborate to make s3fs work better in these environments.

efrecon commented 3 years ago

@gaul I think the first step would be to convert/transition this repository to become a proper implementation of a Docker volume plugin. This would involve implementing the Docker plugin API. The implementation would have to implement an HTTP server (UNIX socket or else?) following the Volume driver API.

This is something that I've always wanted to do, but the core of this repo is in shell and implementing an HTTP server in shell isn't perhaps the best way (it's possible, github has a number of examples). A possible way would be to transit to reimplementing this in go. Either solution would take time and I don't have that kind of free time right now (or an employer willing to pay for that time).

gaul commented 3 years ago

It might be good to write a blog post about the s3fs container situation. When I search for github s3fs (docker OR kubernetes) I see a lot of projects but it is not obvious which projects are popular or maintained. It would be nice for the upstream s3fs project to point at one or more of these in its README.

efrecon commented 3 years ago

I cannot claim that I am fully aware of the s3fs container situation. What I know is that at the time this project was started, there wasn't anything that worked as I wanted and relying on top of s3fs-fuse felt future-proof as the project was stable and had existed for a long time.

I am trying to maintain this project. It has served me, and apparently a few others, well. It's not as flexible as a real Docker volume plugin, but comes close enough at the expense of having to "book" a known path on the host for each volume created.

efrecon commented 3 years ago

I am closing this as the original issue is closed and this has evolved into a(n) (interesting) discussion.