Eruption don't detect device after Ubuntu sleep #62
Assignees
Labels
Milestone
Comments
|
Hi @poldolot, thank you for reporting this issue! I will build fixed packages soon... |
|
@poldolot I just published new packages ( I could not easily reproduce the problem in a Ubuntu virtual machine. Will have to set up Ubuntu on bare-metal if the problem persists. |
|
Hi, unfortunately version 0.1.22 didn't fixed the issue and now even replugging isn't working, only service restart helps. New log: I'm adding log after service restart: |
|
@poldolot Sorry, for not getting back to you earlier. For hotplug and suspend/resume to work, the system needs to be in a state were the following command is able to run successfully: $ sudo eruption-hotplug-helper hotplugCould you please try to run the following commands: $ sudo systemctl unmask eruption.service
$ sudo systemctl enable --now eruption.service
$ sudo systemctl unmask eruption-hotplug-helper.service
$ sudo systemctl enable --now eruption-hotplug-helper.serviceAnd the please run: $ sudo eruption-hotplug-helper hotplugIf eruption restarts successfully then suspend/resume has a great chance of working. To debug the code that gets run during a suspend/resume cycle you could run these commands: To simulate a suspend: $ sudo /lib/systemd/system-sleep/eruption preAnd to simulate a resume afterwards: $ sudo /lib/systemd/system-sleep/eruptionThis should restart the Eruption daemon. |
|
Ok, thx for the reply. |
|
@X3n0m0rph59 no worries! |
|
Hi @poldolot! I just published a new snapshot release. Please find it here. Could you please verify that it fixes the issue for you? |
|
Hi @X3n0m0rph59! and the message from hotplug: |
|
@poldolot, thanks for the quick reply! It seems like the
This normally only happens due to the system exhibiting some hanging or failed Systemd units. Could you please post the output of this command: sudo systemctl list-units --failedI believe that as soon as the failed units are fixed, there is a great chance for suspend/resume to now work correctly! |
|
@X3n0m0rph59, here is an output for failed services: and You'r right, after and corresponding systemlog: |
|
@poldolot, this looks strange to me. Not completely sure what is going on...
Could you please try to run: sudo systemctl stop eruption.service
sudo systemctl daemon-reload
systemctl --user daemon-reload
sudo systemctl restart eruption.serviceAnd then please test again whether device hotplug is working now. |
|
@X3n0m0rph59, no change. |
|
@poldolot, maybe the Eruption daemon is racing against system wakeup and hardware initialization. It seems to me that the USB device is not ready yet, when Eruption tries to enumerate and subsequently bind to it. Could you please temporarily add the line #!/bin/sh
if [ "$1" = "pre" ] ; then
# prepare Eruption for system sleep
touch /run/lock/eruption-hotplug-helper.lock
systemctl stop eruption-hotplug-helper.service
systemctl stop eruption.service
touch /run/lock/eruption-sleep.lock
else
sleep 3
# wake up Eruption after system sleep
rm /run/lock/eruption-hotplug-helper.lock
systemctl start eruption-hotplug-helper.service
rm /run/lock/eruption-sleep.lock
fiand then please try again if it works now. Thanks for your patience! |
|
@X3n0m0rph59, I've tested every scenario I could think off, and it works in most of them but when the system is waked up without keyboard connected it doesn't work. The error is the same as above. |
|
@poldolot, thanks for testing this so thoroughly! Do you use some kind of KVM switch, so that the keyboard could be disconnected during resume? So hotplug after resume should work when we do something like this: #!/bin/sh
if [ "$1" = "pre" ] ; then
# prepare Eruption for system sleep
touch /run/lock/eruption-hotplug-helper.lock
systemctl stop eruption-hotplug-helper.service
systemctl stop eruption.service
touch /run/lock/eruption-sleep.lock
else
sleep 3
# wake up Eruption after system sleep
rm /run/lock/eruption-hotplug-helper.lock
systemctl start eruption-hotplug-helper.service
rm /run/lock/eruption-sleep.lock
sleep 3
systemctl reset-failed
fiThis line should cause the system to be in a state where the systemctl reset-failedTo test whether this theory could be correct, could you please resume from suspend with the keyboard disconnected and then hotplug the device. Please be sure to wait for at least 10 seconds after the resume operation completed, before hotplugging the device, so that everything has settled. |
|
@X3n0m0rph59, yes, it helps! |
|
@poldolot, okay great! I will think about this some more and then try to come up with a robust solution to this issue. Regarding the log messages: This problem should be corrected by enabling the user session daemons (the audio-proxy) that ship with eruption: systemctl --user enable --now eruption-audio-proxy.service eruption-process-monitor.service
And please be sure to install the latest version of the package/update your system. |
|
@X3n0m0rph59, I've installed newest version but this command gave me an error: |
|
@poldolot Did you try without systemctl --user daemon-reload
systemctl --user enable --now eruption-audio-proxy.serviceIf it still wont work could you please locate the file |
|
@X3n0m0rph59, yes I've run it without maybe I need to uninstall eruption and install it from scratch? |
|
@poldolot I have published a new |
|
@poldolot Yes please backup your profiles and then purge and reinstall sudo apt purge eruption-git
sudo apt update
sudo apt install eruption-git |
|
@X3n0m0rph59, I've purged and install newest version but still no success without keyboard connected and eruption files are still in /lib/... and not /usr/lib/... |
|
I had a similar problem on my Manjaro Box with kernel 5.16. Just for your information. Perhaps it helps to solve the issue. |
|
I have pushed a number of fixes to the |
|
@X3n0m0rph59 that's great news! I'll wait for stable version. Thank You for Your insane work :-) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, I have a bug after waking Ubuntu 20.04 from sleep and connecting keyboard. It started after updating to v0.1.20
Corresponding log:
I don't know if it's related but during normal use I have a lot of this in my log:
After
systemctl restart eruption.serviceeverything is back to normal.The text was updated successfully, but these errors were encountered: