Related
I use this on Ubuntu 20.04 and Raspberry Pi OS 5.10 but this is not a Linux related issue.
I'm having an issue with a Go program called Bettercap 2 ( https://www.bettercap.org/ and the repository: https://github.com/bettercap/bettercap ) when I use its function to scan bluetooth devices "ble.recon on" with a different bluetooth dongle.
When I use it with a dongle using Realtek RTL8761b drivers ( MPOW MPBH456AB ) you can find on amazon it works well, but when I use a NordicSemi nrf52840 dongle ( https://www.nordicsemi.com/Products/Development-hardware/nrf52840-dongle ) which is my goal, flashed with Zephyr RTOS' hci_usb sample ( https://github.com/zephyrproject-rtos/zephyr/tree/main/samples/bluetooth/hci_usb ) which is supposed to turn any micro controller using bluetooth into a regular bluetooth dongle that any computer is supposed to recognize as, it throws this error:
>> ble.recon on
panic: runtime error: slice bounds out of range [:1] with capacity 0
goroutine 1 [running]:
github.com/bettercap/gatt/linux/cmd.(*Cmd).SendAndCheckResp(0x1c637c0, 0xa0c760, 0x1c64fe8, 0x1c6501c, 0x1, 0x1, 0x0, 0x0)
/home/pi/go/pkg/mod/github.com/bettercap/gatt#v0.0.0-20210514133428-df6e615f2f67/linux/cmd/cmd.go:98 +0x1b4
github.com/bettercap/gatt/linux.(*HCI).resetDevice(0x18ac0a0, 0x93dc10, 0x18ac0a0)
/home/pi/go/pkg/mod/github.com/bettercap/gatt#v0.0.0-20210514133428-df6e615f2f67/linux/hci.go:273 +0x2f0
github.com/bettercap/gatt/linux.NewHCI(0xffffffff, 0x184fd01, 0xff, 0x2, 0x0, 0x0)
/home/pi/go/pkg/mod/github.com/bettercap/gatt#v0.0.0-20210514133428-df6e615f2f67/linux/hci.go:90 +0x4c0
github.com/bettercap/gatt.NewDevice(0x184fd1c, 0x2, 0x2, 0x3c, 0x184fd24, 0x1, 0x1)
/home/pi/go/pkg/mod/github.com/bettercap/gatt#v0.0.0-20210514133428-df6e615f2f67/device_linux.go:57 +0x114
github.com/bettercap/bettercap/modules/ble.(*BLERecon).Configure(0x18a2780, 0x0, 0x4)
/home/pi/go/pkg/mod/github.com/bettercap/bettercap#v2.24.1+incompatible/modules/ble/ble_recon.go:165 +0x1cc
github.com/bettercap/bettercap/modules/ble.(*BLERecon).Start(0x18a2780, 0x1, 0x1b2c001)
/home/pi/go/pkg/mod/github.com/bettercap/bettercap#v2.24.1+incompatible/modules/ble/ble_recon.go:183 +0x1c
github.com/bettercap/bettercap/modules/ble.NewBLERecon.func1(0x0, 0x0, 0x0, 0x84f358, 0xc)
/home/pi/go/pkg/mod/github.com/bettercap/bettercap#v2.24.1+incompatible/modules/ble/ble_recon.go:56 +0x1c
github.com/bettercap/bettercap/session.(*ModuleHandler).Exec(0x1b2c0c0, 0x0, 0x0, 0x0, 0x0, 0x0)
/home/pi/go/pkg/mod/github.com/bettercap/bettercap#v2.24.1+incompatible/session/module_handler.go:74 +0x80
github.com/bettercap/bettercap/session.(*Session).Run(0x18fb2c0, 0x1c64e30, 0xc, 0x1, 0x1)
/home/pi/go/pkg/mod/github.com/bettercap/bettercap#v2.24.1+incompatible/session/session.go:416 +0x284
main.main()
/home/pi/go/pkg/mod/github.com/bettercap/bettercap#v2.24.1+incompatible/main.go:94 +0x8c8
I have no idea what it means as I'm not a Go developer and have never used this language, I've looked at the error and it seems to be in the code but not knowing Go, I prefer to ask before I modify anything.
The problem is only when I'm using the nrf dongle, otherwise it works with the host's bluetooth and the other realtek dongle.
The nrf dongle works with the BlueZ stack, here are the results:
bluetoothctl ( has a BD address )
Scan does work
$ sudo bluetoothctl
Agent registered
[bluetooth]# list
Controller EB:XX:XX:XX:XX:XX BlueZ 5.50 [default]
btmgmt ( finds the controller )
Scan does work
$ sudo btmgmt --index 0
[hci0]# auto-power
Found controller with index 0
[hci0]# find -l
But, although deprecated, hciconfig and hcitool recognize the realtek dongle but for this one, here are the results:
hciconfig ( no BD address )
$ hciconfig
hci0: Type: Primary Bus: USB
BD Address: 00:00:00:00:00:00 ACL MTU: 27:7 SCO MTU: 0:0
UP RUNNING
RX bytes:1593 acl:0 sco:0 events:88 errors:0
TX bytes:285 acl:0 sco:0 commands:51 errors:0
hcitool ( Doesn't find the controller )
$ hcitool scan
Scanning ...
Inquiry failed: Operation not supported
So, I assume the dongle works well with BlueZ, being the Linux official bluetooth stack it's a good sign, but I thought that Bettercap was also using BlueZ and in that sense the dongle should work.
I don't think there are any drivers to install for the dongle as of the fact that when it is flashed ( J-Link ) it turns into a generic bluetooth dongle.
Do you have any idea what the problem could be ?
I believe the error is coming from https://github.com/bettercap/gatt/blob/master/linux/cmd/cmd.go#L98
The program is attempting to write something to the device and expects that it will receive a response as long as there was no error sending. But apparently the Send call is successful but receives an empty response.
I'd suggest opening an issue over there and asking your question.
I'm trying to write a simple FTP client in Go which will connect to an FTP server, download any files matching a particular pattern (*.xml), and then remove them from the server. I am using Go because it has easy to use support for cross-compilation (important for development) and produces a single static binary (important for deployment). The Linux binary runs fine on Ubuntu 20.04 (the host platform for development) and my Windows 10 Home laptop (cross-compiled with: GOARCH=windows go build ftp-test.go). However, on a Windows 10 Pro machine I get an exception and stack trace which seems to relate to DNS resolution (full output below).
The simplest version of the client is as follows:
package main;
import (
"fmt"
"time"
"github.com/jlaffaye/ftp"
)
func main() {
fmt.Println("Connecting to FTP server")
_, err := ftp.Dial("ftp.mirrorservice.org:21", ftp.DialWithTimeout(60*time.Second))
if err != nil {
fmt.Println(err)
}
}
The full client source code is longer, however as the exception occurs when ftp.Dial is called the above is the minimum code necessary to trigger it. The exception occurs almost instantly, well before the 60 second timeout is hit.
The full stack trace is:
.\ftp-test.exe
Connecting to FTP server
Exception 0xc0000005 0x0 0x7ffae1952fff 0x28cb44e0000
PC=0x28cb44e0000
syscall.Syscall6(0x7ffae07f4c70, 0x4, 0xc0000b60c0, 0x0, 0xc000037f18, 0xc000037e88, 0x0, 0x0, 0x0, 0x0, ...)
/snap/go/6715/src/runtime/syscall_windows.go:201 +0xf2
syscall.GetAddrInfoW(0xc0000b60c0, 0x0, 0xc000037f18, 0xc000037e88, 0x16, 0x0)
/snap/go/6715/src/syscall/zsyscall_windows.go:1718 +0xe5
net.(*Resolver).lookupIP.func1(0x0, 0x0, 0x0, 0x0, 0x0)
/snap/go/6715/src/net/lookup_windows.go:109 +0x259
net.(*Resolver).lookupIP.func2(0xc0000985c0, 0xc0000e8120)
/snap/go/6715/src/net/lookup_windows.go:146 +0x32
created by net.(*Resolver).lookupIP
/snap/go/6715/src/net/lookup_windows.go:145 +0x41b
goroutine 1 [select]:
net.(*Resolver).lookupIPAddr(0x5268e0, 0x41e1e0, 0xc0000e8000, 0x3dbef9, 0x3, 0x3e146f, 0x15, 0x15, 0x0, 0x0, ...)
/snap/go/6715/src/net/lookup.go:299 +0x685
net.(*Resolver).internetAddrList(0x5268e0, 0x41e1e0, 0xc0000e8000, 0x3dbef9, 0x3, 0x3e146f, 0x18, 0x0, 0x0, 0x0, ...)
/snap/go/6715/src/net/ipsock.go:280 +0x4d4
net.(*Resolver).resolveAddrList(0x5268e0, 0x41e1e0, 0xc0000e8000, 0x3dc010, 0x4, 0x3dbef9, 0x3, 0x3e146f, 0x18, 0x0, ...)
/snap/go/6715/src/net/dial.go:221 +0x49d
net.(*Dialer).DialContext(0xc0000e6010, 0x41e1a0, 0xc0000a2058, 0x3dbef9, 0x3, 0x3e146f, 0x18, 0x0, 0x0, 0x0, ...)
/snap/go/6715/src/net/dial.go:403 +0x23c
github.com/jlaffaye/ftp.Dial(0x3e146f, 0x18, 0xc0000cbf50, 0x1, 0x1, 0x19, 0x0, 0x0)
/home/paul/go/src/github.com/jlaffaye/ftp/ftp.go:105 +0x5fc
main.main()
/home/paul/ftp-test.go:11 +0xe5
goroutine 19 [select]:
net.(*Resolver).lookupIP(0x5268e0, 0x41e160, 0xc0000ea000, 0x3dbef9, 0x3, 0x3e146f, 0x15, 0x0, 0x0, 0x0, ...)
/snap/go/6715/src/net/lookup_windows.go:151 +0x1b9
net.glob..func1(0x41e160, 0xc0000ea000, 0xc0000886c0, 0x3dbef9, 0x3, 0x3e146f, 0x15, 0x0, 0x0, 0x0, ...)
/snap/go/6715/src/net/hook.go:23 +0x79
net.(*Resolver).lookupIPAddr.func1(0x0, 0x0, 0x0, 0x0)
/snap/go/6715/src/net/lookup.go:293 +0xc2
internal/singleflight.(*Group).doCall(0x5268f0, 0xc0000d60a0, 0xc0000a0760, 0x19, 0xc0000ea040)
/snap/go/6715/src/internal/singleflight/singleflight.go:95 +0x35
created by internal/singleflight.(*Group).DoChan
/snap/go/6715/src/internal/singleflight/singleflight.go:88 +0x2cc
rax 0x7ffaddecd84a
rbx 0x7ffaddecd848
rcx 0x77
rdi 0xffffffffffbadd11
rsi 0x0
rbp 0x28cb45135d0
rsp 0xbc5e7fe300
r8 0x94b
r9 0x94b
r10 0x94b
r11 0x94b
r12 0x7ffae1760000
r13 0x0
r14 0x7ffaddecd84a
r15 0xc000007a
rip 0x28cb44e0000
rflags 0x10202
cs 0x33
fs 0x53
gs 0x2b
I have already tried:
Updating all dependencies with go get -v -u all.
Forcing a recompilation of the code by deleting the binaries (I usually use a Makefile to only rebuild when necessary).
Running DNS lookups manually, e.g. nslookup ftp.mirrorservice.org - this returns the IP address I expect.
Connecting to the FTP server using ftp on the command line - this works.
Trying a simple "hello world" binary - this works (e.g. if I delete everything bar the fmt.Println("Connecting to FTP server") line, the binary runs without any problems).
Running the binary on Windows 10 Home when Windows Firewall is configured to block all outbound connections. This results in an error message (not an exception with a stack trace) saying that the binary is trying to access a socket and this is forbidden.
Compiling the source code on Windows 10 Home, i.e. not using cross-compilation from Linux. The binary runs on Ubuntu (using WINE) and Windows 10 Home but fails with the same error on the Windows 10 Pro machine.
Unfortunately I have limited access to the Windows 10 Pro machine so I can't install the Go toolchain (as one example).
I am fairly new to Go and rarely target Windows as a platform, so I am not sure if the problem is related to my code, the third party library I'm using for FTP, or Windows (or a combination).
My Go versions are: 1.15.4 linux/amd64 and 1.14.7 windows/amd64
I couldn't find a definitive answer to this question - no security software appeared to be running on the machine other than Windows Firewall - but my software has been successfully deployed elsewhere now so I'm assuming this was a machine-specific problem.
I've set up the gitlab runner on a windows host, and have it pointing to a lubuntu vm.
The vm also has a gitlab runner installed inside it, however the windows host virtualbox executor still cant upload any artifacts.
It keeps saying that the there is no runner installed on the cloned machine - is there something inside the runner that makes it wipe out the cloned VM's gitlab-runner or is it just a bad cloning proccess?
Things I've tried:
I do have a gitlab-runner installed on the VM that is being cloned.
I also made the gitlab ci file try to search for the gitlab-runner with which gitlab-runner and it didn't find it.
As a last resort i made the gitlab ci file install and run a gitlab-runner when it clones the vm (insisde the gitlab ci file in the before_script: section) - this option actually worked and the artifacts were uploaded. This however, I don't feel is a valid solution to the problem and is pretty gross, because it adds a new runner to the gitlab-server each run.
echo passwordgoeshere | sudo -S curl -L --output /usr/local/bin/gitlab-runner https://gitlab-runner-downloads.s3.amazonaws.com/latest/binaries/gitlab-runner-linux-amd64
echo passwordgoeshere | sudo -S chmod +x /usr/local/bin/gitlab-runner
echo passwordgoeshere | sudo -s gitlab-runner install
--user=usernamegoeshere --working-directory=/home/usernamegoeshere
echo passwordgoeshere | sudo -S gitlab-runner register --non-interactive --url "gitlab-server-url" --registration-token "token" --executor "shell" --description "vm_runner" --tag-list "vm" --run-untagged="true" --locked="false" --access-level="not_protected"
echo passwordgoeshere | sudo -S gitlab-runner start
update:
I have sinced changed the vm to a freshly created one and am now getting this error:
Uploading artifacts...
panic: reflect: call of reflect.Value.Type on zero Value [recovered]
panic: reflect: call of reflect.Value.Type on zero Value
goroutine 1 [running]:
main.main.func1()
/go/src/gitlab.com/gitlab-org/gitlab-ci-multi-runner/main.go:32 +0x7f
panic(0x14fcc60, 0xc4204aa200)
/usr/local/go/src/runtime/panic.go:489 +0x2cf
reflect.Value.Type(0x0, 0x0, 0x0, 0x410a9f, 0xc42016d250)
/usr/local/go/src/reflect/value.go:1688 +0x21f
gitlab.com/gitlab-org/gitlab-ci-multi-runner/vendor/gitlab.com/ayufan/golang-cli-helpers.convertMarshal(0x0, 0x0, 0x0, 0xc42016d2b0, 0x4d5dc1, 0xc420091540, 0xc42016d2c0, 0x41db87)
/go/src/gitlab.com/gitlab-org/gitlab-ci-multi-runner/vendor/gitlab.com/ayufan/golang-cli-helpers/convert.go:47 +0x43
gitlab.com/gitlab-org/gitlab-ci-multi-runner/vendor/gitlab.com/ayufan/golang-cli-helpers.convertToString(0x0, 0x0, 0x0, 0x0, 0x0, 0xc42037af80, 0x444fb8, 0x2a, 0x2dc62e6d1d9)
/go/src/gitlab.com/gitlab-org/gitlab-ci-multi-runner/vendor/gitlab.com/ayufan/golang-cli-helpers/convert.go:58 +0x5a
gitlab.com/gitlab-org/gitlab-ci-multi-runner/vendor/gitlab.com/ayufan/golang-cli-helpers.StructFieldValue.String(0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, ...)
/go/src/gitlab.com/gitlab-org/gitlab-ci-multi-runner/vendor/gitlab.com/ayufan/golang-cli-helpers/struct_field.go:32 +0x7b
gitlab.com/gitlab-org/gitlab-ci-multi-runner/vendor/gitlab.com/ayufan/golang-cli-helpers.(*StructFieldValue).String(0xc42037af80, 0x15f73a0, 0xc42037af80)
<autogenerated>:5 +0x70
flag.isZeroValue(0xc4203a33c0, 0x0, 0x0, 0x14922e7)
/usr/local/go/src/flag/flag.go:395 +0x102
flag.(*FlagSet).PrintDefaults.func1(0xc4203a33c0)
/usr/local/go/src/flag/flag.go:469 +0x1b9
flag.(*FlagSet).VisitAll(0xc4204a8060, 0xc42016d610)
/usr/local/go/src/flag/flag.go:325 +0x67
flag.(*FlagSet).PrintDefaults(0xc4204a8060)
/usr/local/go/src/flag/flag.go:478 +0x4f
flag.(*FlagSet).defaultUsage(0xc4204a8060)
/usr/local/go/src/flag/flag.go:511 +0x8e
flag.(*FlagSet).(flag.defaultUsage)-fm()
/usr/local/go/src/flag/flag.go:973 +0x2a
flag.(*FlagSet).usage(0xc4204a8060)
/usr/local/go/src/flag/flag.go:826 +0x2f
flag.(*FlagSet).failf(0xc4204a8060, 0x1719425, 0x22, 0xc42016d898, 0x1, 0x1, 0x0, 0x16f8e6d)
/usr/local/go/src/flag/flag.go:816 +0xea
flag.(*FlagSet).parseOne(0xc4204a8060, 0xc42000e101, 0x0, 0x0)
/usr/local/go/src/flag/flag.go:871 +0x2ee
flag.(*FlagSet).Parse(0xc4204a8060, 0xc42000e120, 0xe, 0xe, 0x31de860, 0x0)
/usr/local/go/src/flag/flag.go:913 +0x60
gitlab.com/gitlab-org/gitlab-ci-multi-runner/vendor/github.com/codegangsta/cli.Command.Run(0x17057a4, 0x12, 0x0, 0x0, 0x0, 0x0, 0x0, 0x1724306, 0x2c, 0x0, ...)
/go/src/gitlab.com/gitlab-org/gitlab-ci-multi-runner/vendor/github.com/codegangsta/cli/command.go:98 +0xb59
gitlab.com/gitlab-org/gitlab-ci-multi-runner/vendor/github.com/codegangsta/cli.(*App).Run(0xc420363b00, 0xc42000e100, 0x10, 0x10, 0x0, 0x0)
/go/src/gitlab.com/gitlab-org/gitlab-ci-multi-runner/vendor/github.com/codegangsta/cli/app.go:159 +0x56f
main.main()
/go/src/gitlab.com/gitlab-org/gitlab-ci-multi-runner/main.go:58 +0x2af
So i figured it out.
The problem was relating to how i installed the gitlab-runner insisde the vm manually.
What i did instead was, create a brand new vm;
intalled git, openssh-server, openssh-lient
ran ssh-keygen ( i'm not sure if i needed this step or not.)
then closed the vm down.
used the virtualbox executor and pointed it at the new vm and it worked perfectly.
for any who finds this, and has searched all of google but found 0 help here is how i set up the runners.
download and install the gitlab runner ( for me i used windows, and there is some security stuff you need to fix if you want to run the runner as a service.) their website has some pretty good info on installing.
work your way through the install stuff, NOTING the username and password you have to use is the same creditintials that you would use to ssh into the VM you want the runner to run on.
the other thing to note is that you need to tell the runner the name of the VM, this is found in Virtualbox and is just it's name.
then you can start the runner with 'gitlab-runner --debug start', just to ensure it's working right.
then regfer to the top section of this answer for how to make sure the vm will need to be configured.
hope this helps.
I am trying to build CockroachDB from sources on a RPi 3, following a couple of posts (this and this).
My RaspberryPi setup:
OS: 2018-06-27-raspbian-stretch
CPU: ARMv7 rev 4(v71)
Mem: 1G + SWAP: 1.5G
Go version: go1.11 linux/arm
I fixed a couple of errors regarding 3rd party libraries while 'make'ing it but now I got stuck on this:
pi#raspberrypi:~/work/go/src/github.com/cockroachdb/cockroach $ make build TAGS='stdmalloc' -j2
GOPATH set to /home/pi/work/go
go build -o cockroach -v -tags 'stdmalloc make arm_linux_gnueabihf_stdmalloc' -ldflags '-X github.com/cockroachdb/cockroach/pkg/build.typ=development -extldflags "" -X "github.com/cockroachdb/cockroach/pkg/build.tag=v2.2.0-alpha.00000000-668-gf76d921f42-dirty" -X "github.com/cockroachdb/cockroach/pkg/build.rev=f76d921f4262356fde83312d0f471262d995f1e0" -X "github.com/cockroachdb/cockroach/pkg/build.cgoTargetTriple=arm-linux-gnueabihf" -X "github.com/cockroachdb/cockroach/pkg/build.utcTime=2018/09/11 12:47:32"' ./pkg/cmd/cockroach
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x0 pc=0x2372b8]
goroutine 1 [running]:
runtime/internal/atomic.goLoad64(0x3d65bdc, 0x0, 0x5607a20)
/usr/local/go/src/runtime/internal/atomic/atomic_arm.go:124 +0x1c
github.com/cockroachdb/cockroach/pkg/util/humanizeutil.(*BytesValue).String(0x55fb578, 0x5607a01, 0x56d9ea0)
/home/pi/work/go/src/github.com/cockroachdb/cockroach/pkg/util/humanizeutil/humanize.go:109 +0x28
github.com/cockroachdb/cockroach/pkg/cli.(*bytesOrPercentageValue).String(0x57b4920, 0x56d9ea0, 0x7)
/home/pi/work/go/src/github.com/cockroachdb/cockroach/pkg/cli/flags_util.go:492 +0x20
github.com/cockroachdb/cockroach/vendor/github.com/spf13/pflag.(*FlagSet).VarPF(0x54d3a00, 0x25cf778, 0x57b4920, 0x1ef3864, 0xe, 0x0, 0x0, 0x56d2900, 0x169, 0x56d9ea0)
/home/pi/work/go/src/github.com/cockroachdb/cockroach/vendor/github.com/spf13/pflag/flag.go:778 +0x24
github.com/cockroachdb/cockroach/vendor/github.com/spf13/pflag.(*FlagSet).VarP(0x54d3a00, 0x25cf778, 0x57b4920, 0x1ef3864, 0xe, 0x0, 0x0, 0x56d2900, 0x169)
/home/pi/work/go/src/github.com/cockroachdb/cockroach/vendor/github.com/spf13/pflag/flag.go:786 +0x5c
github.com/cockroachdb/cockroach/pkg/cli.VarFlag(0x54d3a00, 0x25cf778, 0x57b4920, 0x1ef3864, 0xe, 0x0, 0x0, 0x0, 0x0, 0x1fa4462, ...)
/home/pi/work/go/src/github.com/cockroachdb/cockroach/pkg/cli/flags.go:129 +0x6c
github.com/cockroachdb/cockroach/pkg/cli.init.5()
/home/pi/work/go/src/github.com/cockroachdb/cockroach/pkg/cli/flags.go:324 +0x6c0
Makefile:1288: recipe for target 'docs/generated/settings/settings.html' failed
make: *** [docs/generated/settings/settings.html] Error 2
make: *** Deleting file 'docs/generated/settings/settings.html'
Any ideas what might be wrong?
thanks for the question. I was the original author of that blog post. It looks like you're running into an issue related to https://github.com/golang/go/issues/9959. It looks like golang requires 64-bit alignment of 64-bit words when atomically accessed. This is somewhat tricky to enforce across an entire project. Still, we can try to get this working by removing the atomic access on pkg/util/humanizeutil/humanize.go:109 (which doesn't look necessary) and replacing it with return IBytes(*b.val). That should at least get you past this roadblock. There may be other issues you run into after this though. Unfortunately, CockroachDB has never set up CI around a 32-bit ARMv7 build because 32-bit architectures have never been officially supported by the project.
However, a 64-bit ARMv8 build is more actively maintained. In fact, an entire cross-compilation toolchain has been introduced to build CockroachDB for ARMv8 on an x86_64 host. Compilation using this toolchain can be kicked off by running build/builder.sh mkrelease arm64-linux-gnueabi. The resulting binary can be dropped onto a RaspberryPi running a 64-bit OS like https://wiki.debian.org/RaspberryPi3. I actually tried this out last week and ran into no problems.
I'm running wercker.com on Mac OS. Once in a while wercker crashes with the following error message although the container keeps running:
PANIC dial tcp 192.168.99.100:2376: socket: too many open files
panic: (*logrus.Entry) (0x6bfa60,0xc8202ceb00)
goroutine 2101 [running]:
github.com/wercker/wercker/vendor/github.com/Sirupsen/logrus.(*Entry).log(0xc8202ceb00, 0x0, 0xc8203d87c0, 0x39)
/gopath/src/github.com/wercker/wercker/vendor/github.com/Sirupsen/logrus/entry.go:103 +0x5fb
github.com/wercker/wercker/vendor/github.com/Sirupsen/logrus.(*Entry).Panic(0xc8202ceb00, 0xc8203ebd30, 0x1, 0x1)
/gopath/src/github.com/wercker/wercker/vendor/github.com/Sirupsen/logrus/entry.go:148 +0x7c
github.com/wercker/wercker/docker.(*WatchStep).Execute.func5(0xc82037ba40, 0xc8202ceb40, 0xc820178640, 0xc82005cd60, 0xc820165800, 0x40, 0xc8203b5860, 0xc82010bce0, 0xc82037b8c0)
/gopath/src/github.com/wercker/wercker/docker/watchstep.go:297 +0x723
created by github.com/wercker/wercker/docker.(*WatchStep).Execute
/gopath/src/github.com/wercker/wercker/docker/watchstep.go:312 +0x91d
...
I'm running a Typescript Node.js app inside the container which is being restarted often via wercker's "internal/watch". Typescript is being compiled to JS outside of the container by the IDE, but all the files are shared with the container.
What is the best way to avoid this issue?
After setting the local file limits up, it's working.
See: Is there a fix for the “Too many open files in system” error on OS X 10.7.1.