[MXS-3995] Logs are not sent to STDOUT Created: 2022-02-11  Updated: 2022-07-06  Resolved: 2022-07-06

Status: Closed
Project: MariaDB MaxScale
Component/s: StartupScripts
Affects Version/s: 6.2.0
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: William Scott Assignee: Esa Korhonen
Resolution: Duplicate Votes: 0
Labels: Logging

Issue Links:
Relates
relates to MXS-3457 Add logging to stdout in the docker i... Closed

 Description   

I've encountered two loosely coupled issues and am interested in contributing to their resolution.

  1. Maxscale Docker images no longer log to stdout after version 2.5.X (difficult to determine, see follow up issue). This is obviously problematic, as this is how Docker aggregates logs. A brief investigation determined that this was due to an entrypoint script.

    [root@0db4086c260e /]# ps -ewwf
    UID        PID  PPID  C STIME TTY          TIME CMD
    root         1     0  0 Jan05 ?        00:01:16 /usr/bin/tini -- docker-entrypoint.sh /bin/sh -c maxscale-start && monit -I
     
    [root@0db4086c260e /]# cat /usr/bin/docker-entrypoint.sh
    #!/bin/bash
     
    function exitMaxScale {
            /usr/bin/monit unmonitor all
            /usr/bin/maxscale-stop
            /usr/bin/monit quit
        }
     
    rm -f /var/run/*.pid
    rsyslogd
     
    trap exitMaxScale SIGTERM
     
    exec "$@" &
     
    wait 
    

    To the best of my understanding, this exists to triage maxscale into a multi-process container (monit managing maxscale and rsyslog). I am not familiar with rsyslog, and consequently cannot comment on its necessity, but ideally logs are sent to stdout to re-enable process logging.

  2. Upon discovery of the aforementioned issue, I began to investigate the github repository to find additional information (e.g. when rsyslog was introduced, its purpose, etc.). My first stop was to identify when the new entrypoint was defined, as that would provide the most contextual information. However, the Dockerfile presented within the repository hasn't been updated in four years (version 2.2). Consequently, it is difficult to perform further investigative efforts or contribute to the project.

Please advise on how I should proceed.



 Comments   
Comment by William Scott [ 2022-03-02 ]

I'm wondering if the solution is as simple as changing the container entrypoint,
e.g. within the dockerfile,

ENTRYPOINT "maxscale --user=maxscale --nodaemon --log=stdout"

or within the service definition (for testing)

services:
  maxscale:
    image: "${MAXSCALE_IMAGE}"
    entrypoint: "maxscale --user=maxscale --nodaemon --log=stdout"

The new entrypoint bypasses the existing entrypoint maxscale_start.sh script which invokes rsyslog, monit, and maxscale w/o the --log=stdout and --nodaemon flags. My only hesitation is I don't know why the existing entrypoint, which goes through a lot of trouble to implement monit & rsyslog, is used. Logging to stdout, and single process containers, are both best practices.

Comment by markus makela [ 2022-07-06 ]

I'll close this as a duplicate of MXS-3457 since this is known and expected behavior with the current images.

Generated at Thu Feb 08 04:25:27 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.