Open swizzlr opened 8 years ago
The real was definitely working for me, but I was installing all the deps that apple was suggesting. Should we put those deps back for completeness sake? We might be breaking other parts of the toolchain without knowing it but not having deps apple details in their docs. Perhaps revert that commit and see what happens?
@hamin When they say "development dependencies" I assume they mean for building the swift toolchain itself. (right, @jckarter)? I'll work backwards from the list of dependencies and find which libraries are necessary; then I'll open a PR to the swift repo updating their docs.
@swizzlr yeah what you're saying makes sense, checking it out
@hamin just tried "reverting" those changes and no dice. are you sure it worked for you, back then? maybe it's flaky?
So its working for me right now. I'm running latest master:
@swizzlr its working for me. I'm running latest master
@swizzlr what were you trying to run exactly?
@swizzlr argh sorry its not running for me...i was running my old docker image...gimme a few
@swizzlr confirmed this master is not working for me...the above screenshot was from my original repo. It definitely worked
Does this commit work 369c495ac18df95d9cf48df22a71df299446cd2c ?
@swizzlr checking it out. Meanwhile do a docker pull from here https://hub.docker.com/r/harisamin/docker-swift/
docker pull harisamin/docker-swift
Try that and see if it works there
Nope, not working on this (digital ocean VM hooked up with docker-machine).
docker run -it harisamin/docker-swift bash
error: failed to launch REPL process: process launch failed: 'A' packet returned an error: 8
wtf how is it working for me then from my original image. you're just typing swift
right? I know there's a swift_repl
not sure what exactly that one does
We need a third person to try this out to figure out which of our machines is wrong. The image ID is c9f6b5fece4f
, what's yours?
The one I pushed to Docker Hub earlier today was this: harisamin/docker-swift latest 48660452cc49
Again from original one I had.
@swizzlr master on our repo:
Step 7 : RUN wget https://swift.org/builds/ubuntu1404/swift-2.2-SNAPSHOT-2015-12-01-b/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
---> Running in 0e5501001ce0
--2015-12-04 00:32:30-- https://swift.org/builds/ubuntu1404/swift-2.2-SNAPSHOT-2015-12-01-b/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
Resolving swift.org (swift.org)... 169.45.67.140
Connecting to swift.org (swift.org)|169.45.67.140|:443... connected.
HTTP request sent, awaiting response... 404 Not Found
2015-12-04 00:32:30 ERROR 404: Not Found.
Checking if there's a new tar, maybe apple removed the old one
@swizzlr lol the link is dead: https://swift.org/builds/ubuntu1404/swift-2.2-SNAPSHOT-2015-12-01-b/swift-2.2-SNAPSHOT-2015-12-01-b-ubuntu14.04.tar.gz
Got it from here: https://swift.org/download/
On my own docker implementation I had user reporting the same issue. Funny thing is it work for my docker on VM.
@lxcid That's fascinating! Do you think you could find out what the implementations are?
Maybe this is a TTY thing?
I was interested in creating a latest
image that would provide the most recent version built from source. Perhaps if we try building from scratch inside the container we might unearth the dependencies that are not present?
I'm trying to build from source at the moment though. Its painfully slow, maybe its because I'm building a release build.
Use the following python (2.7) script https://github.com/apple/swift/blob/master/utils/build-script
I'm not sure if I can wait until it complete but I'll keep you updated on my finding.
root@ab75a4cb7eff:/usr/src/swift# ./build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift --version
Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift c959ce2c83)
Target: x86_64-unknown-linux-gnu
root@ab75a4cb7eff:/usr/src/swift# ./build/Ninja-ReleaseAssert/swift-linux-x86_64/bin/swift
LLVM ERROR: Compiler-internal integrated REPL unimplemented for this platform
This is the output of the release build.
I'm doing another debug build at the moment.
@lxcid do u mind trying the latest master? I've tested the current master on my local docker instances and am able to launch the repl without issue. Let us know :)
I just tried the latest master fb7ff42fc3039141342b7020a3626e7ba20db50a but it still have the same error in Digital Ocean docker.
I suspect it is the binary that have issue.
@hamin you running it on your MB in boot2docker?
I installed docker via their official mac DMG.
sh --login '/Applications/Docker/Docker Quickstart Terminal.app/Contents/Resources/Scripts/start.sh'
That's how i start it its funny because looking at #12 seems like @sosedoff was able to deploy our image and it seems to be running.
Im running swift docker image: swiftdocker/swift:836d5b4ca56e and it works fine on both linux and osx machines. Locally (on osx) im using docker-machine and can run REPL with this command:
$ docker run -it swiftdocker/swift swift
Welcome to Swift version 2.2-dev (LLVM 46be9ff861, Clang 4deb154edc, Swift 778f82939c). Type :help for assistance.
1>
I'm laboriously downloading the entire thing to my local machine now, but I think we might be able to isolate this to digitalocean. Curious, but not worth leaving in the open without more reports.
I can confirm it works locally!
This is so weird.
Works locally on OS X. Failed on EC2.
https://hub.docker.com/r/swiftdocker/swift/ https://hub.docker.com/r/ontouchstart/docker-swift-snapshot/ (my own docker image)
I have this issue too (on clean install ubuntu 14.04 VM),
But I found that if I add the --privileged
to docker command, it works
otherwise I got error: failed to launch REPL process: process launch failed: 'A' packet returned an error: 8
@CorcovadoMing awesome find! I can confirm that --privileged=true
fixed it. I still like to know whats wrong though. I going to do some more investigation.
@CorcovadoMing Awesome find! Would be great to know what's causing this. If its something we can fix in our docker configuration I'm game :). @CorcovadoMing @lxcid feel free to submit PR :)
It seems that we may need to fix swift, it may be attempting to access hardware that it isn't allowed to find.
As you can see, there is no problem with interpreted the swift file without lldb via swift *.swift
and also compiled with swiftc
command in docker without --privileged=true
lldb seems to need to access the bottom layer to provide the runtime information
is it possible that we manually disable the lldb debugger to run swift repl? for now, I think the whole swift repl is built on top of lldb, so there are not much thing we can do on docker configuration
You can't run interactive swift without lldb, I've tried. Seems we need to figure out what lldb needs at the machine level.
--privileged
worked for me
sudo docker run --privileged -it ontouchstart/docker-swift-snapshot
I'd suggest we document this in the README, since we don't have any power over this right now, then close this issue.
If anyone else is looking, this issue is already listed on the swift bug tracker: https://bugs.swift.org/browse/SR-54
Fixed by #24
@hamin @gabhi You can use --security-opt seccomp=unconfined
instead to disable seccomp. It's a little more secure. :)
docker run -it --security-opt seccomp=unconfined --name swiftfun swiftdocker/swift:latest /bin/bash
Indeed -- --privileged
is a huge hammer, and should be used with extreme caution and care. It'd be useful IMO to narrow down exactly which part of Docker's default seccomp profile is causing the denial, especially so either the debugger can be fixed to not require that (if possible) or a custom profile to allow it can be written (to avoid using a bare unconfined
). :+1:
@tianon thanks for the tip. we know it's something to do with accessing keyboard drivers in LLDB, but we might have more luck following up on their mailing list. In any case, REPL support is something rarely requested – most devs have their own local install of Swift that works just fine for that. It would be very nice to have a permanent solution.
@tianon @swizzlr @hamin that works:
docker run --cap-add sys_ptrace -ti --rm swiftdocker/swift swift
@aduermael niiiice, I've confirmed that's working here too! That's way better. :metal:
@tianon @aduermael Thanks so much Adrian! I will fold this into the documentation.
So, to run the REPL we need to add the sys_ptrace key which allows you to "Trace arbitrary processes using ptrace(2)."
https://docs.docker.com/engine/reference/run/#/runtime-privilege-and-linux-capabilities
Now we just need to figure out how necessary that is, and if the REPL can run without it!
The Swift.org community makes use of the LLDB debugger to provide a rich REPL as well as the debugging environment for the Swift Language
@swizzlr the REPL uses LLDB, and LLDB needs ptrace...
Hello, I download the latest official swift image from docker hub and there is still the problem with REPL.
mbp-de-loic:Orange loik$ docker run --cap-add sys_ptrace -ti --rm swift swift
error: failed to launch REPL process: process launch failed: 'A' packet returned an error: 8
mbp-de-loic:Orange loikos$ docker images swift
REPOSITORY TAG IMAGE ID CREATED SIZE
swift latest d505ae70cb39 2 weeks ago 1.15 GB
Can't make it work even using --cap-add sys_ptrace
but it work with --privileged
@swizzlr @hamin
Overview
Swift REPL requires LLDB. LLDB requires some elevated privileges.
Objectives