Choco: Check for currently processing installations (MSI 1618)

Created on 31 Jul 2017  路  10Comments  路  Source: chocolatey/choco

(I think this has sort of come up elsewhere for other reasons)

REASONING:
I've had a lot of package installs (MSI - upgrades) failing of late with 1618 meaning MsiExec.exe/InstMsi.exe was already (trying?) installing something else; though I wasn't aware anything else was installing. It might just be a package of my own that is in the creation processes but got "stuck" because the "kinks" haven't been "worked out" yet.

SUGGESTION:
Have choco/cinst/cup.exe check if Windows Installer is already busy before attempting to install package(s) and do some sort of alternative action if Windows Installer is busy. Possibly a statement saying the system is busy already installing programs and abort. Possibly a question asking to delay for X amount of seconds or minutes before continuing. Possibly a default time to wait before processing package installs/upgrades. Possibly a notification and then a loop until Windows Installer is finished. Possibly just continue the attempt of install/upgrade but give a choice after failure to retry? I'm not sure of the best action as I see different options as preferred in instances of manually running choco/cinst/cup versus scripted running of same.

Possibly related to https://github.com/chocolatey/choco/issues/1369?

0 - Backlog Duplicate Issue Enhancement

Most helpful comment

Stopping WU, WSUS, and SCCM only mitigates one vector for MSI installs. Anything could kick them off. As a long-time developer on the Visual Studio setup engines (including WiX/Burn), I recommend don't check for MSI being busy - how you do that can vary from version to version - but instead gracefully handle exit code 1618 and retry after a timeout. The Visual Studio installer uses an increasing timeout and either gives up after about 10 tries or, in newer versions of the installer, prompts the user if they want to continue waiting.

The _MSIExecute has been deprecated for years now and checking if the "msiserver" service is busy is not synchronized. Even if you did check the state, the very next moment it could be busy again.

All 10 comments

Related to #1369.

This will be helpful only for MSI installs, but it won't help with exe installers. That's okay, this is a good start.

@ferventcoder Hello, Just out of curiosity. Would this also get addressed when #1369 is addressed, since i see that this issue has been linked with #1369 ?

Stopping WU, WSUS, and SCCM only mitigates one vector for MSI installs. Anything could kick them off. As a long-time developer on the Visual Studio setup engines (including WiX/Burn), I recommend don't check for MSI being busy - how you do that can vary from version to version - but instead gracefully handle exit code 1618 and retry after a timeout. The Visual Studio installer uses an increasing timeout and either gives up after about 10 tries or, in newer versions of the installer, prompts the user if they want to continue waiting.

The _MSIExecute has been deprecated for years now and checking if the "msiserver" service is busy is not synchronized. Even if you did check the state, the very next moment it could be busy again.

Possible duplicate of #484

It's been three years.
Any progress with this?

I'm surprised I never mentioned it, but I did make this kludge for the meantime:
https://chocolatey.org/packages/chocolatey-preinstaller-checks.extension

Thanks, I made this too, but as a wrapper function, I am unaware of chocolatey extensions. So this allows users to still use choco install, rather than needing a custom command?

I'll have to try it out.

Yes, users use Chocolatey as normal; nothing they have to do other than have the extension installed. Some Chocolatey install/uninstall functions get put on hold so that checks can be made before allowed to execute.

Extensions are just additional PS modules/scripts/functions that get loaded into Chocolatey's PowerShell and their routines are available to Chocolatey install/uninstall scripts if the packager wants to use them ;just like the Chocolatey "helpers." Think of them as extra helpers! Basically created so that common functions can be re-used without having to reinvent the wheel all the time. Chances are if you check your Chocolatey\lib folder, you already have one or two installed and didn't know it.

Read the package description and I bet you'll understand it. Code is pretty well commented as well.

If you have a chance, let me (us?) know what you did for your wrapper and how well it worked. Maybe my extension can be bettered...

Was this page helpful?
0 / 5 - 0 ratings