EMFILE error on task Deploy Azure App Service #4127
Comments
vincent1173
added
Area: Release
Area: AzureAppService
|
@nlips , Thanks for reporting the issue. |
|
|
@nlips , thanks for the logs. For a workaround, Can you please add the web.config file in your package ? In this way, the zip package is not extracted and it proceeds with the deployment. |
|
@vincentdass How does something like this get fixed? Would it be a new agent? I'm seeing the same exact problem, but I'm not clear about your web.config comment since I already have web.config in the root of my zipfile. Can you provide further details of the workaround. Thanks This is my rough directory structure inside my zip (that is being extracted in my case to C:\vstsagent\DEPLOY-RRCRM_work\r1\a\temp_web_package_6270807555411011) bin
|
|
@simeyla , if any options in File Transforms & Variable Substitution Options is enabled, the zip package is |
|
@vinca thanks. I actually managed to dramatically reduce the size of my
release to get around this issue. Glad to see it is fixed but I won't be
able to verify it at this time.
…On Tue, Jun 13, 2017 at 4:41 AM, Vincent A (vinca) ***@***.*** > wrote:
@simeyla <https://github.com/simeyla> and @nlips
<https://github.com/nlips> , sorry for the late response.
For windows, this issue is resolved with 2.117.1 agent version.
Can you please check the hosted agent version and rerun the release ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#4127 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADfKVhvo8YZVR4FnsgRRYcP4Rlk0xNBgks5sDnVtgaJpZM4NIHVM>
.
|
|
Summarizing the fix for reference :
|
|
@vincentdass I just ran into this issue today when trying to deploy my nodejs application as a AzureWebService. My template application was working fine but once started adding modules it couldn't deploy.
Just wanted to point out that it seems like either the issue came back in 3.* or it wasn't resolved in 2.*. |
|
@skylerjokiel , thanks for reaching out.
|
|
I am still getting this issue with a 2.117.1 agent on a windows platform zip size: 47.6 MB |
|
@hendecasyllabic , thanks for reporting the issue.
|
|
I have currently got it working using the extract file work around. I might try the post deployment script as it might be faster. thanks. |
|
Same issue here. I'm using the 3.* agent version. Got it working using extract file work around. |
|
@hilfor , Can you please share the logs and Package size? |
|
@vincentdass The last logs from the release process, the package size is about 20MB : |
|
I can't use @vincentdass 's answer because after extracting it has a long directory, something like: Content/D_C/a/1/s/Project.MVC/obj/release/Package/PackageTmp these directory changes over time, would not make it a stable release. Please tell me where to "Increase the max. limit of open file descriptors for the account where the automation agent is running." on the "Hosted" agent or "Hosted VS2017" agent. Or how to ignore the node_modules folder because as far as deployment goes it should only be used as content, why is it "opening" these files anyway? Post deployment scripts seems no option because not executing the npm install & build during solution build will throw other errors. And my feeling says it shouldn't be in the release because you don't want to "Build" something within a "Release", that is what a "Build" should be for. What is causing this issue anyway? A bit of log: Total zipfile size: 136MB |
|
@Ruud-cb , Is there any file transformation option enabled in the task? (Web config generation , XML transform, XML sub or JSON sub)? |
|
Same problem for me, worked previously, added some extra code / NPM package to my app and now starting to receive this error, log: My app does include a |
|
Happening to me as well, where is the command to "Increase the max. limit of open file descriptors for the account where the automation agent is running." ???? |
|
@jameshowe , @CheetahChrome , Can you please share the agent version? |
|
This is still an issue in Oct 2019, kind of ridiculous that nothing has been done about this in over 2 years. |
|
Hi @vincent1173 I am still seeing this issue. The workaround for adding an extract task before the Azure App Service task worked for me |
|
This issue is stale because it has been open for 180 days with no activity. Remove the stale label or comment on the issue otherwise this will be closed in 5 days |
|
We've encountered this issue a number of times over the last week |
|
Also runnimg into this problem when I'm trying to deploy a next.js project. Zipped folder with node_modules is 100mb. |
|
I opened a support ticket with MS. I've copy/pasted the current assessment of the situation below. TL;DR: When JSON variable substitution is used in the task it will unzip the artifact package to perform the replacement in the file. This issue emerges (for us intermittently, around 25% of the time) during this unzip process. Supposedly, the "Extract Files" task has a more reliable unzipping mechanism. So, as a workaround use that and pass the output to the deploy task. =============================== We have got an update from our product group team. Please go through the below analysis and workaround shared by PG and let us know if you have any questions. Issue: Whenever a File transformation or Variable substitution option is selected in the Azure App Service Deploy task, it will first unzip the package and then perform the operations on the relevant files. Analysis: Currently, decompress-zip node module is used to unzip the package which seems to have some bug related to EMFILE when dealing with a large number of files. PG is currently exploring other options to unzip the package like 7zip, adm-zip. This change will take some time to roll out as they have to revisit the design and test accordingly. Workaround: For now, kindly use the Extract Files task to first extract the zip into a folder path and then provide the folder path into the App Service Deploy task. This will prevent the App service task to unzip the package and hence prevent EMFILE errors. For YAML pipeline: |
|
MS Support have clearly just copied that response from the comments here rather than doing any actual investigation or trying to fix it. |
|
This issue has been fixed and it should get deployed in ~3 weeks with the next deployment. |
|
Thank you @amit-avit and team! Look forward to the fix. |
|
This issue is fixed now and has been deployed. |
|
I am still getting this error, please see below Error: EMFILE: too many open files, open 'D:\a_temp\temp_web_package_9235376407089184\node_modules\tar-fs\test\fixtures\d\file1' Log: |
and others
I'm using the Deploy Azure App Service task to deploy a nodejs application provided as a zip file.
The process always fails with the error "EMFILE: too many open files, open d:\a\r1\a\temp_web_package_..."
The text was updated successfully, but these errors were encountered: