systemd-related hacks in the lxc templates for Debian containers

[Antonio Terceiro]

Hello,

[please cc: me in replies; I'm not in the list]

I was approached by Michael some days ago about the systemd-related
hacks that are present in the lxc template for debian containers.

Back before the jessie release, I put together what made debian
containers with systemd mostly work for me, and there were a few
followups after that, and at the end today we have this (please wait
until you read everything before yelling at me!):

configure_debian_systemd()
{
    path=$1
    rootfs=$2
    config=$3
    num_tty=$4

    # this only works if we have getty at .service to manipulate
    if [ -f ${rootfs}/lib/systemd/system/getty\@.service ]; then
       sed -e 's/^ConditionPathExists=/# ConditionPathExists=/' \
           -e 's/After=dev-%i.device/After=/' \
           < ${rootfs}/lib/systemd/system/getty\@.service \
           > ${rootfs}/etc/systemd/system/getty\@.service
    fi

    # just in case systemd is not installed
    mkdir -p ${rootfs}/{lib,etc}/systemd/system
    mkdir -p ${rootfs}/etc/systemd/system/getty.target.wants

    # Fix getty-static-service as debootstrap does not install dbus
    if [ -e $rootfs//lib/systemd/system/getty-static.service ] ; then
        local tty_services=$(for i in $(seq 2 $num_tty); do echo -n "getty at tty${i}.service "; done; )
        sed 's/ getty at tty.*/'" $tty_services "'/g' \
                $rootfs/lib/systemd/system/getty-static.service |  \
                sed 's/\(tty2-tty\)[5-9]/\1'"${num_tty}"'/g' > $rootfs/etc/systemd/system/getty-static.service
    fi

    # This function has been copied and adapted from lxc-fedora
    rm -f ${rootfs}/etc/systemd/system/default.target
    chroot ${rootfs} ln -s /dev/null /etc/systemd/system/udev.service
    chroot ${rootfs} ln -s /dev/null /etc/systemd/system/systemd-udevd.service
    chroot ${rootfs} ln -s /lib/systemd/system/multi-user.target /etc/systemd/system/default.target
    # Make systemd honor SIGPWR
    chroot ${rootfs} ln -s /lib/systemd/system/halt.target /etc/systemd/system/sigpwr.target
    # Setup getty service on the ttys we are going to allow in the
    # default config.  Number should match lxc.tty
    ( cd ${rootfs}/etc/systemd/system/getty.target.wants
        for i in $(seq 1 $num_tty) ; do ln -sf ../getty\@.service getty at tty${i}.service; done )

    # Since we use static-getty.target; we need to mask container-getty at .service generated by
    # container-getty-generator, so we don't get multiple instances of agetty running.
    # See https://github.com/lxc/lxc/issues/520 and https://github.com/lxc/lxc/issues/484
    ( cd ${rootfs}/etc/systemd/system/getty.target.wants
        for i in $(seq 0 $num_tty); do ln -sf /dev/null container-getty\@${i}.service; done )

    return 0
}

These basically fixed two main issues at the time:

- the lack of udev in the container caused a significant (read f*ing
  long) delay in booting the container

- it was not possible to login using the consoles of the container,
  hande the getty-related hacks.

I built myself a locally-modified version of the lxc package removing
all of the above, and got the following results after testing both
jessie and stretch containers:

- no boot delays anymore. I assume the underlying issue has been fixed
  in systemd since.

- I again cannot login to the extra consoles (lxc-console -n
  $CONTAINER), in both jessie and stretch. I also tested this on an
  Ubuntu xenial container, and there it just works out of the box.

  Further info:

  - if I boot the Debian container in the foreground (lxc-start -F -n
    $CONTAINER), then there is a main getty on /dev/console (from the
    PoV of the container), on the same terminal where I started the
    container, which does work (probably because /dev/console is already
    in /etc/securetty).  The extra ones (pts/0, pts/1, pts/2) still
    don't.

  - the getty processes are started with pretty much the same command
    line on both stretch and xenial, AFAICT

  - /etc/securetty is the same on stretch and xenial

  - /etc/securetty does contain:

    lxc/console
    lxc/tty1
    lxc/tty2
    lxc/tty3
    lxc/tty4

    but from the point of view of the containers, the getty processes
    attach to pts/* instead.

  - I can "make it work" on stretch and jessie by adding a line with
    "pts/0" to the end of /etc/securetty.

  - there are not systemd-related bits in the Ubuntun templates AFAICT

  - The only tty-related bits I could find in the Ubuntu templates are:

    # remove jobs for consoles 5 and 6 since we only create 4 consoles in
    # this template
    rm -f $rootfs/etc/init/tty{5,6}.conf

    which seem to be actually related to upstart (/etc/init/*.conf) so I
    am not convinced those have anything to do with it.

So AFAICS, if we can fix this issue with the consoles, either in systemd
or in lxc, we would be good to go to remove these hacks. Any ideas?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/attachments/20160805/8c1f0683/attachment.sig>