Socket not connected about docker-s3fs-client HOT 11 CLOSED

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

from docker-s3fs-client.

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.

from docker-s3fs-client.

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.

from docker-s3fs-client.

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.

from docker-s3fs-client.

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.

from docker-s3fs-client.

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

from docker-s3fs-client.

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

from docker-s3fs-client.

@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).

from docker-s3fs-client.

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.

from docker-s3fs-client.

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.

from docker-s3fs-client.

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

from docker-s3fs-client.