Issue in Deployment to Linux servers


(manoj_singi) #1


I have issue in deploying to linux servers and when 1st release it gets stuck at the error attached and cancelling that and redeploying works fine.
i have attached the error screen shot and also the task log.
in the error it says cannot start the task and in brackets it says error no task. Please check and reply back.


servertasks-219403_8z6774vl3k.txt (122.9 KB)

(Shane Gill) #2

Hi Manojreddy,

Thanks for getting in touch.

Can you help me understand a little bit more about what is happening.

The first time you create and deploy a release it gets stuck on the “Deployment of Files to Server” step with the message “Cannot start this task yet because…”. You cancel the deployment and immediately redeploy and the deployment works without a problem?

Does this happen every time you deploy a new release?


(manoj_singi) #3

yes its happening everytime i creating release and deploying and once cancelled and redeploying works. and if you see the error msg its not throwing any task in queue. usually it throws a task ID but here in error it says Error - No Task.

(Shane Gill) #4

Hi Manojreddy,

I am completely stumped.

If you leave the deployment running does it ever resume?
Does this happen on all of your SSH targets?
What version of linux and version of mono are you running?


(manoj_singi) #5

It Only happens on 4 linux servers and not all of them.
And if i leave as it it stays with sate as Cannot start the task and if i cancel it and re-run then it gets succeded.

Below are the details of the server which is causing this issue.

Host Name:
October 12th 2018 14:36:41Info
Running As: \OctopusDeployAdmin
October 12th 2018 14:36:41Info
Bash version: 4.1.2(1)-release
October 12th 2018 14:36:41Info
OS: Linux 2.6.32-754.2.1.el6.x86_64 x86_64
October 12th 2018 14:36:41Info
Distro: “Red Hat Enterprise Linux Server release 6.10 (Santiago)” (Santiago)
October 12th 2018 14:36:41Info
Filesystem Size Used Avail Use% Mounted on
October 12th 2018 14:36:41Info
October 12th 2018 14:36:41Info
7.3G 5.9G 989M 86% /
October 12th 2018 14:36:41Info
tmpfs 16G 0 16G 0% /dev/shm
October 12th 2018 14:36:41Info
/dev/sda1 488M 70M 393M 16% /boot
October 12th 2018 14:36:41Info
October 12th 2018 14:36:41Info
2.0G 760M 1.1G 42% /opt
October 12th 2018 14:36:41Info
October 12th 2018 14:36:41Info
3.9G 1.1G 2.6G 31% /var
October 12th 2018 14:36:41Info
October 12th 2018 14:36:41Info
543G 64G 452G 13% /app
October 12th 2018 14:36:42Info
Mono version: Mono JIT compiler version (tarball Wed Jan 17 18:50:44 UTC 2018)

(Shane Gill) #6

Hi Manojreddy,

Do you have any ideas what about those 4 machines is different to the rest?

I’ve tried reproducing using RHEL 6.10 with mono running a deploy a package step but do not encounter the “Cannot start the task…” message. I’ve tried running on machines with the same fingerprint (clones of each other) and they do lock but then unlock and the lock message indicates a script is running in the same deployment.

Does it only happens for “Deploy a package steps”? Can you deploy a single bash script step without getting the “Cannot start the task…” message?


(manoj_singi) #7

Hi Shane,

Yes it happens on “Deploy a Package step”.
Yes i can get the bash script but not the Deploy a package Step and also i can get the health check when the deployment is in this state with “Cannot start the task…”.


(manoj_singi) #8

Any Update on this.

(Shane Gill) #9

Hi Manojreddy,

I’m not sure how else I can help you. From all of the testing we have done with your exact version of linux, mono and bash we are unable to replicate the issue. We have not had reports of this issue from other customers, so I can only conclude there is something specific to those four machines that is causing the issue.

I can help answer questions or provide details about that particular lock but I feel like some troubleshooting needs to happen on your end to determine why those specific machines are having a problem.


(system) #10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.