choco should be more resilient to MSI timeouts and detect abnormalies about choco

[TheCakeIsNaOH]

Chocolatey CLI already has timeouts built in, by default set to 45 minutes. That should apply to installers run by package installation scripts. Is that what you are asking for?

[nopeless]

Chocolatey CLI already has timeouts built in, by default set to 45 minutes. That should apply to installers run by package installation scripts. Is that what you are asking for?

45 minutes is incredibly long but i can see the rationale. The issue im encountering though is not the msi installer itself but whatever windows waits before installing. (like how if you run two installs at the same time one waits before the previous ends). The 45 minutes would be a very broad catch-all while the one im suggesting is a bit more specific to detecting microsoft internal blocks

[pauby]

I'm unsure what you are asking here.

If the operating system is unable to run the installer because 'certain Windows security features are disabled' that would be an issue with the operating system not running the installer? Or that the Operating System / msiexec.exe which Chocolatey CLI uses, not reporting back there is an issue.

If Chocolatey CLI is hanging, it would likely mean that msiexec.exe is hanging which again, is an Operating System issue.

I understand what you are asking that Chocolatey CLI should ensure the Operating System doesn't have 'things' disabled. As a package manager handing off the installing to msiexec.exe, I would feel that msiexec.exe is best placed to determine the suitability of the Operating System for the installation.

45 minutes is incredibly long but i can see the rationale.

45 minutes (or, 2700 seconds) is the default. Like almost everything in Chocolatey CLI, this is configurable. It can be changed using the commandExecutionTimeoutSeconds field using choco config set --name="'commandExecutionTimeoutSeconds'" --value "'600'" to set the timeout to 10 minutes, for example.

[nopeless]

@pauby asking for whether the operating system has things disabled is not something i seek either. there are so many things that can go wrong. what i mean is when i see an installation hanging, i dont know if it is because of the installer or because of the system. having some sort of preflight where it checks that it is possible to install a program for example maybe installing an empty msi and removing it would be suitable enough to see which part is causing the trouble. the way i debugged this issue was by tailing logs and testing a known installer and seeing that one hang as well.

Again, this is rather a niche issue to run into but I still wanted to see if anyone else would be in the same situation.

[pauby]

what i mean is when i see an installation hanging, i dont know if it is because of the installer or because of the system

I completely understand the frustration. This problem will be caused by msiexec.exe which is what is used to install MSI's through Chocolatey CLI or when you install it manually. The solution for that problem lies there, not in Chocolatey CLI.

Changing the timeout will permit Chocolatey CLI to determine there is an issue much sooner.

that it is possible to install a program for example maybe installing an empty msi and removing it would be suitable enough

If there are problems installing an MSI, then installing an empty one will result in the same situation.

this is rather a niche issue to run into but I still wanted to see if anyone else would be in the same situation.

Agreed. Because the problem lies outside of Chocolatey CLI, its affect is limited, there is no chest definition of what is needed and and there is a workaround of sorts (timeout change), this isn't something we'd focus working on.

[nopeless]

If there are problems installing an MSI, then installing an empty one will result in the same situation.

I would point out that installing an empty msi is guaranteed success unless there is a system block. therefore an even shorter timeout can be applied.

@pauby

[pauby]

Unfortunately, installing an empty MSI every time you want to install a non-empty MSI, isn't practical.

[nopeless]

Unfortunately, installing an empty MSI every time you want to install a non-empty MSI, isn't practical.

well i couldn't come up with a better way to test it. im guessing that it's rather a limitations of apis given by windows then?

[pauby]

Don't misunderstand, we appreciate the issue and you taking the time to report it. I wanted to point to where I feel the root problem lies (and I am open to being wrong), and being transparent and honest about our priorities and focus.

[nopeless]

Don't misunderstand, we appreciate the issue and you taking the time to report it. I wanted to point to where I feel the root problem lies (and I am open to being wrong), and being transparent and honest about our priorities and focus.

hm ok. I am not well versed with windows api enough to come up with a practical solution other than installing an empty msi. But a way to detect whether there is a pending installation/blocking installation state would be nice to have

[nopeless]

@pauby i thought about this for a while. Does choco allow testing installing a blank exe?

[pauby]

Chocolatey CLI will install whatever EXE you need. But I don't know what ypu mean by 'testing' and a 'blank EXE'. We're also talking about MSI's?

[nopeless]

sorry, blank msi*.

let's say choco testinstall exists. it will install a blank msi and subsequently uninstall it.

I thought about wrapping choco testinstall with a timeout script and put it at the top of my routine update scripts

does that make a bit more sense?

[github-actions]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?
This issue will be closed in 14 days if it continues to be inactive.