[BUG] session freaks out xorg dwm app package (low priority)

[iceyrazor]

Code of conduct

• I have read and agree to adhere to the Code of Conduct

Self-training on how to write a bug report

• I have learned how to write a bug report

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

fix below low priority

when i start session on my setup. it works fine. however when i start it through terminal and & disown it and close the terminal. it freezes my whole setup and spawns a ton of empty windows.

this cant just be a electron thing as i use discord and it works fine.

this stops if i instead do session-deskop-linux-x86_64-1.12.3.AppImage > /dev/null & disown or any file

Expected Behavior

for the session app image to be able to be opened and disowed and the terminal closing without infinate windows spawning and my pc freezing.

Steps To Reproduce

use dwm and its requirements along with xorg.
use the app package.
run session-deskop-linux-x86_64-1.12.3.AppImage & disown

Desktop Version

v1.12.3

Anything else?

Linux 6.9.1-arch1-2

if this allready was an issue i couldnt find it

bug.mov

[AL-Session]

I've been able to replicate a functionally similar issue on the latest Arch (kernel 6.9.7-Arch-1, bash 5.2.026-2) but using gdm on X11 rather than dwm. If I launch session from a terminal via ./session-desktop-linux-x86_64-1.12.4.AppImage & disown and then close the terminal the window manager locks up and I'm forced to reboot.

However, if I launch via the following:
nohup ./session-desktop-linux-x86_64-1.12.4.AppImage &
then I'm able to close the terminal and session-desktop remains active and responsive, and there are no window manager issues.

Could you give that a try and see how you get on?

As this is more of a workaround than a fix (assuming that it works for you!), do you know if the disown method worked previously but has recently stopped working perhaps?

[iceyrazor]

I've been able to replicate a functionally similar issue on the latest Arch (kernel 6.9.7-Arch-1, bash 5.2.026-2) but using gdm on X11 rather than dwm. If I launch session from a terminal via ./session-desktop-linux-x86_64-1.12.4.AppImage & disown and then close the terminal the window manager locks up and I'm forced to reboot.

However, if I launch via the following: nohup ./session-desktop-linux-x86_64-1.12.4.AppImage & then I'm able to close the terminal and session-desktop remains active and responsive, and there are no window manager issues.

Could you give that a try and see how you get on?

As this is more of a workaround than a fix (assuming that it works for you!), do you know if the disown method worked previously but has recently stopped working perhaps?

i only just started using session on linux so i dont think so.

no the workaround you listed nohup ./session-desktop-linux-x86_64-1.12.4.AppImage & still closes session when i close the terminal that started it,

the workaround session-deskop-linux-x86_64-1.12.3.AppImage > /dev/null & disown works fine for me.

[Bilb]

Hey @iceyrazor
this could be an AppImage issue rather than a session issue, as seen here
https://stackoverflow.com/questions/66573324/unable-to-properly-disown-appimage

Can you try what that guy suggests and let me know if that also fixes your issue?
i.e.
setsid -f <session AppImage path>

Just trying to know what works so we can maybe find a proper fix.

[iceyrazor]

Hey @iceyrazor this could be an AppImage issue rather than a session issue, as seen here https://stackoverflow.com/questions/66573324/unable-to-properly-disown-appimage

Can you try what that guy suggests and let me know if that also fixes your issue? i.e. setsid -f <session AppImage path>

Just trying to know what works so we can maybe find a proper fix.

no such command setsid.

[AL-Session]

no such command setsid.

You'll need to install util-linux:

pacman -Qo setsid
/usr/bin/setsid is owned by util-linux 2.40.1-1

[iceyrazor]

no such command setsid.

You'll need to install util-linux:

pacman -Qo setsid
/usr/bin/setsid is owned by util-linux 2.40.1-1

fin i was running a mc server >:( lol.

no it still did the same thing that happened in the video. this app image is 1.12.4.

i was able to kill it off in a seperate tty. dwm crashed though. and lightdm kicked in and restarted it.

[AL-Session]

@iceyrazor Okay, I've had a chance to take a further look at things. It looks like session-android is taking stdout for logging when launched via terminal and having a bad time of things when the terminal closes and stdout is no longer available. So this will be why session-deskop-<version> > /dev/null & disown works - because stdout is now /dev/null and it doesn't get torn down.

I'm surprised that nohup ./session-desktop-<version> & doesn't work for you, as it seems like it should be the correct mechanism to use (and it works on my gdm setup) so this might be specifically related to how dwm handles things.

You mentioned that Discord behaves okay when you & disown it - and I can confirm... that is, until you then go to close Discord and it throws up continual JS error windows and you have to kill -9 the process (but at least it doesn't lock the wm!). Or at least that's what I've observed on X11 & gdm.

For the sake of completeness I also built a native version of session-desktop from the AUR to see if the issue might have been related to the use of the AppImage build, but unfortunately the same window manager issue was observed.

Perhaps the best we can do for now is use the workaround you found and log to /dev/null when you're not interested in the logs, but log to a specific file should you want to keep the session logs for any reason.

@Bilb Is there somewhere public-facing that we could make note of this information, like perhaps in a Troubleshooting section of the README.md? For example maybe something like:

###Troubleshooting

####Linux
Running session-desktop from a terminal and then closing that terminal has been observed to cause window-manager issues. If you want to run session-desktop from a terminal which is subsequently closed, you can launch it as:
`nohup session-desktop-<version> &`

Or should that not work (as has been observed on the _dwm_ window manager) you can use:
`session-desktop-<version> > /dev/null & disown`

Please note that in the latter case app logging will not be available, but should you require the app logs for any reason then you can substitute a file to log to rather than `/dev/null`.

[iceyrazor]

@AL-Session sounds good. idk if i should leave this open though.

[Bilb]

This looks to me like an AppImage issue and not a session-desktop issue (see the link sent above and here https://stackoverflow.com/questions/66573324/unable-to-properly-disown-appimage)
So I guess we can close this.