Subject: bug#34211: error running container: mingetty cannot find ttys

From: Ludovic Courtès <[email-masked]>
Date: Mon, 11 Feb 2019 23:20:21 +0100

Hi Giovanni,

Giovanni Biscuolo <[email-masked]> skribis:

> plase is there someone else that could reproduce this issue with "guix
> system container": https://issues.guix.info/issue/34211 ?

[...]

> Feb  6 12:45:44 localhost /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[217]: tty5: No such file or directory
> Feb  6 12:45:44 localhost /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[216]: tty6: No such file or directory
> Feb  6 12:45:44 localhost /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[218]: tty3: No such file or directory
> Feb  6 12:45:44 localhost /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[219]: tty2: No such file or directory
> Feb  6 12:45:44 localhost /gnu/store/mbq93mr1vbs6za0n0yn32gfsyq1wx6xf-mingetty-1.08/sbin/mingetty[220]: tty1: No such file or directory
>
> I have to TERM the the container since the "ttN: No such file or
> directory" message loops indefinitely

I also get this behavior.

What happens is that the /dev/ttyN nodes do not exist (understandably),
and thus the ‘console-font-ttyN’ Shepherd services fail to start, and
get restarted, indefinitely.

The container is working as expected though.  If you find the PID of the
container’s ‘shepherd’ process (its PID 1, which obviously has a
different PID outside the container), then you can do:

  guix container exec NNN /bin/sh

where NNN is that PID of that ‘shepherd’ process (I use ‘pstree’ to find
the PID… not very convenient.)

In that shell, you can do:

--8<---------------cut here---------------start------------->8---
sh-4.4#  . /etc/profile         
sh-4.4# ls
bin  dev  etc  gnu  home  proc  root  run  sys  tmp  var
sh-4.4# herd status
Started:
 + containerized-shepherd
 + file-systems
 + guix-daemon
 + host-name
 + loopback
 + nscd
 + root
 + root-file-system
 + ssh-daemon
 + syslogd
 + term-tty1
 + term-tty2
 + term-tty3
 + term-tty4
 + term-tty5
 + term-tty6
 + udev
 + urandom-seed
 + user-file-systems
 + user-processes
 + virtual-terminal
Stopped:
 - console-font-tty1
 - console-font-tty2
 - console-font-tty3
 - console-font-tty4
 - console-font-tty5
 - console-font-tty6
 - networking
 - term-auto
 - user-homes
--8<---------------cut here---------------end--------------->8---

So in that sense everything is working “as expected.”

Now, it would make more sense to simply remove those ‘console-font-ttyN’
services in a container and everything that depends on them.  Not sure
if we should do that automatically.

Thoughts?

Thanks,
Ludo’.