[chef] Re: Re: Re: Upgrading chef-client on Windows not supported?

[Noah Kantrowitz < >]

On Feb 27, 2014, at 1:29 PM, Jeppe Nejsum Madsen 
<
 >
 wrote:

> 
> On Thu, Feb 27, 2014 at 10:21 PM, Noah Kantrowitz 
> <
 >
>  wrote:
> Windows, unlike all other OSes, locks executable files while they are 
> running. The usual solution is to just move the old executables aside and 
> write the new ones in their place. Unfortunately there is no way to do this 
> atomically, so you often end up with tiny updater.exe binaries that the 
> original process launches (and then kills itself) to manage the update 
> process. I'm sure a pull-request would be happily accepted to add this 
> dance to the omnibus_updater cookbook and I'm happy to talk anyone through 
> other strategies for doing binary updates on Windows (might as well get 
> some benefit out of doing that for 3 solid years :-).
> 
> Yeah I guess that it is not easily done. I don't think this should be in 
> the omnibus_updater though as it's not just the .exe but the entire 
> embedded ruby env that might need replacing.
> 

Yes, the problem is almost certainly the ruby.exe and other DLLs that are 
active while Chef is running.

> I think the chef-client MSI should handle this. Like many other windows 
> services it should be able to upgrade itself (preferably without a reboot, 
> but hey this is windows after all :-)

That would work too, I defer to others with more WiX experience as to how 
hard it is to augment the MSI do this though.

--Noah

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail