I am trying to use machine and install PHP 7.1 on it but I am running into problems with files being locked after running sudo apt-get update. These are the commands I am using:
I know this may be considered a Linux issue, but this is such a basic use-case that I would hope CircleCI would want it to be possible without having to do resort to complex Bash scripting to get around this problem.
BTW, I am using machine because I later want to my own set of Docker containers that require a sandboxed VM to operate correctly.
I don’t think I have seen this reported here before. I wonder whether people would normally install things like PHP first, and then do their checkout. You have them reversed, which perhaps gave the machine more time to throw a spanner in the works.
Is that even with the stop, kill and wait? I can’t imagine why that would fail. (Of course it depends on what failed - were these failures still lock issues?)
I have decided to give up on this and take the path of least resistance for now and just use a Docker image. My thoughts are now that CircleCI are putting no efforts into machine so choosing it will be folly. I guess I will have to figure out Docker-in-Docker later.
I suspect that DinD is more work, to be honest. My view is that if you have a PHP build to run, this is your best bet to meet the 2.0 deadline, especially if you are not familiar with Docker. I’d recommend:
Posting the result of swapping the install and checkout
Posting the build logs after the kill/wait script is installed
I am entirely confident that this can be made to work with minimal extra effort.
Sorry, I was probably not clear on my short term requirements. I don’t need to run other Docker containers inside a VM before August 31st, that is longer term. I was just trying to kill two birds with one stone and get experience with machine. I can cross the D-in-D bridge or machine bridge later when we actually get to that point.
As it is, I have already moved on and have been working on the scripts I need to do the deploys that we are using CircleCI to make happen. I’ve still got a lot of work to do there so I don’t think it would be wise at this time to try to resolve the machine + PHP install problems. But I really thank you for your interest in helping.
Maybe when I revisit this (or someone else will have solved the problem by then?)
running into a similar issue when installing awscli on machine classic:201808-01. but only some of the branches have this error. unfortunately those branches are master and release. all of the other development branches skip right through without any problem. i’ve tried throwing a sudo apt-get install -f to force dpkg to resolve its issues and unlock, but that only seems to work on the development branches and not master.
this issue only started to show up when we moved from machine classic:201710-01 to the more recent image. i’m thinking now there’s something wrong with that machine.
i can’t just put internal code up on a public repo, but i can at least post the makefile command that’s falling apart. maybe there’s a simple bug i just can’t see?
i’m already seeing one issue with the hack/workaround missing the double-ampersand to block while it executes.
E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?
Exited with code 100
the issue was bad enough and intractable enough that we’ve moved off circleci and onto travis ci where machine setups are supported.
the solutions here go down a path of fixing the VM with special commands and scripts and we really don’t want to be in the businesses of managing our managed service.
This works fine for me. I’ve added a sleep in, I think that might have been one of the fixes linked to earlier. Has your experience been intermittent, or has it failed reliably?
That’s fine - I don’t work for CircleCI, so I have no axe to grind regarding whose service you use. I am also a big believer in letting teams choose their own tools. Nevertheless, you are likely to hit a roadbump with Travis, at which point you’ll take out your frustration on Travis forum volunteers and decide that only GitLab cares about support. Eventually you’ll run out of (good) CI providers to try.
For your own benefit, I would urge you to change your approach.
