Panic decoding toml array when expecting string

[MikeMester]

Followed the instructions to download the latest telegraf agent. Ran the make.

Performed the following steps:

`
telegraf --input-filter jolokia2 --output-filter influxdb config > test.config

telegraf test.config
`
RESULT

`
2017/11/07 12:11:41 I! Using config file: /etc/telegraf/telegraf.conf
panic: reflect.MakeSlice of non-slice type

goroutine 1 [running]:
reflect.MakeSlice(0x1c85aa0, 0x1223fa0, 0x0, 0x1, 0x1223fa0, 0xc420068130, 0xc420234d30)
/usr/lib/golang/src/reflect/value.go:2049 +0x2ab
github.com/influxdata/toml.setArray(0x1223fa0, 0xc420068130, 0x198, 0xc420018440, 0x23, 0x0)
/root/work/src/github.com/influxdata/toml/decode.go:347 +0x216
github.com/influxdata/toml.setValue(0x1223fa0, 0xc420068130, 0x198, 0x1c75c00, 0xc420018440, 0x1223fa0, 0xc420068130)
/root/work/src/github.com/influxdata/toml/decode.go:266 +0x52c
github.com/influxdata/toml.UnmarshalTable(0xc42006c8c0, 0x131a4c0, 0xc420068100, 0xc4201dea80, 0x0)
/root/work/src/github.com/influxdata/toml/decode.go:127 +0xe90
github.com/influxdata/telegraf/internal/config.(*Config).addInput(0xc420185720, 0xc4201432b0, 0xe, 0xc42006c8c0, 0x0, 0x0)
/root/work/src/github.com/influxdata/telegraf/internal/config/config.go:827 +0x16b
github.com/influxdata/telegraf/internal/config.(*Config).LoadConfig(0xc420185720, 0x149ec46, 0x1b, 0x1d882d8, 0x0)
/root/work/src/github.com/influxdata/telegraf/internal/config/config.go:633 +0x743
main.reloadLoop(0xc420182ae0, 0x1d882d8, 0x0, 0x0, 0x1d882d8, 0x0, 0x0, 0x1d882d8, 0x0, 0x0, ...)
/root/work/src/github.com/influxdata/telegraf/cmd/telegraf/telegraf.go:135 +0x49b
main.main()
/root/work/src/github.com/influxdata/telegraf/cmd/telegraf/telegraf.go:408 +0x65b
`

Relevant telegraf.conf:

System info:

Telegraf v1.5.0~e0df62c (git: master e0df62c)
Centos 7

Steps to reproduce:

See Above

Expected behavior:

Collect Jolokia Metrics

Actual behavior:

Panic

Additional info:

[MikeMester]

telegraf.conf.txt

Actually, Looks more like a configuration issue with the Jolokia2 plugin. Im using the kafka example conf.

[danielnelson]

This change should solve things:

[[inputs.jolokia2_proxy]]
-  url = ["http://127.0.0.1:8080/jolokiai/"]
+  url = "http://127.0.0.1:8080/jolokiai/"

[MikeMester]

Yep. That worked. Thanks for the quick turn around.

[danielnelson]

We could fix this by upgrading to the latest naoina/toml, but our fork has diverged and we could introduce bugs. I'm also planning to switch to BurntSushi/toml with the in progress config plugin changes for #272. I will leave this issue open for now.

[goller]

@danielnelson I had a similar panic in 1.9.4:

ok I’ve narrowed down the panic a bit

[[outputs.http]]
    method = "POST"
    data_format = "json"
    url = "http://billingd.twodotoh.svc.cluster.local:8094/billing"
    namepass = ["storage_usage_bytes"]
    taginclude = ["org_id"]
    [outputs.http.headers]
       Authorization = "Token $BILLINGD_TOKEN"
       Content-Type = "application/json"

this ^^ is OK!

[[outputs.http]]
    method = "POST"
    data_format = "json"
    url = "http://billingd.twodotoh.svc.cluster.local:8094/billing"
    [outputs.http.headers]
       Authorization = "Token $BILLINGD_TOKEN"
       Content-Type = "application/json"
    namepass = ["storage_usage_bytes"]
    taginclude = ["org_id"]

this ^^ panics

[danielnelson]

As we discussed this is the same case, when the values are placed below the subtable they become part of it, with indention:

[[outputs.http]]
    method = "POST"
    data_format = "json"
    url = "http://billingd.twodotoh.svc.cluster.local:8094/billing"
    [outputs.http.headers]
       Authorization = "Token $BILLINGD_TOKEN"
       Content-Type = "application/json"
       namepass = ["storage_usage_bytes"]
       taginclude = ["org_id"]

This is because indention has no meaning and keys always belong to the closest table above them in the file. Then it becomes the original issue of assigning an array to a field that expects a string.

[powersj]

The panic is now handled, and instead, an error message about unmarshaling TOML into string exists. I'm going to go ahead and close this as the panic is resolved and the user gets an actual error message.