Linux- segmentation fault if multiple podman quadlets start at boot

[nitinkmr333]

What's wrong

This is continuation of #546. I guess it would be better to keep it as a separate issue instead of re-opening the older issue, as the problem is with podman quadlets and not non-root user. Please see my last comment in the previous issue. The segmentation fault is caused by two (or more) podman quadlet configurations stored in ~/.config/containers/systemd/.

What were you trying to do, and what happened instead?
I get segmentation fault when running the linux release/appimage.

❯ ./github_store.appimage
[1]    5005 segmentation fault (core dumped)  ./github_store.appimage

How to reproduce

These are the exact steps to reproduce the issue-

1. Install podman if not already installed (see https://podman.io/docs/installation).
2. Run mkdir -p ~/.config/containers/systemd/ to create a directory to store podman quadlets (quadlets are similar to docker-compose files but to run/define containers with podman instead of docker). We will run rootless podman here.
3. Create two (or more) quadlets and they must start at boot (i.e., need install target).

❯ mkdir -p ~/.config/containers/systemd/

❯ ls .config/containers/systemd
 quadlet1.container   quadlet2.container

❯ cat ~/.config/containers/systemd/quadlet1.container
[Unit]
Description=quadlet1

[Container]
Image=docker.io/library/alpine:latest
Exec=sleep infinity

[Install]
WantedBy=default.target

❯ cat ~/.config/containers/systemd/quadlet2.container
[Unit]
Description=quadlet2

[Container]
Image=docker.io/library/alpine:latest
Exec=sleep infinity

[Install]
WantedBy=default.target

Here, I have created two quadlets (segmentation fault only happens with two or more quadlets). I have defined [Install] with default.target to auto create/start container at boot. This section is important. Segmentation fault does not happen if we remove the [Install] section. I guess bug has something to do with it.
Exec=sleep infinity is added so that container does not stop/exit.

Note- Make sure to reboot the system after creating the quadlets and then wait couple of minutes for it to pull the images. If the github store works, try rebooting again. I have noticed that on rare occasions, github store works even with the above steps. Rebooting again makes it stop (segmentation error).

I am not entirely sure if this is a bug with Github-Store or systemd (podman/systemd services) but it only happens with github-store. All other appimages seems to work fine on my system.

Your setup

Operating System- Bazzite DX (nvidia) with KDE Plasma desktop environment.

❯ rpm-ostree status
State: idle
Deployments:
● ostree-image-signed:docker://ghcr.io/ublue-os/bazzite-dx-nvidia:stable
                   Digest: sha256:a76a5bcf34907b62c30598c6d6799f1948bd2226ffcd689ce085ceeb2bdc162c
                  Version: 43.20260420 (2026-04-30T04:08:25Z)
                Initramfs: regenerate

Anything else

Screenshots-

1. Segmentation fault with github store if two or more podman quadlets are present and run at boot.

2. Podman containers

3. Github store starts working if we stop the podman containers (using systemd user service)

Stopping services-

Note-

1. I was able to reproduce this issue by creating a separate user/account and following same steps. It would be great if someone can try this on their system (either same or different linux distribution- the issue might be with some system library/package instead of github store).
2. I have attached list of all system packages (rpm -qa) installed (see attached file system_packages.log).

system_packages.log

3. The issue does not happen with just one podman quadlet. It only happens with two or more quadlets starting at boot (i.e., with install target). Removing install target section from quadlets makes it work (no more segmentation error).

[rainxchzed]

Thanks for the detailed repro — the podman quadlet correlation is the missing piece from #546. Trace data there showed 94 env vars under your user vs 49 under sudo, and the SEGV lands at libpthread.so.0 load (before libjvm.so even maps), so the poison is at the bundled Temurin JLI level, not GPU / Skiko.

Quadlets autostarting via systemd-user inject extra env into your login session (SYSTEMD_EXEC_PID, NOTIFY_SOCKET, JOURNAL_STREAM, INVOCATION_ID, possibly LD_* from container shims, etc.). One of those is what JLI chokes on. To pin it down:

1. Capture env diff (with quadlets running and again after stopping them):

# With containers running (poisoned state):
env | sort > env-poisoned.log

# After: systemctl --user stop quadlet1.service quadlet2.service
env | sort > env-clean.log

diff env-clean.log env-poisoned.log

Attach both files (redact secrets first).

2. Confirm env-poisoning with minimum-env launch (while quadlets are running):

env -i HOME=$HOME PATH=/usr/bin:/bin DISPLAY=$DISPLAY XDG_RUNTIME_DIR=$XDG_RUNTIME_DIR WAYLAND_DISPLAY=$WAYLAND_DISPLAY DBUS_SESSION_BUS_ADDRESS=$DBUS_SESSION_BUS_ADDRESS ./github_store.appimage

If this launches cleanly, env-poisoning confirmed.

Once we see which var is the culprit, we'll ship a sh wrapper inside the AppImage that unsets it before invoking the JVM launcher. Interim workaround for now: command in step 2 starts GHS even with quadlets active.