I’ve run into a similar issue, “The remote script failed with exit code 100”
WEBSITE_WEBDEPLOY_USE_SCM = false didn’t correct the error.
The above forum message mentions “First class support for deploying Linux apps to an Azure web app is something we are currently working on”
Is this still being worked on?
Hi,
Thank you for reaching out! In reviewing the information you’ve provided I see you have questions about running Linux apps within an Azure Web App, and what updates have been made in this space.
Since the last post you linked we have made some major improvements to this area via our new ‘Deploy an Azure App Service’ step template (available in Octopus versions > 2021.1):
If you are currently using the legacy step template ‘Deploy an Azure Web App (Web Deploy)’, then this updated step template should help alleviate some of the pains of the old template, but let me know if you have any additional questions or concerns.
Best regards,
Britton
When deploying to a Linux Web App, I get a “Gateway Time-out”, “The remote script failed with exit code 100” error (with the new Deploy an Azure App Service step).
Deploying the same app to a Windows Web App completes successfully.
Hi,
I’m sorry to hear you are having trouble with the new ‘Deploy an Azure App Service’ step template, but I’ll do my best to help get things sorted.
As an initial troubleshooting step would you be able to upload the raw output for both the working Windows app task as well as the broken Linux app task? Feel free to upload these logs at the following secure link.
Best,
Britton
Done. The project targets both in the same deployment, you should see both success and failures in the same log.
Hi,
Thank you for sending the log over for review.
While I continue to look into this on my side, can you also let me know if the package sizes vary between the Linux and Windows applications? I’d be curious to know the package sizes (on average) that are being uploaded in each process in order to rule this out as being the potential issue.
I did find this GitHub issue which sounds similar to what we are seeing here (slightly different error), but this should be addressed in the version of Octopus you are currently running so I am continuing to investigate what could be causing this in your case.
Best,
Britton
Uncompressed, it’s 115 MB, and it’s the exact same package being deployed to each host.
Additionally, a “az webapp deployment source config-zip” deployment completes successfully to the Linux App Service…
Hi,
Thank you for clarifying and providing this additional information.
As a next step in troubleshooting, would you be able to upload the Tentacle logs for review as well? I’m curious to see what the Tentacle logs report in this case, so we can compare it against what is being reported by the Octopus server logs.
Best,
Britton
I’ve uploaded the tentacle and server logs from C:\Octopus\Logs on the Octopus server. I don’t believe it executed on a remote tentacle due to the step setting:
“Execution LocationThis step will run on the Octopus Server on behalf of each deployment target”
Also, the az webapp deployment source config-zip took 12.6 minutes to run, and octopus is timing out after 18 minutes.
Is there a way to increase the timeout?
Hi,
Thank you for providing those additional logs, and I was also curious if adjusting some timeout settings would help here as well.
You should be able to make some adjustments to the Octopus timeout settings by going to Infrastructure > Machine Policies within your Octopus instance and modifying the ‘Connect Timeout’ value:
Let me know how it goes once you update this value, but the logs do seem to indicate that something is timing out somewhere - just need to track it down 
Best,
Britton
Adjusted the Connect Timeout to 1 hour, task still timed out at 18 minutes.
Hi,
I’m sorry that changing this setting didn’t impact anything, but I’ve been doing some more experimenting on my side to try and troubleshoot this issue further.
In order to try and reveal some information on the underlying problem could you upload the relevant deployment logs for the problem application on the Azure side? On my side I was able to pull this information by going to My Web App > Deployment Center > ‘Logs’ tab in Azure:
Could you also confirm what is listed under ‘App Service Plan’ as the Operating System in the Azure Portal for this web application (My Web App > App Service Plan)?
Also, I would be interested to see if there are any differences on what is set for TLS/SSL between the Linux and Windows apps (My Web App > TLS/SSL Settings in Azure):
Lastly, as a way to rule out the package size being an issue in the case of the Linux deployment, is there any way you could try uploading a smaller package to see if this succeeds?
Sorry this has turned into a deeper investigation, but thank you for your patience in working through this and hopefully we will get it sorted soon.
Best,
Britton
Found the issue- Auto-swap on Linux is not supported: Set up staging environments - Azure App Service | Microsoft Docs
While it’s not possible to configure auto-swap via Azure Portal on a Linux app, it is possible to configure via ARM/Bicep (which is how I poked myself in the eye on this one)
Thanks for looking into this on your side.
Hi,
You’re welcome, I’m glad you were able to identify the underlying problem. I haven’t used the auto-swap feature too heavily so I wasn’t initially aware this wasn’t supported for Linux apps, but definitely something I will keep in mind if this comes up in the future.
Cheers,
Britton
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
