chronograf not creating a pidfile when requested with the "-pidfile=" flag

[petercelentano]

My current version of Chronograf is:

2017/10/04 19:24:39 Chronograf 1.3.8.3 (git: e63f073c8fcc309abcc5a3b04aad1eb692b69864)

Platform: Linux, Centos 7.3
My start command is:

./chronograf --host 0.0.0.0 --port 8888 -b lib/chronograf/chronograf-v1.db -c share/chronograf/canned --influxdb-url=http://127.0.0.1:8086 --kapacitor-url=http://127.0.0.1:9092 -pidfile=chronograf.pid

If using:

-pidfile=chronograf.pid

is not the correct syntax, what is? Using the start command listed above, Chronograf will not create a pidfile

[petercelentano]

Is this a bug? Is Chronograf supposed to be able to create a pidfile with the above flag?

[thibodux]

It doesn't look like that option is currently supported like the rest of the TICK stack. Maybe this should be an enhancement request.

[petercelentano]

In that case it should probably be a feature request.

[goller]

@petercelentano thanks for writing in! Did you want to try your hand at adding code to the project?

If so, you'd add an option in server/server.go for the PID file.

@timhallinflux I'm looking at this library: https://github.com/facebookgo/pidfile to handle generating process id files. However, it has facebook's patent clause here: https://github.com/facebookgo/pidfile/blob/master/patents Is this an issue?

[petercelentano]

I'm not too familiar with GO yet, and I don't have a build environment setup yet. If adding this functionality would be trivial, I would appreciate help with it. I will get a build env together though so that I can test the fix :)

[thibodux]

@goller why not just take parts of code from TICK stack like cmd.writePIDFile found here: https://github.com/influxdata/kapacitor/blob/0a8abecf0fd73c7b3a5b930a0c2923033ac92b80/cmd/kapacitord/run/command.go

[goller]

@thibodux even better! Thank you!

[petercelentano]

Any progress on this all? I'm willing to do testing as soon as a fix is available :)

[goller]

(some implementation notes... )

Here is telegraf's implementation:
https://github.com/influxdata/telegraf/blob/366bda45c37d8391b420ef4d413b6f089214b3cc/cmd/telegraf/telegraf.go#L216

... and influxdb's:
https://github.com/influxdata/influxdb/blob/5bf9191a8272d4980a5bed78029b905ed69040a2/cmd/influxd/run/command.go#L172

I prefer telegraf

[thibodux]

The Kapacitor implementation (https://github.com/influxdata/kapacitor/blob/0a8abecf0fd73c7b3a5b930a0c2923033ac92b80/cmd/kapacitord/run/command.go#L187) matches the InfluxDB implementation.

The discrepancy is because InfluxDB and Kapacitor seem to assume that they are running as services on *nix, and think the service manager will remove the PID file (see https://github.com/influxdata/influxdb/blob/276a26656e316b1068fe1a66952dff8a17f39fa1/scripts/init.sh).

On the other hand Telegraf takes care of removing the PID file whenever it closes (via the defer call in the code).

At this point, I would also agree that the telegraf implementation makes more sense just because I don't like the assumption. In fact, it would be best if they could use the same logic across all four, but I don't know if that change would suddenly break a lot of systemd or init.d stuff in the wild (hopefully not).

[thibodux]

After rethinking, I retract my previous statement about which implementation I prefer. I think Kapacitor and Influx is generally cleaner. Telegraf startup code seems to be a bit more thrown together compared to the others and how it reads configuration settings.

The one caveat would be how the pid file gets removed would need to be changed if Telegraf was made to look more like the others.

Just my two cents

[goller]

@thibodux Agreed. Adding the PID file removal would be good.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has not had recent activity. Feel free to reopen if this issue is still important to you. Thank you for your contributions.