Bluetoothctl or Pipewire causing a logout/crash #45
Comments
Anyway, I doubt that uwsm has anything to do with the crash. Does crash happen without it? Or when using different terminal emulator or compositor? |
|
The crash only started happening when I switched to using uwsm, didn't have it when I was launching hyprland directly. Terminal emulator shouldn't matter as it happen when I trigger the command via hyprland key binding or eww widget button (mentioning just in case, I also get a crash if I start eww without In regards to a different compositor, I need to set one up to launch via uwsm to test, will try to do that before the end of the week. |
|
What exact bluetoothctl command triggers the crash? |
|
It's Either has a high chance to crash uwsm. Probably |
|
Did a few tests just now |
|
All of these were done with me launching my terminal without Please leave this be for now and I'll do proper testing this weekend and report back the results once I am more sure of myself - right now I am just confused. |
|
You can't crash uwsm, because it isn't running, it just sets things up and makes systemd do useful stuff. See journal around the time of the crash to find out what exactly crashes, deactivates, and brings everything down. Since it is somehow related to silencing output, it might be some content bluetoothctl or related processes produce that affects systemd/journal or Hyprland. Just for fun, try this in shell: |
|
Maybe I should be saying my session crashes, I just called it uwsm as it is not an issue when I run hyprland directly. when running when running Crashing on logs to journal would be ridiculous, I would probably not be able to boot 😄 - I suspect the way bluetoothctl outputs to stdout is wonky. Right now I have this behavior confirmed bot |
|
Which process crashes? Post relevant journal content. |
|
Sorry, I wanted to attach it but got carried away with the emojis. |
|
That log was from triggering |
|
In the next message timing seems right, Why I assume this is the output of What happens when running What happens when running |
for the 23 Oct earlier log here are a few seconds before the start of what I posted initially + a bit of overlap:
The
I have triggered my script from hyprland keybind which essentially just does bluetoothctl unblock + connect on 80:C3:BA:49:FA:92. The session started terminating as soon as I triggered it (meaning it was
I have tried
Not sure what you mean by running |
This means processes are running in login shell, without replacing it. If graphical session ends, login session should stay running. Is it staying? If it is, this means that whatever kills everything, kills only user units, not all user's processes including login shell, otherwise login shell is also affected somehow. Try triggering crash after launching Hyprland from tty in these ways: |
|
playerctl wasn't mentioned in previous logs. Either it is irrelevant, or its messages did not go into journal in other cases. |
I am not being logged out when launching Hyprland via uwsm from TTY. Just the graphical ends and I get thrown back to TTY still logged in.
I think it's irrelevant as it doesn't appear on
stdout stderr
|
|
I was able to reproduce it by launching |
|
I'm sorry, sounds like it's a messy bug 😳 I take it you figured out what actually starts terminating my graphical session? |
|
Yes I did, although for a time I started doubting my sanity (a bit more than usual). So when it is being run in compositor's unit, which has Immediate workaround: do not run |
|
So what happens when I trigger |
|
Output redirection does not matter, starting eww as a unit does. Notification stuff is not default, so other units are not affected. |
|
Anyway, I'm closing this as wontfix. General rule of thumb: it's better to not run stuff inside compositor's unit. Mine is pretty clean: As for bluetoothctl behavior, see bluez/bluez#996 |
|
Thanks, I have subscribed to the bluez issue. Few final questions if you don't mind.
|
TTY or SDDM: See this. |
ArtemSmaznov
added a commit
to ArtemSmaznov/dotfiles-hyprland
that referenced
this issue
Nov 5, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
First of all thanks for the work on #42 just updated to 0.20.1-1 and added a few silencers and already half of my setup's functionality is restored.
Now to the actual issue.
I am running
uwsm start -S -N Hyprland -D Hyprland -C compositor -- Hyprlandfor my session (either from a TTY or SDDM - both have the same issue so not relevant here). I don't really understand what-Sflag actually does, but documentation sounded like the more desired option is to have it in a slice.what I've noticed is that whenever I use
bluetoothctlmy terminal stars behaving like the enter key is stuck pressed and my windows start terminating until I am left with a blank TTY with a few@^@^symbols. I haven't figured out how to make logout return me back to SDDM when I start from it so this might be a similar process here, or it might be a crash of sorts. I would like to focus on thebluetoothctlissue.Now, I don't know if
bluetoothctlis the culprit here, because I primarily use itblock|unblock|connectmy bluetooth headset and pipewire switches my audio sink when this happens. If it'sbluetoothctl, then I suspect it's because of it rapidly outputting few lines to stdout and maybe that is just too frequent for systemd to handle. Or maybe the issue is deeper and switching sinks or something else in this chain is causing uwsm to effectively crash for me. The only reason I would think that, is because I was inspecting journalctl log the other day and it just looked like system just started logging out normally, the apps were stopping and waiting for each other and all that good jazz. And the only thing that stood out was this line.I haven't found anything else relevant to the issue on my own, so if this is not reproducible by the devs, please let me know what info I can provide to identify how I can fix this.
The text was updated successfully, but these errors were encountered: