Repository navigation
Let SELKIES_DEBUG show the desktop session's output - #188
junkerderprovinz wants to merge 1 commit into
Conversation
The session scripts sent openbox and labwc output to /dev/null unconditionally, so autostart failures never reached the container log. SELKIES_DEBUG only affected the selkies server's own logging. svc-de/run opens fd 3 while it is still root, pointing at stdout when SELKIES_DEBUG is true and at /dev/null otherwise, and the session commands write to it. abc inherits the descriptor across s6-setuidgid and never opens /dev/stdout itself. The scripts fall back to /dev/null when fd 3 is missing, so running them without svc-de/run behaves as before.
dbb1cdd to
54cc91e
Compare
|
Rebased onto the v2 master. The v2 startwm.sh and startwm_wayland.sh still send openbox and labwc to /dev/null unconditionally, so SELKIES_DEBUG cannot show why the session or an autostart entry failed. The session commands now write to fd 3, which svc-de/run opens as root and points at stdout only when SELKIES_DEBUG is true, so with it off the output is the same as today, selkies-desktop included. The SELKIES_DEBUG check lives only in svc-de/run, abc never opens /dev/stdout itself, and the scripts fall back to /dev/null if fd 3 is missing. The same commit applies cleanly to the other v2 flavor branches if you want it there too. |
|
Yeah I will get to stuff after downstream is settled we rebuild every week so this will land eventually I need to test if shell redirection like this to a 3rd tty has any effect on stuff. |
|
I am kicking this out another week I did not have time to test downstream effects. |
|
180 on this, I don't want to do this. I don't want to change all the downstream littered startwms for desktop sessions, I don't really care about it in my baseimages, seeing this output it is almost never useful for me or when someone is debugging a container remotely, if their app does not start you just ask them to start it from the terminal. I don't want piles of container logs coming back and I don't even want my users running selkies debug mode that is more for developers. If you have the capability to swap env vars and restart containers you should be more than capable of opening a terminal in the session itself. If you are not running the base labwc or openbox session you are already making your own startwm script and you can log how you want, so really this boils down to desktop application logs. We just cleaned up Selkies logs upstream to be less of a spam fest and integrated the stats panel to get useful information from peoples remote setup for the core streaming tech. I still feel the null pipe is the right call and docker logs is not the right place to be debugging desktop applications. |
3 participants
Fixes #176.
Following up on the approach I described in the issue.
svc-de/runopens the destination while it is still root, and both entrypoints inherit that descriptor acrosss6-setuidgid. Soabcnever opens/dev/stdoutitself, which was the blocker on the earlier attempt, and the conditional sits in one place rather than in each session script.Verified the inheritance holds:
while the same user opening
/dev/stdoutdirectly still getsPermission denied.SELKIES_DEBUGalready drives the selkies server's own debug logging, and this extends it to the session output. With it off, behaviour is unchanged.