Telegraf: inputs.disk with mount_points errors in 1.12.x

Created on 12 Sep 2019  路  11Comments  路  Source: influxdata/telegraf

Relevant telegraf.conf:

[[inputs.disk]]
  mount_points = [
    "/hostfs/vol/ssd/0_400G",
    "/hostfs/vol/hdd/0_3T",
    "/hostfs/vol/hdd/2_1T",
    "/hostfs/vol/hdd/3_4T",
    "/hostfs/vol/hdd/4_4T",
  ]

System info:

  • works: telegraf 1.11.5 (1.11.x all work) via official docker
  • fails: telegraf 1.12.1 (1.12.0 also fails) via official docker

Steps to reproduce:

  1. start telegraf with above config

Expected behavior:

works as before

Actual behavior:

2019-09-12T19:21:40Z E! [inputs.disk] Error in plugin: error getting disk usage info: lstat /dev/mapper/vol_ssd_0_400G_crypt: no such file or directory
bug regression upstream

Most helpful comment

I copied my config and only ran disk and output to stdout. I mounted the binaries from /usr/bin of tarball via: -v /root/telegraf:/usr/bin/telegraf:ro and ran latest (1.12.1) docker image.

With the binary override mount proper output was generated:

disk,device=mapper/vol_hdd_2_1T_crypt,fstype=ext4,mode=ro,path=/vol/hdd/2_1T used=18886762496i,used_percent=2.0234354188704478,inodes_total=61054976i,inodes_free=61010063i,inodes_used=44913i,total=983427665920i,free=914514042880i 1568346480000000000

Without the binary override mount it failed like normal:

[inputs.disk] Error in plugin: error getting disk usage info: lstat /dev/mapper: no such file or directory

As such I can confirm your build works.

All 11 comments

How are you starting the container, are there any environment variables set?

From inside the docker container, on both 1.11.5 and 1.12.1, run:

cat /proc/self/mountinfo
ls -l /dev/mapper/
...
  --privileged \
  -v /srv/telegraf:/etc/telegraf:ro \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /:/hostfs:ro \
  -e HOST_MOUNT_PREFIX=/hostfs \

As expected nothing in dev_mapper in either version as the mount setup is identical, just telegraf is now expecting more.

I believe this is fixed upstream by https://github.com/shirou/gopsutil/commit/93e08ea089e8ede9d53a3d345ea4384b08e86ee2.

If I get you a telegraf binary with the fix included would you be able to test it? Probably will want to just mount it over the telegraf in the container.

Here is a build for testing the fix (ignore the wrong version number, this is the latest from the 1.12.x branch):

If I get you a telegraf binary with the fix included would you be able to test it?

Yes, I can do that.

I copied my config and only ran disk and output to stdout. I mounted the binaries from /usr/bin of tarball via: -v /root/telegraf:/usr/bin/telegraf:ro and ran latest (1.12.1) docker image.

With the binary override mount proper output was generated:

disk,device=mapper/vol_hdd_2_1T_crypt,fstype=ext4,mode=ro,path=/vol/hdd/2_1T used=18886762496i,used_percent=2.0234354188704478,inodes_total=61054976i,inodes_free=61010063i,inodes_used=44913i,total=983427665920i,free=914514042880i 1568346480000000000

Without the binary override mount it failed like normal:

[inputs.disk] Error in plugin: error getting disk usage info: lstat /dev/mapper: no such file or directory

As such I can confirm your build works.

I copied my config and only ran disk and output to stdout. I mounted the binaries from /usr/bin of tarball via: -v /root/telegraf:/usr/bin/telegraf:ro and ran latest (1.12.1) docker image.

With the binary override mount proper output was generated:

disk,device=mapper/vol_hdd_2_1T_crypt,fstype=ext4,mode=ro,path=/vol/hdd/2_1T used=18886762496i,used_percent=2.0234354188704478,inodes_total=61054976i,inodes_free=61010063i,inodes_used=44913i,total=983427665920i,free=914514042880i 1568346480000000000

Without the binary override mount it failed like normal:

[inputs.disk] Error in plugin: error getting disk usage info: lstat /dev/mapper: no such file or directory

As such I can confirm your build works.

hi, i had the same problem:
[inputs.disk] Error in plugin: error getting disk usage info: lstat /dev/mapper: no such file or directory.
how did you solve this problem? thanks

Yea im also having that problem on the latest docker container

Same! Can we get a new docker release with the fix please?

I believe this will be going out in the release on Tuesday. If you are unable to wait that long,
consider using a nightly build which should also work.

Closed in #6389

Was this page helpful?
0 / 5 - 0 ratings