Further investigation reveals that the actual env passed with 66-env is in effect so the bug may be on 66-inservice displaying both the service file env section and appending the one from 66/conf/ver/servicename.conf
This is absolutely normal. No bug here but a misunderstood of what 66-env do.

if you look at the first sentence of the Environment file you see this: 
environment variables from: /etc/66/conf/nptd/0.2.0/.ntpd
So, it display the upstream configuration file(prefixed with a dot). The [WARN] message at the display of the upstream file with 66-inservice is erased just for a convenient and visibility way in particular when the environment section define just a one line. You can see it if you "cat" the upstream file.
So, this file should NEVER be changed because its ALWAYS overwritten by 66-enable.

Now, when you use the first time the 66-env for a service and the user configuration file(without prefixed with the dot) doesn't exist, it create it. This file is NEVER touched by any 66 tools apart 66-env.
So, now when you call 66-inservice it display ALL configuration files. In your case you see an another sentence with: 
environment variables from: /etc/66/conf/ntpd/0.2.0/ntpd
At start time, every configuration files will be read and parsed by execl-envfile but it read and parse it in alphabetical order. So, for a same key=value the one kept is the one coming for the user configuration file(without prefixed with the dot).

Note: 66-inservice display the contents of the configuration file in alphabetical order too. That means that for a same=key value, the last file displayed which contain the key=value is the one used.

Hope, it's clear, if not, please ask me again.

Powered by Obarun