Syslog output with few or even single characters by conmon (not full lines).

[FootStark]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

conmon-output to syslog produces single or double character outputs mith mssql container. This completely floods log in /var/log/syslog. It would be great if conmon would buffer and wait for newline before printing to syslog. Or delay and buffer output for maybe up to 10 ms.

Related issues: #2500 looks like being somewhat similar but wasn't fixed 100%.

Steps to reproduce the issue:

As systemd-service: podman run -d -e=ACCEPT_EULA=Y -e=SA_PASSWORD=My_Init0_Pwd -e=MSSQL_PID=Express mcr.microsoft.com/mssql/server:2019-latest

Describe the results you received:

Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: At
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: t
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: em
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: p
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: t
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: in
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: g
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]:  t
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: o
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]:  l
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: oa
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: d
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]:  l
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: i
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: br
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: a
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: ry
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]:  
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: 'x
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: p
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: lo
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: g
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: 70
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: .
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: dl
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: l
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: ' 
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: i
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: nt
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: o
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]:  m
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: e
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: m
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: or
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: y
Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: . 

Describe the results you expected:

Oct  3 21:08:58 vm-ubuntuprod01 conmon[598655]: Attempting to load library 'xplog70.dll' into memory.

Additional information you deem important (e.g. issue happens only occasionally):

This issue is likely related to the way the mssql-container outputs log data.

Output of podman version:

Version:      3.4.4
API Version:  3.4.4
Go Version:   go1.17.3
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info:

host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers:
  - cpuset
  - cpu
  - io
  - memory
  - hugetlb
  - pids
  - rdma
  - misc
  cgroupManager: systemd
  cgroupVersion: v2
  conmon:
    package: 'conmon: /usr/bin/conmon'
    path: /usr/bin/conmon
    version: 'conmon version 2.0.25, commit: unknown'
  cpus: 10
  distribution:
    codename: jammy
    distribution: ubuntu
    version: "22.04"
  eventLogger: journald
  hostname: vm-ubuntuprod01.int.pp-software.net
  idMappings:
    gidmap: null
    uidmap: null
  kernel: 5.15.0-47-generic
  linkmode: dynamic
  logDriver: journald
  memFree: 112824320
  memTotal: 5047332864
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version 0.17
      commit: 0e9229ae34caaebcb86f1fde18de3acaf18c6d9a
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/podman/podman.sock
  security:
    apparmorEnabled: true
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: false
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.0.1
      commit: 6a7b16babc95b6a3056b33fb45b74a6f62262dd4
      libslirp: 4.6.1
  swapFree: 5133664256
  swapTotal: 6442442752
  uptime: 407h 45m 19.49s (Approximately 16.96 days)
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries: {}
store:
  configFile: /etc/containers/storage.conf
  containerStore:
    number: 4
    paused: 0
    running: 4
    stopped: 0
  graphDriverName: btrfs
  graphOptions: {}
  graphRoot: /dataSSD/containers/storage
  graphStatus:
    Build Version: Btrfs v5.15.1
    Library Version: "102"
  imageStore:
    number: 8
  runRoot: /dataSSD/containers/running
  volumePath: /dataSSD/containers/storage/volumes
version:
  APIVersion: 3.4.4
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.17.3
  OsArch: linux/amd64
  Version: 3.4.4

Package info (e.g. output of rpm -q podman or apt list podman or brew info podman):

podman/jammy,now 3.4.4+ds1-1ubuntu1 amd64  [installiert]

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

Troubleshooting Guide: Yes
Latest Version: Yes, latest available via apt

Additional environment details (AWS, VirtualBox, physical, etc.):

Ubunutu 22.04 running as VM in Hyper-V on WinSrv2022

[baude]

please try the latest version of podman (4.2) and conmon (2.1.4)

[Luap99]

I think this is the expected behaviour at the moment, see containers/conmon#335

You should have a CONTAINER_PARTIAL_MESSAGE field in the journald which tells you that this is not the full line. If you run podman logs it will read the journal correctly and print the lines correctly.