Restarting docker container cannot not resume upload?

[jeremyj]

Hello,

I have a tusd container running behind an nginx reverse proxy container.
If I restart the tusd container I am unable to resume the upload from the client and I see this error message on the server:

[tusd] 2020/11/03 15:03:01 event="RequestIncoming" method="HEAD" path="75acb5b1a190876bb8a8c35f7ba0b3ab" requestId="" 
[tusd] 2020/11/03 15:03:01 event="ResponseOutgoing" status="423" method="HEAD" path="75acb5b1a190876bb8a8c35f7ba0b3ab" error="file currently locked" requestId="" 

I would imagine that the server shutdown would delete the lock, but instead it is still there.

So how can I avoid this problem?

I am running tusproject/tusd:v1.4.0 and the following command

command: ["-behind-proxy","-hooks-http","http://frontend:80/internal/tus/hook","-upload-dir","/var/www/media/storage/tus"]

Thanks for any suggestions

[Acconut]

That's weird. The lock files contain the PID of the tusd process that created the lock file. If the process with this PID does not exist anymore, the lock file should be automatically be removed when an upload resume. So, usually when you restart tusd, its PID changes and the lock file are not an issue. Does another process with the PID from the lock files exist on your system?

[jeremyj]

OK I think the problem is the fact that tusd always runs as PID 1 in containers.
There is a --pid="" switch to docker run which allows the host's PID namespace inside the container. Ill try and see if I can work around the issue.

[jeremyj]

So apparently that switch does not work in docker swarm, which I'm using (docker/docs#5624).

Do you know of some other external locking mechanism that is not implemented using PID?

[Acconut]

Do you know of some other external locking mechanism that is not implemented using PID?

There is https://github.com/tus/tusd-etcd3-locker. If only one tusd instance is accessing the upload directory, you can also simply remove all *.lock files in the upload directory.

So apparently that switch does not work in docker swarm

That's good to know!

[jeremyj]

If only one tusd instance is accessing the upload directory, you can also simply remove all *.lock files in the upload directory.

I have multiple instances running behind a load balancer with sticky sessions. Furthermore the application makes sure that an upload is always accessed by only one client, so I guess I could do without locks all together.

Is there a way to disable them?

[Acconut]

No, there is currently no way to disable locks and we don't have plans to make them optional in the future. I am currently working on some changes allowing tusd to unlock uploads which are locked by other instances (in a safe manner, of course) but that is not completed yet.

[jeremyj]

OK thanks for the clarification.
At the moment we have implemented a solution that deletes the locks in the shared upload directory when a container starts. This is far from optimal but it gets the job done.