Hab pkg exec fails with Illegal Instruction

We are working on creating a squid package, which will form the basis of an outbound proxy layer for a number of our applications. We intend to make the squid package available to core plans, so want to keep it as simple and reusable as possible.

At the moment we’re still working to ensure that squid uses the pkg.svc_var_path for state, and have been seeing some inconsistencies.

I have a package that I built using hab 0.54.0/20180221022026 on a Debian host, which seems to work on my Debian machine. I took the hart from the results directory and copied it to a different machine (a CentOS 7 VM), and installed it using the same version of hab.

Starting the service with hab start atalanta/squid results in some of the same state issues which I haven’t resolved yet, but of more concern is that when I try to run squid -z with hab pkg exec to test the cache creation, I get an Illegal Instruction error. Attached is the strace of this error.

I’m raising this in case this indicates a deeper and more serious issue. I’m confident I will resolve the broader state issues with squid, but this seemed like an unexpected and potentially alarming error, so in the interests of the project I"m sharing it here.

@sns what does ldd show against that squid binary?

Gist of strace here: https://gist.github.com/Atalanta/eb50f18c6e84fd89a583f6bef11988c6

$ ldd /hab/pkgs/atalanta/squid/3.5.27/20180228055354/sbin/squid
	linux-vdso.so.1 =>  (0x00007ffe7c75e000)
	libpthread.so.0 => /hab/pkgs/core/glibc/2.22/20170513201042/lib/libpthread.so.0 (0x00007f81349c4000)
	libcrypt.so.1 => /hab/pkgs/core/glibc/2.22/20170513201042/lib/libcrypt.so.1 (0x00007f813478b000)
	libstdc++.so.6 => /hab/pkgs/core/gcc/5.2.0/20170513202244/lib/../lib/libstdc++.so.6 (0x00007f8134411000)
	libnsl.so.1 => /hab/pkgs/core/glibc/2.22/20170513201042/lib/libnsl.so.1 (0x00007f81341f9000)
	libresolv.so.2 => /hab/pkgs/core/glibc/2.22/20170513201042/lib/libresolv.so.2 (0x00007f8133fe1000)
	librt.so.1 => /hab/pkgs/core/glibc/2.22/20170513201042/lib/librt.so.1 (0x00007f8133dd9000)
	libdl.so.2 => /hab/pkgs/core/glibc/2.22/20170513201042/lib/libdl.so.2 (0x00007f8133bd5000)
	libm.so.6 => /hab/pkgs/core/glibc/2.22/20170513201042/lib/libm.so.6 (0x00007f81338d6000)
	libgcc_s.so.1 => /hab/pkgs/core/gcc/5.2.0/20170513202244/lib/../lib/libgcc_s.so.1 (0x00007f81336c0000)
	libc.so.6 => /hab/pkgs/core/glibc/2.22/20170513201042/lib/libc.so.6 (0x00007f813331c000)
	/hab/pkgs/core/glibc/2.22/20170513201042/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00005648d8874000)

Can you attach the squid plan you have? I’d like to give it a run locally

The strace certainly looks like it can’t find basically any of the libraries linked by glibc even though ldd shows correct. Illegal instruction is typically caused by a CPU instruction in the binary that CPU can’t understand. E.G. if you moved the package over to a box running an i686 or ARM or something from an x86_64 proc.

Exactly - but if that were the case, the process wouldn’t run under the supervisor. Also the architecture is not different:

$ uname -a
Linux REDACTED 3.10.0-693.17.1.el7.x86_64 #1 SMP Thu Jan 25 20:13:58 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

$ uname -a
Linux REDACTED 4.9.0-5-amd64 #1 SMP Debian 4.9.65-3+deb9u2 (2018-01-04) x86_64 GNU/Linux

That is supremely bizarre. If we could take a look at the plan to try and reproduce that would likely be helpful. This isn’t something I’ve seen before!

I wonder if --disable-native-arch is what’s causing the heartburn

1 Like

So this is supposed to fix that problem: