Today in weird ungoogleable errors:

[longb4@host ~]$ sudo ls
bar     baz     foo
Bus error
[longb4@host ~]$ echo $?
138

Wat. [1]

This was on FreeBSD 10.0-RELEASE (amd64), after executing what I thought would be a routine pkg upgrade. The pkgs that were thusly upgraded had been built in a Poudriere bulk build just moments before. I was logged in as an LDAP user (via pam_ldap, nss_ldap, and openldap-client) and using bash as my shell. New SSH logins to LDAP users still worked and sudoers could still sudo, so I knew at least that PAM, the LDAP client, and sudo weren’t completely hosed. Other commands I tried worked as expected — the misbehavior only manifested when I ran sudo.

Things started making a bit more sense when I discovered that local users (including root) could sudo without the bus error occurring. This narrowed my issue down to the LDAP client stack, which in my experience is constantly looking for new and troubling ways to mysteriously break. I shouldn’t have been surprised.

In the end, I just forcibly rebuilt the packages for the LDAP client stack and then forcibly upgraded them on the client, after which the bus errors stopped happening. I’m inferring that somewhere along the way, a package didn’t get linked against the right library on the Poudriere server or a package didn’t upgrade on the client. On FreeBSD machines that build their own pkgs through ports, I’m in the habit of recursive and forcible portupgrades when upgrading the LDAP client stack, but this experience shows that developing similar habits when using newer methods like Poudriere + pkg upgrade would be worthwhile.

[1] Before you speak up, I know what a bus error is, but just haven’t managed to provoke one on this architecture before — much less by accident.