On Fri, Jun 5, 2015 at 7:39 PM, Konstantin Khomoutov <flatw...@users.sourceforge.net> wrote: > On Fri, 5 Jun 2015 16:25:21 +0200 > Alexander Thomas <alexander.thomas+d...@esaturnus.com> wrote: > > [...] >> That would be an option, but it might still cause the same problem of >> apt-get hanging as we currently experience when doing the update >> before runlevel S. >> >> We looked deeper into this and found out that apt-get always hangs >> while installing a package before the first runlevel switch. An strace >> reveals an endless loop of SIGCONT and ioctl calls. Running other >> commands that use ioctl also results in a hang, so the controlling >> terminal seems to lack certain capabilities at this stage. We have >> found a workaround: we spawn a new terminal with agetty and run the >> update script in there, this allows to perform the apt-get >> dist-upgrade in runlevel S and avoid the init 1 hack. > > I would try running apt-get with </dev/null >somelogfile 2>&1 > redirections: that should ensure it sees no terminal at all on its stdin > and that should avoid code paths dealing with TTY-related ioctls > altogether. (Well, excluding the isatty(3) call which supposedly uses > fstat(2) and checks to see the device's major number is that of a TTY).
The </dev/null avoids the hang indeed. I haven't looked at the code but it makes sense that when apt-get starts configuring the packages, it will probe the terminal or prepare it for user interaction. We falsely assumed that setting DEBIAN_FRONTEND=noninteractive APT_LISTCHANGES_FRONTEND=none, and using the -y and --force-yes options, would never invoke terminal-related code. Thanks! -- Alexander Thomas -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/cakr4ymxoqq0a-rvztymts3c371tgxocvx+yra96ovyy6y-d...@mail.gmail.com