yeah, that makes sense 
I manually modified the upstart script to include the env var and after a reboot it clearly shows that the service is not started with a update strategy:
DEBUG 2018-10-15T09:35:15Z: habitat_sup::manager::service::spec: Writing service spec to '/hab/sup/default/specs/mypkg-core.spec': ServiceSpec { ident: PackageIdent { origin: "mypkg", name: "mypkg-core", version: None, release: None }, group: "default", application_environment: None, bldr_url: "https://bldr.habitat.sh", channel: "stable", topology: Standalone, update_strategy: None, binds: [], binding_mode: Strict, config_from: None, desired_state: Up, svc_encrypted_password: None, composite: None }
However, checking the used recipe in chef manage shows that the service is configured to use strategy ‘at-once’
hab_service 'myorg/mypkg-core' do
action :load
strategy 'at-once'
channel node.habitat['channel']
end
So either this is an issue with the chef habitat cookbook, or with habitat itself. However as this node has seen a few updates, this might also have happened along the way when upgrading. If there is any additional information I could gather that would be helpful, please do let me know. Otherwise I’ll just throw away that node and start with a clean state and see if I’ll run into this again.
Yet, probably chef should be able to figure out that a service is running with the wrong strategy and take care of that. After looking through the cookbook, I don’t think that there is any implementation which would check if a service is configured correctly. I’ll open an issue over at the repo. Maybe we can find a way to improve this.