Run and troubleshoot rsyslog in a Docker container

A message such as rsyslogd is not running... failed from a service script does not identify the underlying fault. A typical application container has no systemd instance managing services. Run rsyslog in the foreground as the container's main process so its lifecycle and diagnostics are visible.

Build a collector with an explicit configuration

FROM ubuntu:24.04
RUN apt-get update \
    && apt-get install -y --no-install-recommends rsyslog \
    && rm -rf /var/lib/apt/lists/*
COPY rsyslog.conf /etc/rsyslog.conf
CMD ["rsyslogd", "-n", "-iNONE"]

A minimal rsyslog.conf for network reception is:

module(load="imudp")
module(load="imtcp")
input(type="imudp" port="514")
input(type="imtcp" port="514")
action(type="omfile" file="/dev/stdout")

This example runs as the image's default root user and listens on a privileged port. For a non-root deployment, choose an appropriate unprivileged port and writable runtime paths. -n keeps the daemon in the foreground; -iNONE disables the PID file in this single-process setup. See the rsyslog daemon options.

Publish only the protocols and interfaces you intend to expose. A local test might map 127.0.0.1:5514 to container port 514 for TCP and UDP; that deliberately does not accept remote hosts. A receiver for other machines needs an appropriately bound published port, routing, and firewall rules.

Read the actual startup error

Validate the configuration with rsyslogd -N1. For deeper diagnosis, run rsyslogd -n -d -iNONE in a test container and inspect its output. Avoid starting a second instance against the live instance's sockets or files.

• Kernel-log errors: Ordinary containers usually lack access needed by imklog. Omit that module unless reading kernel messages is an intentional, supported part of the deployment.
• Missing /dev/log: A local Unix-socket input can create an appropriate socket; its absence does not inherently require network logging. Configure imuxsock if a legacy application in the same environment needs it. Mounting or sharing a socket requires deliberate permissions and lifecycle management.
• No remote messages: Check the receiver's bind address, container port publishing, and the sender's protocol. A listener inside one network namespace is not automatically reachable from every other host.

Decide whether rsyslog belongs in the container

For applications that can write stdout and stderr, the runtime's logging path is often simpler. A dedicated syslog receiver or a legacy application requiring a local syslog socket can justify rsyslog. Multiple processes are possible, but they need supervision and correct signal/reaping behavior; “one concern per container” is more useful than a literal one-process rule.

For Guance ingestion, configure the actual DataKit TCP/UDP log listener. Kubernetes needs a deliberate reachable Service, host port, or other networking arrangement. Match the configured port and parsing rules, then verify a test event rather than assuming port 514 is DataKit's default.