logspout crash when using block limit in docker-compose.yml
morpheuske opened this issue · 3 comments
morpheuske commented
Hi,
I have recently set up a logspout container:
version: '2.3' services: logspout: image: gliderlabs/logspout/v3.2.6 restart: unless-stopped command: 'udp://10.132.15.196:5514' mem_limit: 64m memswap_limit: 64m cpus: 0.5 environment: - "RAW_FORMAT={\"type\" : \"docker\", \"hostname\" : \"fqdn\", \"containerName\" : {{toJSON .Container.Name}}, \"labels\": {{ toJSON .Container.Config.Labels }}, \"message\" : {{ toJSON .Data }} }" - BACKLOG=false - ROUTE_URIS=udp://10.132.15.196:5514 volumes: - '/var/run/docker.sock:/tmp/docker.sock'
This works perfectly, unless you configure disk block limits on another docker(-compose) container.
https://docs.docker.com/compose/compose-file/#blkio_config
blkio_config: device_read_bps: - path: /dev/sdb rate: '1mb' device_read_iops: - path: /dev/sdb rate: 50 device_write_bps: - path: /dev/sdb rate: '1mb' device_write_iops: - path: /dev/sdb rate: 50
If you start logspout, something like this happens:
logspout_1 | 2020/01/10 12:30:58 # logspout v3.2.6 by gliderlabs logspout_1 | 2020/01/10 12:30:58 # adapters: udp multiline raw syslog tcp tls logspout_1 | 2020/01/10 12:30:58 # options : logspout_1 | 2020/01/10 12:30:58 backlog:false logspout_1 | 2020/01/10 12:30:58 persist:/mnt/routes logspout_1 | 2020/01/10 12:30:58 # jobs : pump routes http[health,logs,routes]:80 logspout_1 | 2020/01/10 12:30:58 # routes : logspout_1 | # ADAPTER ADDRESS CONTAINERS SOURCES OPTIONS logspout_1 | # raw+udp 10.132.15.196:5514 map[] logspout_1 | 2020/01/10 12:31:00 pump: json: cannot unmarshal number into Go struct field BlockLimit.Rate of type string
Thanks in advance, much appreciated.
Kind Regards,
M.
skyzh commented
Same issue here. I'm looking into this.
skyzh commented
Related issue: fsouza/go-dockerclient#625 fsouza/go-dockerclient#626
skyzh commented
This issue has been fixed in upstream fsouza/go-dockerclient in 2017. Currently logspout is using v0.0.0-20160624230725-1a3d0cfd7814. I think upgrading dependency could solve this issue.