What is the expected behaviour of the disk input plugin for systemd automounted drives?

Telegraf
1

I have an NFS share which is configured with x-systemd.automount in the fstab file. Since I also have in fstab the parameter x-systemd.idle-timeout=10 , I expect my drive to unmount automatically again until needed.

I want to use the inputs.disk plugin to monitor the disk usage of this NFS drive. Do I expect that the inputs.disk plugin is able to remount the drive in order to collect the metric?

I have mentioned this here, but am still struggling to get clarification.

In the “Bug fixes” for V1.5 here, I see “Always ignore autofs filesystems in disk input.” Is this relevant for what I am asking, or is this simply about ignoring already-mounted drive which have the tag “aufs” ?

Please advise. Thank you.

2

@teeeeee I can clarify the expected behaviour of the Telegraf disk input plugin with systemd automounted NFS drives.

The disk input plugin will NOT automatically remount your NFS drive to collect metrics. Here’s why:

How the Plugin Works

The disk input plugin operates by:

  1. Reading the current mount table from /proc/self/mounts (on Linux)
  2. Making statfs system calls on already-mounted filesystems
  3. Only collecting metrics from filesystems that are currently mounted

Behavior with Automounted Drives

For your NFS share configured with x-systemd.automount and x-systemd.idle-timeout=10:

  • When mounted: The plugin will detect the NFS mount and collect disk usage metrics normally
  • When unmounted (after the 10-second idle timeout): The plugin will not see the filesystem in /proc/self/mounts and therefore won’t collect any metrics for it
  • No automatic remounting: The plugin does not perform any operations that would trigger systemd to remount the drive

The “autofs” Bug Fix Clarification

The bug fix you mentioned - “Always ignore autofs filesystems in disk input” - is indeed relevant to your situation. This change means:

  • Filesystems with fstype=autofs are automatically ignored
  • This prevents the plugin from trying to stat autofs mount points, which could potentially trigger unwanted mounts
  • However, once your NFS share is actually mounted (triggered by other access), it will have fstype=nfs or similar, not autofs, so it will be monitored normally

Recommendations

If you want continuous monitoring of your NFS share:

  1. Remove the idle timeout or set it to a longer value if the drive should remain mounted
  2. Accept intermittent metrics - only collect data when the drive is actively mounted
  3. Use a separate health check - implement a simple script that periodically accesses the NFS share to keep it mounted if continuous monitoring is required

The plugin is designed to be non-intrusive and won’t trigger filesystem operations that could cause unwanted side effects like automatic mounting.

3

Thanks for your comments here. It’s helpful.

The reason for having an idle timeout because I thought it’s nicer to have the drive unmount when not used, and to re-mount whenever needed. This would help avoid stale mounts, or in case of any problem with the server/connection then the drive would attempt a remount when it was needed by telegraf. It was more an attempt at protecting against problems/disconnections.

This is a possible route, but there are some subtleties I think. The issue is that when you bind mount the drive into the telegraf docker container, with this configuration for example:

docker run -d \
--name telegraf_container \
--user 1001:1001 \
--network docker_monitoring_network \
--mount type=bind,source=/,destination=/hostfs \
--mount type=bind,source=/mnt/nfs/SSD_240GB/backups/TIG_backups/telegraf_backups,destination=/mnt/nfs/SSD_240GB/backups/TIG_backups/telegraf_backups \
-e HOST_MOUNT_PREFIX=/hostfs \
-e HOST_PROC=/hostfs/proc \
telegraf:latest

then if the original drive on the host is unmounted (e.g. by the idle-timeout) then it does NOT disappear from the container. This is because they are two separate mounts for the same filesystem (one mount on the host, and a second independent one for the bind mount into the container). And only the mount on the host has the autofs layer (with the container mount being a regular mount with no special autofs properties).

However, it seems that if I don’t bind mount the drive into the container explicitly, but instead mount the entire host filesystem (which includes the mounted NFS drive), as recommended in the disk input plugin docs, like this:

docker run -d \
--name telegraf_container \
--mount type=bind,source=/,destination=/hostfs \
-e HOST_MOUNT_PREFIX=/hostfs \
-e HOST_PROC=/hostfs/proc \
telegraf:latest

then it behaves differently. In this case, when the drive is mounted/unmounted automatically on the host, then this propagates into the docker container. It seems to be in this case that the drive is a recursive bind mount with slave propagation mode. I had this discussion with a user here.

So, it seems like if I want it to work in this way (with the idle-timeout and a periodic accessing script as you proposed), then this needs to be done on the host rather than in the container, and secondly I need the disk input plugin to be monitoring the mount at /hostfs/mnt/nfs/, rather than /mnt/nfs with a bind mount.

Is this broadly what you would expect?