[SOLVED] How to debug dockerized self-detaching program?

Issue

I am writing Docker images for maintainers of packages for Debian-like distributions. These images are derived from the official images of the respective Debian-like distributions by adding packages required for maintainership and are started with a few useful mounted volumes, so that various configuration items are taken from user's environment instead of being held in the container.

When I start a shell off that image and execute a apt-src build to prepare a package, operation starts normally but the connection between the container and the tty drops inexplicably. Examining the state of the container with docker ps -a shows that it Exited (0). This is very strange, since it means that something causes the shell to exit while its subcommand runs.

Which steps can help me to debug this odd behaviour, figure out what is going on here, and eventually fix it?

---

Container run command

This is how I start the container:

docker run\
    --interactive=true\
    --tty=true\
    --rm=false\
    --volume "${maintainer_pkgdir}:${maintainer_docker_pkgdir}"\
    --volume "${maintainer_srcdir}:${maintainer_docker_srcdir}"\
    --volume "${maintainer_confdir}:${maintainer_docker_confdir}"\
    "${maintainer_repository}/${maintainer_image}"

Session transcript

The session consists of two commands apt-src install bmake and apt-src build bmake:

% apt-src install bmake
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Need to get 544 kB of source archives.
Get:1 http://ftp.debian.org/debian/ unstable/main bmake 20140620-3 (dsc) [1785 B]
Get:2 http://ftp.debian.org/debian/ unstable/main bmake 20140620-3 (tar) [509 kB]
Get:3 http://ftp.debian.org/debian/ unstable/main bmake 20140620-3 (diff) [33.0 kB]
Fetched 544 kB in 0s (681 kB/s)
gpgv: Signature made Tue Sep 16 20:22:02 2014 UTC using RSA key ID 1A2D268D
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./bmake_20140620-3.dsc
dpkg-source: info: extracting bmake in bmake-20140620
dpkg-source: info: unpacking bmake_20140620.orig.tar.gz
dpkg-source: info: unpacking bmake_20140620-3.debian.tar.xz
dpkg-source: info: applying 100_makefile.boot.diff
dpkg-source: info: applying 140_multiarch.diff
dpkg-source: info: applying 160_manpage.diff
dpkg-source: info: applying 180_bmake_path_max.diff
% apt-src build bmake
I: Building in /home/anvil/bmake-20140620 ..
dpkg-buildpackage: source package bmake
dpkg-buildpackage: source version 20140620-3
dpkg-buildpackage: source changed by Andrew Shadura <[email protected]>
dpkg-buildpackage: host architecture amd64
 dpkg-source --before-build bmake-20140620
 fakeroot debian/rules clean
dh clean --with=autoreconf
   dh_testdir
   debian/rules override_dh_auto_clean
make[1]: Entering directory `/home/anvil/bmake-20140620'
/usr/bin/make -f Makefile.boot clean
make[2]: Entering directory `/home/anvil/bmake-20140620'
rm -f arch.o buf.o compat.o cond.o dir.o for.o hash.o job.o main.o make.o make_malloc.o parse.o str.o strlist.o suff.o targ.o trace.o var.o util.o meta.o strlcpy.o lst.lib/lstAppend.o lst.lib/lstAtEnd.o lst.lib/lstAtFront.o lst.lib/lstClose.o lst.lib/lstConcat.o lst.lib/lstDatum.o lst.lib/lstDeQueue.o lst.lib/lstDestroy.o lst.lib/lstDupl.o lst.lib/lstEnQueue.o lst.lib/lstFind.o lst.lib/lstFindFrom.o lst.lib/lstFirst.o lst.lib/lstForEach.o lst.lib/lstForEachFrom.o lst.lib/lstInit.o lst.lib/lstInsert.o lst.lib/lstIsAtEnd.o lst.lib/lstIsEmpty.o lst.lib/lstLast.o lst.lib/lstMember.o lst.lib/lstNext.o lst.lib/lstOpen.o lst.lib/lstRemove.o lst.lib/lstReplace.o lst.lib/lstSucc.o lst.lib/lstPrev.o  bmake
make[2]: Leaving directory `/home/anvil/bmake-20140620'
make[1]: Leaving directory `/home/anvil/bmake-20140620'
   dh_autoreconf_clean
   dh_clean
 debian/rules build

Solution

Attaching a program to a tty seems to be a not completely reliable operation, meaning that it only works under the assumption that the program uses the tty reasonably.

The program su is notorious for abusing the tty is connected to, so rather than troubleshooting the issue it is easier to avoid using su or any other program abusing the tty it is connected to.

Answered By - Michaël Le Barbier

Answer Checked By - Mary Flores (WPSolving Volunteer)