[smtp-relay] monitoring enabled causes CrashLoopBackOff

[leleobhz]

Describe the bug a clear and concise description of what the bug is.

Hello!

Enabling monitoring causes the following log in chatwork/kumina-postfix-exporter:edge pod:

2025/05/15 17:06:22 Reading log events from /var/log/maillog
2025/05/15 17:06:22 Failed to create PostfixExporter: open /var/log/maillog: no such file or directory

What is the proper way to fix it?

Thanks!

What's your helm version?

version.BuildInfo{Version:"v3.17.3", GitCommit:"e4da49785aa6e6ee2b86efd5dd9e43400318262b", GitTreeState:"", GoVersion:"go1.24.2"}

What's your kubectl version?

Client Version: v1.32.4 Kustomize Version: v5.5.0 Server Version: v1.32.4+k0s

Which chart?

smtp-relay

What's the chart version?

latest

What happened?

No response

What you expected to happen?

No response

How to reproduce it?

No response

Enter the changed values of values.yaml?

metrics:
  enabled: false
  prometheusRules:
    enabled: true
  serviceMonitor:
    enabled: true
smtp:
  host: "<REDACTED>"
  username: "<REDACTED>"
  password: "<REDACTED>"
  hostname: "<REDACTED>"
  mynetworks:
    - "10.244.0.0/16"
    - "192.168.42.0/24"
    - "fd00::/108"
  tls_security_level: "encrypt"
  tls_wrappermode: "yes"

service:
  type: ClusterIP
  loadBalancerIP: "192.168.50.1"
  port: 25

Enter the command that you execute and failing/misfunctioning.

helm upgrade --kube-context=brgvhomekubearmorial --install --history-max=1 --create-namespace --namespace=smtp-relay --repo https://djjudas21.github.io/charts/ --values smtp-relay.values.yaml smtp-relay smtp-relay

Anything else we need to know?

No response

[djjudas21]

Thanks for reporting. You haven't done anything wrong, this seems to be a real bug and I am able to recreate it. I'll have a look at a fix later 🙂

[djjudas21]

Just to explain the problem space a bit better. The metrics sidecar container is crashing because it is trying to open /var/log/maillog, which doesn't exist in the metrics container.

The metrics exporter is kumina-postfix-exporter and it has a configurable option for where you can set the log file destination. In theory, it would be possible to create a shared volume between the postfix and metrics containers, make postfix log there, and tell the metrics exporter to read there.

However this then creates the need to manage and rotate those log files, which implies also needing some kind of rsyslog container or service. So we then need to configure Postfix and rsyslog to continue logging to container stdout, but also to the temporary log file for the metrics exporter. I think this solution is too heavyweight. There's a discussion here: kumina/postfix_exporter#68

It is also possible to set the metrics exporter to check a Docker socket to read logs on stdout, but unfortunately it doesn't work with Kubernetes.

The "least bad" solution I can think of is to set the exporter to read null log files from /dev/null. It will still allow the exporter to report some metrics that it can obtain from the postfix socket, but it will not get the full set.

It's a realy sticky problem without making a very complex solution. There are some other Postfix containers available that bundle supervisord and rsyslog, but I explicitly wanted to keep my container lightweight, because supervisord inside Kubernetes is an anti-pattern.

[leleobhz]

Hello @djjudas21 !

Was Kubernetes able to handle FIFO between sidecar and main container?

That asked, if it works, maybe the /var/log/maillog be a FIFO shared between both containers. If it not works, the painless way is a logrotate sidecar (Something more maintained than https://hub.docker.com/r/blacklabelops/logrotate for example) and keep it there in the ephemeral_storage.

Anyways, some metric is better than no metric. I suggest approve the PR and keep this open to track a better solution. I'm a bit overloaded from my job but I can try to at least test some solution without promisses.