seaweedfs: Webdav server stops responding after saving some files
WebDav server stop responding after file with some extension was uploaded.
My configuration: I have 3 nodes in cluster. Every node runs 2 docker-container:
- official
cockroachdbcontainer for filer metadata (v.20.1.0) - my custom
seaweedfscontainer with:
- weed master -ip=b-img02 -mdir=/opt/seaweedfs/data/master -peers=b-img00:9333,b-img01:9333,b-img02:9333 -defaultReplication=200
- weed volume -ip=b-img02 -mserver=b-img00:9333,b-img01:9333,b-img02:9333 -dataCenter=b-img02 -rack=rack -dir=/opt/seaweedfs/data/
- weed filer -collection=filer -defaultReplicaPlacement=200
- weed webdav Weed version: 30GB 1.79

All works fine until I trying to upload file in filer.
In examples I create test file, upload it into filer and download from webdav.
Example#1 - all works fine
echo ok > data.html
curl -F file=@data.html http://b-img00:8888/
>> {"name":"data.html","size":3,"fid":"7,08ba03a642ff84","url":"http://b-img02:8080/7,08ba03a642ff84"}
curl -vvv http://b-img00:7333/data.html
* Trying x.x.x.x...
* TCP_NODELAY set
* Connected to b-img00 (x.x.x.x) port 7333 (#0)
> GET /data.html HTTP/1.1
> Host: b-img00:7333
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Length: 3
< Content-Type: text/html; charset=utf-8
< Etag: "161503d94245de003"
< Last-Modified: Wed, 03 Jun 2020 11:04:35 GMT
< Date: Wed, 03 Jun 2020 11:04:57 GMT
<
ok
* Connection #0 to host b-img00 left intact
curl -X DELETE -vvv http://b-img00:7333/data.html
* Trying x.x.x.x...
* TCP_NODELAY set
* Connected to b-img00 (x.x.x.x) port 7333 (#0)
> DELETE /data.html HTTP/1.1
> Host: b-img00:7333
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 204 No Content
< Date: Wed, 03 Jun 2020 11:08:15 GMT
<
* Connection #0 to host b-img00 left intact
Ok. Example#2 - I change file extention from .html to .txt
After file uploaded webdav stops to serv folder with this file (it can be downloaded via filer successfully).
Another folders in webdav works fine.
echo ok > data.txt
curl -F file=@data.txt http://b-img00:8888/
curl -vvv http://b-img00:7333/data.txt
* Trying xx.xx.xx.xx...
* TCP_NODELAY set
* Connected to b-img00 (xx.xx.xx.xx) port 7333 (#0)
> GET /data.txt HTTP/1.1
> Host: b-img00:7333
> User-Agent: curl/7.58.0
> Accept: */*
>
(( I await some time - but no response received ))
^C
curl -vvv http://b-img00:8888/data.txt
* Trying xx.xx.xx.xx...
* TCP_NODELAY set
* Connected to b-img00 (xx.xx.xx.xx) port 8888 (#0)
> GET /data.txt HTTP/1.1
> Host: b-img00:8888
> User-Agent: curl/7.58.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Accept-Ranges: bytes
< Content-Disposition: inline; filename="data.txt"
< Content-Length: 3
< Content-Type: text/plain
< Etag: "908e596f"
< Last-Modified: Wed, 03 Jun 2020 11:09:35 GMT
< Date: Wed, 03 Jun 2020 11:10:06 GMT
<
ok
* Connection #0 to host b-img00 left intact
curl -X DELETE http://b-img00:8888/data.txt
(ok)
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 27
Commits related to this issue
- file read report EOF fix https://github.com/chrislusf/seaweedfs/issues/1344 — committed to seaweedfs/seaweedfs by chrislusf 4 years ago
- webdav: return io.EOF when at end of a file fix https://github.com/chrislusf/seaweedfs/issues/1344 — committed to seaweedfs/seaweedfs by chrislusf 4 years ago
@chrislusf
My log format same as your - look at
logjson field.For
data.htmlI see logs as you:I watched a source code (I dont know GO language so sorry for my mistakes).
Webdav server used http.serveContent method. This method execute auto-detection content-type header bases on:
After this serveContent calls Seek function double times to determine size-of-content. I think this calls we see in logs.
In successfull case I see this calls, In fail case - I dont see it. So, I think problem in step#2 of content-type detection - serveContent tried to read stream, but… it is too small?
I looked for a step#1 of content-type detection. On unix host system it used some predefined extensions, and then - used 3 mime-type files. I looked this files in my docker-container, and not found any.
I mount
/etc/mime.typesfrom host system, and error is dissapier.So I think problem in Read function - maybe it have to raise some end-of-stream error? I dont know how it must work on GO.
Can you try to delete
/etc/mime.typesfile and try to repeat samples?