Azure-docs: azCopy process not terminating on finish

[woodwardmatt]

I'm using azCopy in a release pipeline within the Azure DevOps platform. Having read the above I've configured the following bash task (after installing azcopy) as an inline script:

azcopy \
--source <build agent local file path> \
--destination <file share url> \
--dest-key <security key> \
--recursive \
--verbose

The task runs (and appears to successfully copy files to the Azure File Share from the Build Agents local storage) but then seems to hang at the end simply continuing to echo "[VERBOSE] Finished: 0 file(s), 0 B; Average Speed:0 B/s."

Is there a configuration option I'm missing to terminate the copy process? Shouldn't it simply terminate upon success / failure?

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: e224df65-311e-166c-caff-918f47ad2f57
• Version Independent ID: 21914f58-1720-39d9-acb7-ed8475cab9d4
• Content: Copy or move data to Azure Storage with AzCopy on Linux
• Content Source: articles/storage/common/storage-use-azcopy-linux.md
• Service: storage
• GitHub Login: @seguler
• Microsoft Alias: seguler

[AdamS-MSFT]

@woodwardmatt Thank you for the valuable feedback,we are investigating the issue.
What specific version of AZcopy are you using ? it should normally terminate the copy once it is done.

[woodwardmatt]

Thanks for the quick response @Adam-Smith-MSFT :)

I believe it's this package:

Package: azcopy
Section: admin
Installed-Size: 77756
Maintainer: AzCopy Dev<[email protected]>
Architecture: amd64
Version: 7.2.0-netcore
Depends: libc6 (>= 2.14), libcurl3 (>= 7.16.2), libgcc1 (>= 1:3.0), libgssapi-krb5-2 (>= 1.10+dfsg~), liblttng-ust0 (>= 2.5.0), libstdc++6 (>= 4.8), libunwind8, libuuid1 (>= 2.16), zlib1g (>= 1:1.1.4), libicu55, libssl1.0.0
Filename: pool/main/a/azcopy/azcopy_7.2.0-netcore_ubuntu16.04_x64.deb
Description: Transferring data from/to azure storage blob/file

I install using the following code from the article:

echo "deb [arch=amd64] https://packages.microsoft.com/repos/microsoft-ubuntu-xenial-prod/ xenial main" > azure.list
sudo cp ./azure.list /etc/apt/sources.list.d/
sudo apt-key adv --keyserver packages.microsoft.com --recv-keys EB3E94ADBE1229CF
sudo apt-get update
sudo apt-get install azcopy

It definitely seems odd. Is there anything else I can supply / test to help identify the cause?

[woodwardmatt]

Yep just confirmed:

2018-11-21T00:44:33.9309760Z Preparing to unpack .../azcopy_7.2.0-netcore_amd64.deb ...
2018-11-21T00:44:34.4574490Z Unpacking azcopy (7.2.0-netcore) ...
2018-11-21T00:44:38.1020320Z Setting up azcopy (7.2.0-netcore) ...

[AdamS-MSFT]

@woodwardmatt Is it possible to try it with Azcopy v10? , The newer version has better performance as well as additional options/flags. Let me know if this works for you.

[woodwardmatt]

@Adam-Smith-MSFT Sure - I've updated my pipeline task. This installs and copies the files in one step.

wget -O azcopyv10.tar https://aka.ms/downloadazcopy-v10-linux
tar -xf azcopyv10.tar
cd azcopy_linux_amd64_10.0.4
./azcopy cp $SOURCE "https://[MyStorageAccount].file.core.windows.net/[MyShare]?[MyKey]" --recursive=true --log-level "DEBUG"

where $SOURCE is an environmental variable for $(System.DefaultWorkingDirectory)/app/drop

This installs azcopy fine, then seems to fail on the copy routine. Any thoughts?

2018-11-22T05:25:38.6069507Z Scanning...
2018-11-22T05:25:38.6297381Z 
2018-11-22T05:25:38.6298761Z Job c9946641-9f43-454e-45df-0389fa9d305f has started
2018-11-22T05:25:38.6299244Z 
2018-11-22T05:25:38.6300222Z Log file is located at: /home/vsts/.azcopy/c9946641-9f43-454e-45df-0389fa9d305f.log
2018-11-22T05:25:38.6300589Z 
2018-11-22T05:25:40.6276088Z 0 Done, 0 Failed, 1505 Pending, 0 Skipped, 1505 Total
2018-11-22T05:25:40.6277180Z 
2018-11-22T05:25:40.6277352Z 
2018-11-22T05:25:40.6278208Z Job c9946641-9f43-454e-45df-0389fa9d305f summary
2018-11-22T05:25:40.6278501Z Elapsed Time (Minutes): 0.0333
2018-11-22T05:25:40.6279111Z Total Number Of Transfers: 1505
2018-11-22T05:25:40.6279239Z Number of Transfers Completed: 0
2018-11-22T05:25:40.6279412Z Number of Transfers Failed: 1505
2018-11-22T05:25:40.6279849Z Number of Transfers Skipped: 0
2018-11-22T05:25:40.6279980Z TotalBytesTransferred: 0
2018-11-22T05:25:40.6280100Z Final Job Status: Completed
2018-11-22T05:25:40.6280260Z 
2018-11-22T05:25:40.6448477Z ##[error]Bash exited with code '1'.

[woodwardmatt]

I've also tried the same routine but for a single file (to remove the recursion from the equation) but the same result is observed.

[AdamS-MSFT]

@woodwardmatt that's interesting, is it possible to provide what distro and kernel version you are running it from ? I'd like to do some testing.

[woodwardmatt]

Hey @Adam-Smith-MSFT thanks for getting back to me.

The task runs on the Microsoft hosted Ubuntu 16.04 agent - there'll be some more details for that at: https://github.com/Microsoft/azure-pipelines-image-generation/blob/master/images/linux/Ubuntu1604-README.md

Let me know if there's anything else you need. This is definitely a weird one, just very frustrating as it should be one of the simpler tasks :) Thanks soo much for your help :)

[woodwardmatt]

@Adam-Smith-MSFT - just checking back in, anything come out of the testing so far?

[AdamS-MSFT]

@woodwardmatt My apologies, I escalated the issue internally, Also, let's create a support case in parallel for this issue. If you don't have a support plan in Azure, Could you please reach to me via AZCommunity[AT]microsoft.com with a link to this Issue as well as your subscription ID and we can help get a support ticket opened for this issue. Please mention "ATTN Adam" in the subject field.

[seguler]

@woodwardmatt - is the [MyKey] the account key in the following command ?

./azcopy cp $SOURCE "https://[MyStorageAccount].file.core.windows.net/[MyShare]?[MyKey]" --recursive=true --log-level "DEBUG"

[woodwardmatt]

@segular - yep that's right - as per the File Share Authentication Keys in the Azure Portal

@Adam-Smith-MSFT - Sure thing I'll drop you a message now :)

[woodwardmatt]

@Adam-Smith-MSFT email sent :)

[seguler]

That is the problem. Please use a Shared Access Signature (SAS token), which is a token that can be created through Portal or Storage Explorer, and is in limited scope, and validity. AzCopy v10 no longer supports an account key, which is less secure to use compared to the SAS token.

I must admit you are not the first one to encounter this issue. Please do let me know how we can improve the documentation to make this clear if you have read the AzCopy v10 document

[woodwardmatt]

@seguler - I've just tried this and it has indeed fixed the issue I described earlier (phew!!). I did read the AzCopy v10 Read Me - I think this is probably an easy one to overlook given the historic use of Access Tokens. Maybe an explicit note under this section to clarify that a "Shared Access Signature" and not an "Access Key" (as previously used) should be created to populate the SAS token parameter.

A case of not seeing the wood for the trees on my part there I think, thank you both so much for your support :)

[AdamS-MSFT]

Thanks for the update @seguler , We will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.