cannot set terminal process group (-1): Inappropriate ioctl for device

[stapler117]

I've successfully completed a couple of gitian builds for Dogecoin, but as of recently, I've been getting an error that Google shows affected the su command in a particular version of Debian. This occurred after I pulled a more recent version of gitian-builder, but the issue still persists after checking out older commits. I am running ubuntu server 14.04 on a fresh VM. Creating the base VM's for gitian appears to work fine. I'm using LXC and here is the output.

user@gitian:/gitian-builder$ ./bin/gbuild ../dogecoin/contrib/gitian-descriptors/deps-linux.yml
--- Building for precise i386 ---
Stopping target if it is up
Making a new image copy
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
root@gitian:# exit
Starting target
Checking if target is up
Preparing build environment
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
To run a command as administrator (user "root"), use "sudo ".
See "man sudo_root" for details.

ubuntu@gitian:~$ exit
tar: This does not look like a tar archive
tar: Exiting with failure status due to previous errors
lxc-start: The container failed to start.
lxc-start: Additional information can be obtained by setting the --logfile and --log-priority options.
./bin/gbuild:21:in system!': failed to run copy-to-target inputs/openssl-1.0.1h.tar.gz build/ (RuntimeError) from ./bin/gbuild:80:inblock in build_one_configuration'
from ./bin/gbuild:78:in each' from ./bin/gbuild:78:inbuild_one_configuration'
from ./bin/gbuild:235:in block (2 levels) in <main>' from ./bin/gbuild:230:ineach'
from ./bin/gbuild:230:in block in <main>' from ./bin/gbuild:228:ineach'
from ./bin/gbuild:228:in `

'

[stapler117]

I confirmed the "Inappropriate ioctl for device" issue with @Andymeows on IRC.

It turns out that Ubuntu 12.04 works just fine. The only needed step with that is to 'apt-get uninstall ruby1.8' and 'apt-get install ruby1.9' as "Dir.exists?" is not in ruby 1.8. My best guess is a recent update in ubuntu 14.04 within the last month has broken something that gitian does. Just to clarify, I'm able to use make-base-vm just infe in 14.04

[gurnec]

It looks like lxc-start is ignoring its stdin and stdout (from the host), instead of passing them between the host and the guest. In other words, redirects to lxc-start are being ignored, and lxc-start's stdout is empty even when the guest produces output.

I wonder if this commit is the cause?

[devrandom]

Let me know if this fixes the issue. You need lxc installed in the guest (automatically done for new images).

[Michagogo]

@devrandom It looks to me like that change causes all kinds of other trouble. For example, it apparently breaks building in a precise lxc on a debian stable host. Looks like it may be because precise's lxc package installs files to /usr/lib/lxc, and apparently debian's lxc-execute tries to use /usr/lib/x86_64-linux-gnu/lxc/lxc-init in the guest, which doesn't exist. I don't know if it fixes this particular issue, but even if it does, it causes a whole bunch of trouble in different ways...

[gurnec]

I don't know if it fixes this particular issue

It does fix this issue, for me at least, for one combination of host/guest (precise on trusty).

It looks to me like that change causes all kinds of other trouble.

As I mentioned in the #69 PR, I couldn't come up with a good way to fix this problem that avoided the possibility of regressions. The only option I could think of that wouldn't be a maintainability headache would be to try method A, and if that didn't work, try method B (which feels hackish, but may be the best alternative...)

Maybe the result of which method works could be cached in a per-target config file, although no such file exists at the moment. Alternatively, both methods might need to be tried for each run of on-target or copy-*

Any other ideas?

In the mean time, I'm in favor of reverting this commit until it can be properly written. (precise on Debian stable is probably a lot more common than something on trusty)

[devrandom]

Please take a look at the latest commit. I punted to an environment variable switch.

[gurnec]

That's nice and simple. Making lxc-start the default, as you did, seems best.

[devrandom]

Assuming this is fixed, please reopen if not.