telegraf container points to a folder called telegraf.conf not a file called telegraf.conf

[ryanwalexander]

error:
ERROR: for telegraf Cannot start service telegraf: OCI runtime create failed: container_linux.go:380: starting container process caused: process_linux.go:545: container init caused: rootfs_linux.go:76: mounting "/home/pi/IOTstack/services/telegraf/telegraf.conf" to rootfs at "/etc/telegraf/telegraf.conf" caused: mount through procfd: not a directory: unknown: Are you trying to mount a directory onto a file (or vice-versa)? Check if the specified host path exists and is the expected type
gcgarner#57 looks similar to this one

expected:
no error, telegraf.conf is file, not folder.

observed:
only under my sevices/telegraf/telegraf.conf folder is nothing (yes, telegraf.conf is a folder, not a file, this seems to be an error, yes?)

resolution:
after replacing the telegraf.conf folder under /services with a file called telegraf.conf with the contents here it works https://github.com/SensorsIot/IOTstack/blob/master/.templates/telegraf/telegraf.conf

[Paraphraser]

What you are seeing is the result of a few things.

Assume you have just done a clean clone of IOTstack. Now, imagine that you run the menu and select Telegraf as one of your containers.

What the screen shot is telling you is that the build.py script (which is run by the menu) takes care of copying the telegraf.conf file from the .templates directory into the services directory.

Then, when you leave the menu and execute docker-compose up -d, the file mapped in the volumes: directive of Telegraf's service definition is already present so everything works.

Now, suppose the copy of telegraf.conf in the services directory goes away (gremlins, "person or persons unknown" kind of stuff). There is no mechanism in Docker to repeat what the menu does when it copies the file from the template. Instead, the next time you run docker-compose it checks to see whether ./services/telegraf/telegraf.conf is present and, if it isn't, docker-compose automatically creates a directory at that path with root ownership. Inside the container, telegraf is expecting a valid configuration file at the path /etc/telegraf/telegraf.conf but finds it is now mapped to a directory, so it crashes and the container goes into a restart loop.

Docker's inability to run "pre-launch fix-up scripts" (like build.py) is, depending on your perspective, either a strength of, or a known weakness of, the Docker environment. Those who take the view it is a strength (including me) point the finger at containers that crash when their environment is not to their liking, rather than taking responsibility for sensible self-repair.

Mosquitto had an almost identical problem but I was able to work out how to turn Mosquitto into a well-behaved container. If you want to know a bit more, maybe read Issue 331.

Telegraf was on my to-do list to get similar treatment but I got stuck on this little conundrum:

$ wc -l *telegraf.conf
     236 IOTstack-default-telegraf.conf
    8641 official-1.19.3-telegraf.conf

I'm not a Telegraf user and a difference of 8405 lines is not something I can sort out. The most I can say is that, if I use the 8641-line file as the default, the Telegraf container comes up, doesn't moan about the config file, and doesn't go into a restart loop. But, whether using that file as the default will break the setups of people (like you) who are actually using Telegraf for something productive is a huge unknown.

I'm sure you could work this out for yourself from the Telegraf Dockerfile but here's a script to fetch the current official default config file:

TELEGRAF_VERSION=1.19.3
WD=./telegraf-${TELEGRAF_VERSION}
CONFIG=official-${TELEGRAF_VERSION}-telegraf.conf
mkdir -p "$WD/usr/src"
cd "$WD"
wget --no-verbose https://dl.influxdata.com/telegraf/releases/telegraf-${TELEGRAF_VERSION}_static_linux_amd64.tar.gz
tar -C ./usr/src -xzf telegraf-${TELEGRAF_VERSION}_static_linux_amd64.tar.gz
cp ./usr/src/telegraf-${TELEGRAF_VERSION}/etc/telegraf/telegraf.conf "$CONFIG"
wc -l "$CONFIG"

Maybe see if that 8641-line file works "as is" on your system and, if not, what "tweaks" are needed.

That would give me some confidence about moving onto a Pull Request.

[Paraphraser]

Further to the above, I have three Pull Requests (one for each of master, old-menu and experimental branches) ready to roll. This includes adding some documentation to the master branch version (there didn't seem to be any existing documentation for Telegraf).

I've made the (possibly heroic) assumption that the 8641-line default supplied with Telegraf will actually work out-of-the-box. The doco explains how to use any existing telegraf.conf that current users will have in their services directory.

It would still be nice to know "how heroic" that assumption is, before I push these commits and create the Pull Requests.

[ryanwalexander]

Unfortunately I'm just getting started with Telegraf so I won't be able to tell you if it broke anything or not. I'd probably also bet on the one supplied with Telegraf.

That said, I do want to help you, and if you can ELI5 how to run the script I will do that as a test.

While we are at it, it might be awesome to get a container going for Chronograf as well - then we almost have the whole InfluxDB TICK stack.

That said, perhaps it may be even better still to try InfluxDB 2.0 introduced in 2019 which if I"m not mistaken, has Chronograf & (and maybe Telegraf?) built into the InfluxDB itself.

https://github.com/influxdata/influxdata-docker/tree/master/influxdb/2.0/alpine

[Paraphraser]

Ha! I had to Google "ELI5".

What I think I will do is proceed with the pull requests. Doing that makes it a fair bit easier for anyone to test and revert.

However, to answer your question, if I assume you're doing this on your Raspberry Pi:

1. Run the (slightly modified) commands from the earlier post:

   TELEGRAF_VERSION=1.19.3
   WD=${HOME}/telegraf-${TELEGRAF_VERSION}
   CONFIG=official-${TELEGRAF_VERSION}-telegraf.conf
   mkdir -p "$WD/usr/src"
   cd "$WD"
   wget --no-verbose https://dl.influxdata.com/telegraf/releases/telegraf-${TELEGRAF_VERSION}_static_linux_amd64.tar.gz
   tar -C ./usr/src -xzf telegraf-${TELEGRAF_VERSION}_static_linux_amd64.tar.gz
   cp ./usr/src/telegraf-${TELEGRAF_VERSION}/etc/telegraf/telegraf.conf "$CONFIG"
   wc -l "$CONFIG"
   

   you will wind up with a file called official-1.19.3-telegraf.conf.

2. Make the result of the above the active configuration, like this:

   cp official-1.19.3-telegraf.conf ~/IOTstack/services/telegraf/telegraf.conf
   

3. Tell the telegraf container to restart:

   cd ~/IOTstack
   docker-compose restart telegraf
   

4. To undo the change:

   cp ./.templates/telegraf/telegraf.conf ./services/telegraf/telegraf.conf
   docker-compose restart telegraf
   

5. To clean up everything done in step 1:

   rm -rf "$WD"
   

---

Haven't ever thought about Chronograf. I'll mull it over.

---

Ah, yes, InfluxDB 2 might be nice but this is what happens when I try it:

Creating network "iotstack_default" with the default driver
Pulling influxdb (influxdb:latest)...
latest: Pulling from library/influxdb
ERROR: no matching manifest for linux/arm/v7 in the manifest list entries

If I switch to 64-bit mode:

sudo sed -i.bak '$iarm_64bit=1' /boot/config.txt
sudo reboot

and confirm the switch:

$ uname -a
Linux sec-dev 5.10.52-v8+ #1441 SMP PREEMPT Tue Aug 3 18:14:03 BST 2021 aarch64 GNU/Linux

(the "aarch64" bit) and then try again:

Creating network "iotstack_default" with the default driver
Pulling influxdb (influxdb:latest)...
latest: Pulling from library/influxdb
ERROR: no matching manifest for linux/arm/v7 in the manifest list entries

The Pi clearly knows it is in 64-bit mode but Docker doesn't share that understanding. It's a known problem (but, offhand, I can't find the issue where it is discussed). At one point I experimented with forcing the correct architecture on a docker pull but that still didn't help. I think we IOTstackers running on Raspbian just have to be patient.

In short, as the old Cornishman once said:

if I wanted to be getting to there, I wouldn't be starting from here

[Paraphraser]

I have just uploaded the changes as Pull Requests:

• If you're running "new menu" on master branch: Pull Request 394
• If you're running "old menu" on old-menu branch: Pull Request 395

Here are some instructions on Applying a single Pull Request.

Now we just have to wait until the IOTstack maintainer either accepts or rejects these pull requests. Fingers crossed.

I should probably add that the new doco for the Telegraf container will be in your local copy of the IOTstack repository once you apply one of these pull requests (~/IOTstack/docs/Containers/Telegraf.md). If you want to see it in your browser, click this.

[Paraphraser]

This seems to work for Chronograf:

  chronograf:
    container_name: chronograf
    image: chronograf
    restart: unless-stopped
    environment:
      - TZ=Etc/UTC
    # see https://docs.influxdata.com/chronograf/v1.9/administration/config-options/
      - INFLUXDB_URL=http://influxdb:8086
    # - INFLUXDB_USERNAME=
    # - INFLUXDB_PASSWORD=
    # - INFLUXDB_ORG=
    ports:
      - "8888:8888"
    volumes:
      - ./volumes/chronograf:/var/lib/chronograf
    depends_on:
      - influxdb
    networks:
      - iotstack_nw

Remove the last two lines if you are running "old menu".

Firing this up and connecting to port 8888 opens the GUI but I did not go any further than that (because I have no idea what I'm doing).

It seems to create its own database in its persistent storage area. /var/lib/chronograf is the only path I found in any documentation so I assume all "user action" that needs to be preserved across instantiations gets stored there. That doesn't mean there might not be other things that need to be persisted; I guess we'll find that out the hard way.

My guess is that the environment variables for username, password and organisation are there to support querying. The URL embedded in the comment is to the doco page if you need other environment variables.

Anyway, see if it works for you. If it looks OK to you, I'll submit some Pull Requests.

[Paraphraser]

Take two!

  chronograf:
    container_name: chronograf
    image: chronograf
    restart: unless-stopped
    environment:
      - TZ=Etc/UTC
    # see https://docs.influxdata.com/chronograf/v1.9/administration/config-options/
      - INFLUXDB_URL=http://influxdb:8086
      - KAPACITOR_URL=http://kapacitor:9092
    # - INFLUXDB_USERNAME=
    # - INFLUXDB_PASSWORD=
    # - INFLUXDB_ORG=
    ports:
      - "8888:8888"
    volumes:
      - ./volumes/chronograf:/var/lib/chronograf
    depends_on:
      - influxdb
      - kapacitor
    networks:
      - iotstack_nw

  kapacitor:
    container_name: kapacitor
    image: kapacitor:1.5
    restart: unless-stopped
    environment:
      - TZ=Etc/UTC
    # see https://docs.influxdata.com/kapacitor/v1.6/administration/configuration/#kapacitor-environment-variables
      - KAPACITOR_INFLUXDB_0_URLS_0=http://influxdb:8086
    # - KAPACITOR_INFLUXDB_USERNAME=
    # - KAPACITOR_INFLUXDB_PASSWORD=
    # - KAPACITOR_HOSTNAME=kapacitor
    # - KAPACITOR_LOGGING_LEVEL=INFO
    # - KAPACITOR_REPORTING_ENABLED=false
    ports:
      - "9092:9092"
    volumes:
      - ./volumes/kapacitor:/var/lib/kapacitor
    depends_on:
      - influxdb
    networks:
      - iotstack_nw

[Paraphraser]

@ryanwalexander Pull Requests PR394, PR395, PR396, PR297, PR398, PR399 have been applied to master, old-menu and experimental branches. Together, everything in the above should now be part of IOTstack. If you manually applied any pending pull requests, just git checkout master (or git checkout old-menu) and then do a git pull.

[Paraphraser]

To the best of my knowledge this is fixed and should be closed.