[BUG] startwm.sh silences all openbox-session output, hiding autostart logs

[junkerderprovinz]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

/defaults/startwm.sh ends with exec dbus-launch --exit-with-session /usr/bin/openbox-session > /dev/null 2>&1. That redirect discards everything the openbox session and its children write, so nothing from /defaults/autostart (app launchers, ready banners, healers) reaches docker logs. Diagnosing a desktop that starts but misbehaves becomes a blackout, and a CI smoke gate that greps the container log for an autostart line fails even when the app started fine.

Expected Behavior

The openbox-session output should reach the container log (as it did on the KasmVNC base), or the silencing should be opt-in via an env var.

Steps To Reproduce

1. Build an image FROM this base and print a marker from /defaults/autostart, e.g. echo "APP READY".
2. Start the container and run docker logs <name>.
3. The marker is absent, even though the desktop and app are running.

Environment

• OS: Unraid / any Docker host
• Base: ghcr.io/linuxserver/baseimage-selkies (current), X11 mode (Xvfb + openbox)

Docker creation

docker run -d --name selkies-test -p 3001:3001 --shm-size=1g ghcr.io/linuxserver/baseimage-selkies:ubunturesolute

Container logs

The svc-de output stops before any openbox-session or autostart line; the session stdout/stderr never appear because of the > /dev/null 2>&1 on the final exec.

I can open a PR shipping a startwm.sh without the redirect (or gating it behind an env var) if that is welcome.

[thelamer]

This was discussed in PR #180, leaving open in case we land on some kind of good solution that does not duplicate too much code in the default startwms. In general desktop output is very noisy it is only ever useful for debugging and should not be enabled by a normal user.