Failed to launch REPL process

Hi all-

I am able to build Swift 4 on Fedora 26 Linux (https://github.com/tachoknight/swift-rpm\) and while it can compile and run Swift code just fine, the REPL does not start because of:

error: failed to launch REPL process: process launch failed: 'A' packet returned an error: -1

I've been searching around and this seems common to running Swift in a Docker container or the Ubuntu shell in Windows. In my case I'm running it on a Fedora 26 virtual machine, so no Docker, no Windows.

I ran an strace on the swift process and I can see that that it tries to spawn a child process which is killed, leading to the error:

--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_KILLED, si_pid=6551, si_uid=1000, si_status=SIGINT, si_utime=0, si_stime=2} ---
write(2, "error: failed to launch REPL pro"..., 94error: failed to launch REPL process: process launch failed: 'A' packet returned an error: -1
) = 94

I get the same error if I run swift as root or sudo. I'm willing to dive into this issue but before I do am wondering if this is a known issue or there's some specific thing I haven't done to make it work. This particular machine is devoted only to getting Swift working on Fedora, so it has no extraneous stuff, no other users, etc.

Thanks for any help!

Ron

1 Like

This occurs when you are running the docker image without a --privileged flag, or without a --cap-add=SYS_PTRACE flag. You are not able to debug any running program, and since the Swift REPL is implemented as a front-end to an lldb debugging instance, it follows that the Swift REPL will not work without the container being launched without either of those flags.

Alex

ยทยทยท

On 24 Oct 2017, at 17:00, Ron Olson via swift-dev <swift-dev@swift.org> wrote:

Hi all-

I am able to build Swift 4 on Fedora 26 Linux (https://github.com/tachoknight/swift-rpm\) and while it can compile and run Swift code just fine, the REPL does not start because of:

error: failed to launch REPL process: process launch failed: 'A' packet returned an error: -1

Hi Alex-

Thanks for the info, but this isn't in a Docker container, just a regular Linux VM.

As an additional bit of info, I ran the build script on my Fedora laptop, and it works just fine; the REPL starts right up. I'd be surprised and confused if this was truly a VM (in this case, VMware ESXi) issue, but stranger things have happened I guess.

Ron

ยทยทยท

On 24 Oct 2017, at 12:11, Alex Blewitt wrote:

On 24 Oct 2017, at 17:00, Ron Olson via swift-dev >> <swift-dev@swift.org> wrote:

Hi all-

I am able to build Swift 4 on Fedora 26 Linux (https://github.com/tachoknight/swift-rpm\) and while it can compile and run Swift code just fine, the REPL does not start because of:

error: failed to launch REPL process: process launch failed: 'A' packet returned an error: -1

This occurs when you are running the docker image without a --privileged flag, or without a --cap-add=SYS_PTRACE flag. You are not able to debug any running program, and since the Swift REPL is implemented as a front-end to an lldb debugging instance, it follows that the Swift REPL will not work without the container being launched without either of those flags.

Alex

Hi Alex-

Thanks for the info, but this isn't in a Docker container, just a regular Linux VM.

Ah, sorry - my bad. I saw Docker in the message with the problem and didn't see the 'not' ;-)

As an additional bit of info, I ran the build script on my Fedora laptop, and it works just fine; the REPL starts right up. I'd be surprised and confused if this was truly a VM (in this case, VMware ESXi) issue, but stranger things have happened I guess.

You can also see this issue if your VM/OS is running under something like selinux or apparmor. You'd have to look into what OS your VM is running to confirm (and compare it with the configuration you have on your laptop).

https://fedoraproject.org/wiki/Features/SELinuxDenyPtrace
http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference

I would have a look to see if either of these settings are denying the PTrace mechanism, which is similar in effect to Docker's runtime options but configured in a slightly different way.

Alex

ยทยทยท

On 24 Oct 2017, at 18:19, Ron Olson <tachoknight@gmail.com> wrote: