Why is systemd-oom the owner of my podman container volume?

soulprovidr

7/12/24, 1:10 AM

I'm attemping to run Listmonk using the provided Docker method, but I'm encountering an issue related to systemd-oom that I am struggling to understand.

I've mapped the /var/lib/postgresql/data volume in the db service to my local /srv/listmonk/data folder and set the SELinux context appropriately.

Here is the issue: as soon as I run sudo docker-compose up -d (I'm using podman-docker), the owner of the /srv/listmonk/data directory and all files within it becomes systemd-oom.

The app runs fine and I am able to access and use it, but I can't understand what's happening here. My server has 64GB of RAM and I haven't seen any spikes in usage while starting the containers that might be triggering systemd-oom. Could this be happening from within the db container itself?

How can I prevent this from happening?

Here is my docker-compose.yml:

version: "3.7"

x-app-defaults: &app-defaults
  restart: unless-stopped
  image: listmonk/listmonk:latest
  ports:
    - "9000:9000"
  networks:
    - listmonk
  environment:
    - TZ=Canada/Eastern

x-db-defaults: &db-defaults
  image: postgres:13
  ports:
    - "9432:5432"
  networks:
    - listmonk
  environment:
    - POSTGRES_PASSWORD=<...>
    - POSTGRES_USER=listmonk
    - POSTGRES_DB=listmonk
  restart: unless-stopped
  healthcheck:
    test: ["CMD-SHELL", "pg_isready -U listmonk"]
    interval: 10s
    timeout: 5s
    retries: 6

services:
  db:
    <<: *db-defaults
    container_name: listmonk_db
    volumes:
      - /srv/listmonk/data:/var/lib/postgresql/data:Z

  app:
    <<: *app-defaults
    container_name: listmonk_app
    depends_on:
      - db
    volumes:
      - /srv/listmonk/config.toml:/listmonk/config.toml:Z
      - /srv/listmonk/uploads:/listmonk/uploads

networks:
  listmonk:

424

1 + 0

fedora

systemd

docker

docker-compose

podman

Score:4

Server

BMitch

7/12/24, 1:49 AM

Files share uid's between the container and host (without user namespaces) when you mount a volume. So a file with uid 999 in the container will have uid 999 on the host (just like permission bits are the same between both). So if the container changes ownership of files in its volume, then you'll see that ownership change, by uid, on the host. You can compare the /etc/passwd in the container vs your host to see what host user maps to which container user. Here are the user mapping in the container for the postgres:13 image, where you can see postgres is uid 999:

root@9a946afa90cc:/# cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
_apt:x:42:65534::/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
postgres:x:999:999::/var/lib/postgresql:/bin/bash

+ 0

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Why is systemd-oom the owner of my podman container volume?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.