Offline package drop file access problem

Hi

I have a problem with the Offline Package Drop feature. My deployment process has two NuGet steps that use the same NuGet package. Each step installs the same NuGet package as a Windows service but with different settings. The NuGet package is called inQuba.VoC.EventProcessor and I get the following error when the package is uploaded during the deployment:

The process cannot access the file ‘C:\Offline Package Drops\WesBank QA\inQuba CX\4.9.0.152\Packages\inQuba.VoC.EventProcessor.4.9.0.152_E305A464E7107A4B84BC5B8C22D2E9CC.nupkg’ because it is being used by another process.
System.IO.IOException: The process cannot access the file ‘C:\Offline Package Drops\WesBank QA\inQuba CX\4.9.0.152\Packages\inQuba.VoC.EventProcessor.4.9.0.152_E305A464E7107A4B84BC5B8C22D2E9CC.nupkg’ because it is being used by another process.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream…ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
at System.IO.FileStream…ctor(String path, FileMode mode, FileAccess access, FileShare share)
at Octopus.Shared.Util.OctopusPhysicalFileSystem.OpenFile(String path, FileMode mode, FileAccess access, FileShare share) in Y:\work\refs\tags\3.1.3\source\Octopus.Shared\Util\OctopusPhysicalFileSystem.cs:line 184
at Octopus.Worker.OfflineDrop.OfflineDropBatch.StagePackage(RequiredPackage requiredPackage, IPackageSource packageSource, TargetManifest targetManifest) in Y:\work\refs\tags\3.1.3\source\Octopus.Worker\OfflineDrop\OfflineDropBatch.cs:line 65
at Octopus.Worker.OfflineDrop.OfflineDropWorker.StagePackage(RequiredPackage acquisition, IPackageSource packageSource, TargetManifest targetManifest) in Y:\work\refs\tags\3.1.3\source\Octopus.Worker\OfflineDrop\OfflineDropWorker.cs:line 28
at Octopus.Server.Orchestration.Deploy.Acquire.AcquireMachinePackageTask.Acquire(AcquiredPackageMap acquiredPackageMap) in Y:\work\refs\tags\3.1.3\source\Octopus.Server\Orchestration\Deploy\Acquire\AcquireMachinePackageTask.cs:line 27
at Octopus.Shared.Tasks.OctoThreadClosure`1.Execute() in Y:\work\refs\tags\3.1.3\source\Octopus.Shared\Tasks\OctoThreadClosure.cs:line 29
Octopus.Server version 3.1.3 (3.1.3+Branch.master.Sha.645480fc4eeb916ceefd1725a1d0a80493cabfb6)

It appears that both steps are trying to upload the same package and it is causing a file access error. If I exclude one of the two steps then the deployment is successful.

Thanks

ServerTasks-3398.log.txt (34 KB)

Hi,

Thanks for reaching out. We fixed this in 3.1.6 https://github.com/OctopusDeploy/Issues/issues/2090

Please try to upgrade to the latest to get the fix for this issue.

Best regards

Dalmiro

I upgraded to 3.2 and the problem is fixed.

Thanks Dalmiro.

Hello. It looks like we have a similar problem. We use Octopus 3.2.7.

We have special Octopus Environment with two Offline deployment targets (Offline Package Drop type). Let’s name them “QA Server 1 Drop” and “QA Server 2 Drop”.

Both Offline deployment targets has the same role (only one role for each target).

Octopus project has special steps for this role: the first multi-step contains two child steps: “Stop Windows Service A” and “Stop Windows Service B”.

Sometimes we have next issue while creation of the deployment package for this environment. Note: the issue is occured while the deployment creation and presented in the Octopus Web UI, not during the real deployment on the offline target machines.

The first multi-step is successfully passed for the first offline deployment target ( “QA Server 1 Drop” ), both child steps are successful. But for the second one ( “QA Server 2 Drop” ) the first child step ( “Stop Windows Service A” ) is failed with next error:

The process cannot access the file "\\octopusdeployserver\OfflineDrops\QA Offline Environment\QA Test Project\1.1.100.2\Scripts\Stop Windows Service A.ps1" because it is being used by another process.

But after the deployment restart the result is successful. The most probability to reproduce this issue is the first deployment of the new octopus Project release.

Could you please check this issue? Please let me know if you need some additional details/logs.

Raw deployment log is attached to this post.

Thank you.

ServerTasks-8379.txt (4 KB)

Hello.

Sorry, do we have any updates on it?

Unfortunately, the issue reported by me on Dec 08, 2015 still reproduced in the Octopus 3.2.13

Hi Igor,

I deeply apologize for the delay here.

We’ve had reports of a similar issue, but re the Nuget Package Deploy step: https://github.com/OctopusDeploy/Issues/issues/2090

I’m gonna consult this issue with the team get back to you by tomorrow.

Best regards,
Dalmiro

Hi Dalmiro,

Thank you for the response - It’s all ok :slight_smile:

This is not a blocked issue because of after the second attempt it usually successfully made the package.

Best regards,
Igor Arslanov

Hi Igor,

After you run the 2nd attempt, do you get the expected Deployment Package on the Offline Drop Path?

Is it possible that you have both Offline QA Server Drop 1 & QA Server Drop 2 with the exact same Offline Drop Path? Because that was the only way I was able to reproduce this issue. If that is the case, you should have each target with a different drop path (Ideally something like \\QAServerDrop1\offline & \\QAServerDrop2\offline). Otherwise you’ll never get the 2 packages (one per target) you were looking for.

Regards,
Dalmiro

Hi Dalmiro,

Yes, on the 2nd attempt we got the expected Deployment Package on the Offline Drop Path .

Yes, it’s exactly the case what we had: QA Server Drop 1 & QA Server Drop 2 had the same Offline Drop Path. We have changed it to the two different folders and all work fine now on the 1st attempt.

Thank you very much for your response: the problem was fixed. We could close this discussion.

Good luck and have a nice 2016 year! :slight_smile:

I believe Octopus Team will present us a lot of good features in the new year.

Best regards,
Igor Arslanov

Very glad to hear that!

Cheers