Kudu: Recover logs of calls to Kudu API

[renzors]

Hello, I have tried to call Kudu API from Powershell using Invoke-RestMethod and it throws timeout randomly, so I would like if exist a way to recovery the logs of API calls to Kudu.
Thanks in advance.

[davidebbo]

Check the D:\home\LogFiles\kudu\trace folder from Kudu Console.

[renzors]

D:\home\LogFiles\kudu\trace doesn't keep that information, What could am I missing?

[davidebbo]

You mean you don't see any log file at all for these calls? What specific API are you calling? It might make sense to open an issue focused on the problem you're having rather than on the log.

[renzors]

I am calling exactly to api/command and I call commands for restoring npm packages, composer packages, or that kind of commands that could take a long time.
What I already tried:

• Setting -TimeoutSec 600 in Invoke-RestMethod
• Setting this appSetting SCM_COMMAND_IDLE_TIMEOUT = 600

Things I know:

• On Azure, there is a general idle request timeout that will cause clients to get disconnected after 230 seconds.

Things I don't know:

• Where Can I find logs of these calls on Azure.
• Why It happens randomly.

Things I think could work.

• We can receive an ID when we use this API and then can request the progress status through another endpoint, on this way we could keep alive the call on the client.

Why I need this behavior:

• Because we use Octopus for continuous delivery, and we need to run automate commands from here in the deployments.

I hope to be more clear on this occasion, let me know if is necessary open another issue. Thanks in advance for your assistance.

[davidebbo]

A couple questions:

• when it times out, is it always after 230 seconds, or does the time vary?
• does the operation complete server side despite the client being disconnected? That's usually the case with the 230s timeout

Also, when you say that "D:\home\LogFiles\kudu\trace doesn't keep that information", do you mean that you don't see any trace files in that folder? Or you see some for some operations but not the ones at stake here?

[renzors]

Hi David,

• The timeout happens at 230 seconds in the most cases. Sometimes, it takes some more seconds.
• In my last tests the operation didn't complete the execution.
• Respect to logs, I would mean I don't see any content related to the api/command calls into log files.

[davidebbo]

Is it expected this it would take this long? This API is not really designed for starting very long operations and waiting for them. Unfortunately, the 230s timeout is not something Kudu can change.

One approach some have used is to create your own async pattern. e.g.

• start the command but don't wait for it
• have the command report progress by writing to some file
• poll for the file (e.g. using Kudu vfs API) to check status/completion

Not super pretty but can be made to work.

[axelwass]

We have hacked around the issue by running in azure the following commands:

# Clean old files
del composer_update_*.txt

# Start composer (we just let it timeout and redirect output and exit code to files)
composer update 1> composer_update_output.txt 2> composer_update_error.txt & echo %errorLevel% > composer_update_exitcode.txt

# Then we actively wait until exitcode file exist as a flag on execution end
if exist composer_update_exitcode.txt (echo exit) else (echo still running)

# Then we get the data from files
type composer_update_output.txt
type composer_update_error.txt
type composer_update_exitcode.txt | find "0"

# And finally we clean the environment
del composer_update_*.txt

It would be nice to have a less hacky way to run a command async.

Hope this helps someone.

[renzors]

Awesome!!! Thanks @axelwass I'll try it :)