Subject: [bug#77578] [PATCH 1/2] tests: docker-system: Remove unnecessary services from Docker image.

From: Ludovic Courtès <[email-masked]>
Date: Fri, 25 Apr 2025 17:17:54 +0200

Hi,

Oleg Pykhalov <[email-masked]> writes:

> 'run-docker-system-test' was hanging during execution of 'herd status' inside
> a container. This occurred because '%test-docker-system' specified more
> services than 'gnu/system/examples/docker-image.tmpl', which may have caused
> conflicts or unexpected behavior.
>
> * gnu/tests/docker.scm (%test-docker-system): Remove
> static-networking-service-type, udev-service-type, urandom-seed-service-type,
> shepherd-system-log-service-type. Add syslog-service-type.
>
> Change-Id: I2c3f7bc54fa6b5a802c8e16cba6ffae0cd09d4cc
> +                        (services
> +                         (modify-services
> +                             (append
> +                              (operating-system-user-services os)
> +                              (list
> +                               (service syslog-service-type
> +                                        (syslog-configuration
> +                                         (extra-options
> +                                          '("--rcfile=/etc/syslog.conf"
> +                                            "--no-forward"
> +                                            "--no-unixaf"
> +                                            "--no-klog"))))))
> +                           ;; 'herd status' is unresponsive. Investigation
> +                           ;; needed to resolve before migrating from syslog
> +                           ;; logging.
> +                           (delete shepherd-system-log-service-type)

I think that’s because by default ‘system-log-service’ tries to open
/proc/kmsg; it fails in the container, which causes ‘system-log’ to fail
to start, and then nothing starts.

The solution is to modify ‘shepherd-system-log-service-type’ to set
‘kernel-log-file’ to #f (similar to ‘--no-klog’ above).

> +                           ;; Containers are created with limited privileges
> +                           ;; by default as a security measure. This
> +                           ;; restriction can prevent direct configuration of
> +                           ;; networking or hostname settings, which often
> +                           ;; require elevated permissions. Container runtimes
> +                           ;; typically manage these aspects using internal
> +                           ;; mechanisms and the CNI (Container Network
> +                           ;; Interface) standard, abstracting away much of
> +                           ;; the underlying network configuration.
> +                           (delete static-networking-service-type)
> +
> +                           ;; Inside a container, the device tree is often
> +                           ;; limited and controlled by a container runtime.
> +                           (delete udev-service-type)
> +                           ;; Seeding urandom rely on devices that are not
> +                           ;; available inside the container.
> +                           (delete urandom-seed-service-type)))))

I realized that ‘containerized-operating-system’ already attempts to do
exactly that (it misses udev, urandom, and system-log handling though).

Should we use it here, adjusting it as needed?

Thank you, and apologies for the back-and-forth,
Ludo’.