Segmentation fault on raspberry pi 2 model b
File downloaded from https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-arm.tgz
pi@raspberrypi:~ $ ./cloudflared -v
Segmentation fault
pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.14.52+ #1123 Wed Jun 27 17:05:32 BST 2018 armv6l GNU/Linux
pi@raspberrypi:~ $ lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.4 (stretch)
Release: 9.4
Codename: stretch
pi@raspberrypi:~ $ cat /proc/cpuinfo
processor : 0
model name : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7
Hardware : BCM2835
Revision : 000e
pi@raspberrypi:~ $ sha256sum cloudflared
b3730fd14bc7306b09eafefcef10025aca3f2e94a6059952426a5341ab6e4045 cloudflared
pi@raspberrypi:~ $ file cloudflared
cloudflared: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=adf2825c51e543d9a36dea416573b70eeaa2ac8a, not stripped
Same on Raspberry Pi Zero and Raspberry Pi Zero W.
Same on Pi Zero W. reverted to 2018.6.2
Program received signal SIGSEGV, Segmentation fault. 0x00060ea0 in runtime.moduledataverify1 (datap=0x36333b31) at /usr/local/go/src/runtime/symtab.go:517
Exactly the same issue as well. It's also being reported elsewhere. Reverting to 2018.7.2 works..
the issue is 2018.7.3
@xyzulu how do you revert to 2018.7.2? I can't find the binaries for download.
Here: https://bin.equinox.io/a/4SUTAEmvqzB/cloudflared-2018.7.2-linux-arm.tar.gz
I have also reproduced this issue on my Raspberry Pi Model 1B (rev 2). Reverting to 2018.7.2 as xyzulu suggested works.
Same issue, same device
+1 for same issue on a RPi Model B; 2018-7.2 works but I keep randomly running into this (https://github.com/cloudflare/cloudflared/issues/23) same error with 2018-7.2.
failed to connect to an HTTPS backend and then have to reboot the Pi.
Would love to get this fixed to try a later version of Cloudflared that hopefully resolves that problem :)
+1 on all of the above, including falling back to 2018-7.2 works.
Same issue here on RPi B - Segmentation Fault.
EDIT- 2018-7.2 only works if copied to usr/local/bin and then chmod +x is run.
Same issue with a Raspberry Pi model A. Falling back to 2018-7.2 worked without any further steps.
+1 Can repro on Raspberry Pi 1 B+ with Raspbian Minimal
Same here on Pi 2.
+1 for a Raspberry Pi 1 Model B+, haven't tried reverting to an older version yet.
Falling back to 2018-7.2 does work on a Raspberry Pi Zero W.
I ended up building from source on my Pi Zero W, and it works like a charm. Had to add an extra swapfile in order for the build process to have enough RAM.
I suspect cloudflare's ARM build instance is to blame.
I also had this issue on the Pi Zero W, building from source fixed this for me. I had to add extra swap space to compile properly. Thanks @joehillen
Note: I compiled using Go 1.11.5. I noticed the build config seems to use the 1.9 stream which doesn't receive patches any more.
What command is needed to compile using Go?
sudo apt-get install golang
export GOPATH=$HOME/go
go install github.com/cloudflare/cloudflared/cmd/cloudflared
Hi,
The next cloudflared release will be built with Go 1.11.
Same error on Pi B Version 2019.2.1. 2018.7.2 works.
@sssilver Since there has been a new release, does that mean this issue is fixed?
@sssilver Since there has been a new release, does that mean this issue is fixed?
Does not appear to have been fixed. I tried the current release today and it’s still segfaulting.
cloudflared version 2019.4.1 (built 2019-04-19-2152 UTC) (official binary download))
Works on Raspberry Pi 3b+
Same issue on RPiZeroW with latest Rasberry Pi Stretch with all updates and name showing - Linux ZeroPiHole-I 4.19.42+ #1219 Tue May 14 21:16:38 BST 2019 armv6l GNU/Linux
Latest version 2019.4.1 only works with RPi3B+
pi@ZeroPiHole-I:~ $ dig yahoo.com
; <<>> DiG 9.10.3-P4-Raspbian <<>> yahoo.com ;; global options: +cmd ;; connection timed out; no servers could be reached pi@ZeroPiHole-I:~ $ dig @127.0.0.1 -p 5053 yahoo.com
; <<>> DiG 9.10.3-P4-Raspbian <<>> @127.0.0.1 -p 5053 yahoo.com ; (1 server found) ;; global options: +cmd ;; connection timed out; no servers could be reached pi@ZeroPiHole-I:~ $ ping 1.1.1.1 PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data. 64 bytes from 1.1.1.1: icmp_seq=1 ttl=55 time=23.9 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=55 time=26.9 ms ^C --- 1.1.1.1 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1000ms rtt min/avg/max/mdev = 23.930/25.415/26.900/1.485 ms
Name resolution with 2018.7.2 does not work at all
I referenced this article when setting up DoH - https://docs.pi-hole.net/guides/dns-over-https/
I think the segfault issue is due to released cloudflared being built on a later ARM processor, or cross compiled. The latest current version (2019.5.0) works fine on a Pi 3 B+, whether it stops working after a while (#23), I don't know, didn't test it for long enough, but segfault on a Pi 1B (BCM2835). I installed go1.12.5 linux/arm on the Pi 1B and built from source, release 2019.5.0 plus a few commits (babcd9f), this appears to work, but stops working after a while (#23), it appears to run out of file handles.
Jun 3 06:33:14 jennifer cloudflared[261]: time="2019-06-03T06:33:14Z" level=error msg="failed to connect to an HTTPS backend \"https://1.1.1.1/dns-query\"" error="failed to perform an HTTPS request: Post https://1.1.1.1/dns-query: dial tcp 1.1.1.1:443: socket: too many open files"
Jun 3 06:33:14 jennifer cloudflared[261]: time="2019-06-03T06:33:14Z" level=error msg="failed to connect to an HTTPS backend \"https://1.0.0.1/dns-query\"" error="failed to perform an HTTPS request: Post https://1.0.0.1/dns-query: dial tcp 1.0.0.1:443: socket: too many open files"
Jun 3 06:33:14 jennifer cloudflared[261]: time="2019-06-03T06:33:14Z" level=error msg="failed to connect to an HTTPS backend \"https://1.1.1.1/dns-query\"" error="failed to perform an HTTPS request: Post https://1.1.1.1/dns-query: dial tcp 1.1.1.1:443: socket: too many open files"
Jun 3 06:33:14 jennifer cloudflared[261]: time="2019-06-03T06:33:14Z" level=error msg="failed to connect to an HTTPS backend \"https://1.0.0.1/dns-query\"" error="failed to perform an HTTPS request: Post https://1.0.0.1/dns-query: dial tcp 1.0.0.1:443: socket: too many open files"
Update: Having looked at the Makefile, I built version 2019.5.0 using it...
pi@jennifer:~ $ cd gocode/src/github.com/cloudflare/cloudflared/
pi@jennifer:~/gocode/src/github.com/cloudflare/cloudflared $ git checkout 2019.5.0
Note: checking out '2019.5.0'.
...
HEAD is now at 4bff1ef... Release 2019.5.0
pi@jennifer:~/gocode/src/github.com/cloudflare/cloudflared $ export PATH=$PATH:/usr/local/go/bin
pi@jennifer:~/gocode/src/github.com/cloudflare/cloudflared $ export GOPATH=~/gocode
pi@jennifer:~/gocode/src/github.com/cloudflare/cloudflared $ go clean
pi@jennifer:~/gocode/src/github.com/cloudflare/cloudflared $ make cloudflared
go build -v -ldflags='-X "main.Version=2019.5.0" -X "main.BuildTime=2019-06-03-1717 UTC"' github.com/cloudflare/cloudflared/cmd/cloudflared
pi@jennifer:~/gocode/src/github.com/cloudflare/cloudflared $ ./cloudflared -v
cloudflared version 2019.5.0 (built 2019-06-03-1717 UTC)
This version may be ok, it's now been running for several hours including a Pi reboot and a router reboot.
Version 2019.5.0 built with go1.12.5 on a Pi 1B as in previous post eventually failed due to running out of file handles after about a week...
Jun 10 08:27:44 jennifer cloudflared[1286]: time="2019-06-10T08:27:44Z" level=error msg="failed to connect to an HTTPS backend \"https://1.1.1.1/dns-query\"" error="failed to perform an HTTPS request: Post https://1.1.1.1/dns-query: dial tcp 1.1.1.1:443: socket: too many open files"
Jun 10 08:27:44 jennifer cloudflared[1286]: time="2019-06-10T08:27:44Z" level=error msg="failed to connect to an HTTPS backend \"https://1.0.0.1/dns-query\"" error="failed to perform an HTTPS request: Post https://1.0.0.1/dns-query: dial tcp 1.0.0.1:443: socket: too many open files"
Just checking in that the issue continues with version 2019.6.0
The latest version from https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-arm.tgz gives an instant segfault on a Pi 1B. I can't tell the version because it won't run.
pi@jennifer:~/cd $ tar xzvf cloudflared-stable-linux-arm.tgz
cloudflared
pi@jennifer:~/cd $ ./cloudflared
Segmentation fault
Update: Version 2019.6.0 builds and runs OK on a PI 1B using go1.12.5 linux/arm, downloading an amazing long list of stuff from various sources.
pi@jennifer:~/go/src/github.com/cloudflare/cloudflared $ git checkout 2019.6.0
Note: checking out '2019.6.0'.
...
HEAD is now at acd17f6... Release 2019.6.0
pi@jennifer:~/go/src/github.com/cloudflare/cloudflared $ export GOPATH=~/go
pi@jennifer:~/go/src/github.com/cloudflare/cloudflared $ export PATH=$PATH:/usr/local/go/bin
pi@jennifer:~/go/src/github.com/cloudflare/cloudflared $ make cloudflared
go build -v -ldflags='-X "main.Version=2019.6.0" -X "main.BuildTime=2019-06-21-1621 UTC"' github.com/cloudflare/cloudflared/cmd/cloudflared
... Amazing long list of stuff from various sources ...
pi@jennifer:~/go/src/github.com/cloudflare/cloudflared $ ./cloudflared -v
cloudflared version 2019.6.0 (built 2019-06-21-1621 UTC)
Somewhere I found a tgz file that was compiled for 32 bit Pi, I am assuming those are zero, zero w, a and some older ones? Upon checking the version I have is 2019.5.0 that works perfectly fine on ZeroW. Can’t seem to find the original post or url that hosted the file, however I do have a copy that I can share. I am not sure how to attach it here. Let me know if someone has a website where I can upload
I have on soak test on a Pi 1B an old version I got from here: https://web.archive.org/web/20180419005946/https://bin.equinox.io/c/VdrWdbjqyF/cloudflared-stable-linux-arm.tgz, linked from here: https://web.archive.org/web/20180524132333/https://developers.cloudflare.com/argo-tunnel/downloads, which is version 2018.4.6. It's third choice, so it may take a while to fail if it's going to.
A recent version built from source using a recent Go compiler seems to fail after a while as above.