env vars can't be managed on a system-wide basis / inserted (you can only modify your current, and pass it to children), and are easy to lose (one blanket reset and it's gone forever), and you have to preserve the value.  so the file behavior isn't unreasonable.  it's the same reason we have /etc/ld.so.preload -- LD_PRELOAD isn't sufficient.

that said, on CrOS, i don't see a problem with patching either out.  we don't currently track or change or care about hwcap features (today) in any process.

Is this problem in CrOS or Goobuntu?

strace ls 2>&1 | grep /etc/ld.so.nohwcap

returns nothing inside Cros or on DUT, it returns

access("/etc/ld.so.nohwcap", F_OK)      = -1 ENOENT (No such file or directory)

in Goobuntu.

Oh...sorry!

ihf's traces were from autotest server which are running ubuntu or debian. Ilja?

So maybe the right answer is to take the ssh built in the chroot and use that on autotest servers.

This is on Goobuntu and possibly Ubuntu. But servers also use ssh from the chroot. So rather messy, as we have 3 different ssh binaries. But I guess the one on Goobuntu is the most important/most commonly used by autotest.

By the way, if this is low hanging fruit I am ok to fix this, but if this requires major work we should probably just work on dropping/replacing ssh.

Goobuntu/Ubuntu are not yunlian's problem.

Can we redirect all ssh calls to one built for the chroot? That's the only one that we (google) "own" the toolchain for.

executing ssh out of the chroot but in the host env is a bad idea (due to library version skew), and i don't think it'd help here ... if the access calls are coming from glibc, then running the ssh from the sdk but in the host env would use the host glibc which has those access calls.

Mike,I was thinking of using USE=static for the chroot build - then it shouldn't depend on any libs in the goobuntu or ubuntu environment, right?

I don't know if that's really entirely true but it _should_ work fine. It's what I've been doing to test other things in the past.

In any case, I've given up trying to update anything in goobuntu (or ubuntu) and feel that our test environment should use our own chroot to provide the tools needed to run tests. The fact that three different version of ssh are in use really bothers me.

an openssh[static] would be less problematic here, but unfortunately glibc still loads nss modules from the host system for network and user resolution :/

Given this is expected behavior for current Goobuntu and ssh isn't going to get updated in Goobuntu, I'm closing this bug as "no fix; WAI".

I'll open a new bug to address the fact the we are using three different SSH binaries to run autotest.

Yunlian, Luis, my apologies for the false alarm. :(