You are not logged in.
When I try to reboot the machine there is long delay of 90 seconds before shutdown takes place. If I poweroff remotely the same delays exists. During the delay I see that gnome-shell is still running. If I stop gdm remotely first and then poweroff, the poweroff is instantaneous.
I suspect that gnome-shell is not responding or is waiting. How do you debug gnome-shell?
Last edited by j1mt0 (2020-12-06 20:07:43)
Offline
I've a very similar issue: 120 seconds pause only if I poweroff from a GNOME session.
If I logout, then poweroff from login screen, all is quick as usual.
Last packages I updated, right before having the issue, were:
[2020-12-03T20:02:17+0100] [ALPM] upgraded libldap (2.4.54-1 -> 2.4.56-1)
[2020-12-03T20:02:17+0100] [ALPM] upgraded pipewire (0.3.15-2 -> 0.3.17-1)
[2020-12-03T20:02:18+0100] [ALPM] upgraded llvm-libs (11.0.0-3 -> 11.0.0-4)
[2020-12-03T20:02:18+0100] [ALPM] upgraded sqlite (3.33.0-2 -> 3.34.0-1)
[2020-12-03T20:02:18+0100] [ALPM] upgraded gnutls (3.6.15-1 -> 3.7.0-1)
[2020-12-03T20:02:19+0100] [ALPM] upgraded mutter (3.38.1-1 -> 3.38.2-1)
[2020-12-03T20:02:19+0100] [ALPM] installed gst-plugin-pipewire (0.3.17-1)
[2020-12-03T20:02:19+0100] [ALPM] upgraded gnome-shell (1:3.38.1-1 -> 1:3.38.2-1)
[2020-12-03T20:02:19+0100] [ALPM] upgraded gnome-shell-extensions (3.38.1-1 -> 3.38.2-1)
[2020-12-03T20:02:19+0100] [ALPM] upgraded lib32-libldap (2.4.54-1 -> 2.4.56-1)
[2020-12-03T20:02:20+0100] [ALPM] upgraded lib32-llvm-libs (11.0.0-1 -> 11.0.0-2)
[2020-12-03T20:02:20+0100] [ALPM] upgraded libslirp (4.3.1-1 -> 4.4.0-1)
[2020-12-03T20:02:21+0100] [ALPM] upgraded llvm (11.0.0-3 -> 11.0.0-4)
[2020-12-03T20:02:21+0100] [ALPM] upgraded nano (5.3-1 -> 5.4-1)
[2020-12-03T20:02:21+0100] [ALPM] upgraded ninja (1.10.1-1 -> 1.10.2-1)
[2020-12-03T20:02:22+0100] [ALPM] upgraded python-babel (2.8.1-2 -> 2.9.0-1)
[2020-12-03T20:02:22+0100] [ALPM] upgraded sigil (1.4.2-4 -> 1.4.3-1)
Looking at journactl, failing poweroffs have a pause (2 mins from 9:50:06 to 09:52:05) until a timeout kicks in and kills various processes: pipewire sounds suspect to me.
...
Dec 05 09:50:06 ignaker systemd[1]: systemd-swap.service: Succeeded.
Dec 05 09:50:06 ignaker systemd[1]: Stopped Manage swap spaces on zram, files and partitions..
Dec 05 09:50:06 ignaker audit[1]: SERVICE_STOP pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-swap comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
Dec 05 09:52:05 ignaker systemd[1]: user@1000.service: State 'stop-sigterm' timed out. Killing.
Dec 05 09:52:05 ignaker systemd[1]: user@1000.service: Killing process 776 (systemd) with signal SIGKILL.
Dec 05 09:52:05 ignaker systemd[1]: user@1000.service: Killing process 1227 (pipewire) with signal SIGKILL.
Dec 05 09:52:05 ignaker systemd[1]: user@1000.service: Killing process 1229 (pipewire-media-) with signal SIGKILL.
Dec 05 09:52:05 ignaker systemd[1]: user@1000.service: Killing process 1228 (pipewire) with signal SIGKILL.
Dec 05 09:52:05 ignaker systemd[1]: user@1000.service: Killing process 3156 (dbus-daemon) with signal SIGKILL.
Dec 05 09:52:05 ignaker systemd[1]: user@1000.service: Main process exited, code=killed, status=9/KILL
Dec 05 09:52:05 ignaker systemd[1]: user@1000.service: Failed with result 'timeout'.
Dec 05 09:52:05 ignaker systemd[1]: Stopped User Manager for UID 1000.
I tried to downgrade pipewire and gnome-shell, but without results.
Though, I had some troubles downgrading so I'm not completely sure this step is useless.
Any ideas? Does all this make sense to someone?
Thanks in advance,
Ignazio
Offline
I found this https://gitlab.gnome.org/GNOME/gnome-se … ote_978036
and trying the fix suggested here solves the issue for me
adding
Slice=-.slice
in the [Service] section of/usr/lib/systemd/user/gnome-session-restart-dbus.service fixes the issue.
Offline
Thanks, but I was asking for information on how to debug the problem, not an actual solution. Thanks for saving me the joy of debugging systemd and gnome-shell.
Seems to work. Thanks. But can I mark this as solved? Not in all honesty. It has simply taught me to be lazy, to avoid adding logging, and to expect everything delivered to me onto a plate..
Last edited by j1mt0 (2020-12-06 08:31:08)
Offline
You could've checked what was going on by the time of the delay:
journalctl | grep gnome
You would've found something like this:
dic 04 18:21:46 t480s-arch systemd[677]: Requested transaction contradicts existing jobs: Transaction for exit.target/start is destructive (gnome-session-restart-dbus.service has 'start' job queued, but 'stop' is included in transaction).
Google the error message and the first result is this thread: https://gitlab.gnome.org/GNOME/gnome-se … /issues/74
In this thread you can find which systems are affected, when, why and how to get it solved.
Offline
Thanks for this OP and @ignaker and @gatasi for helpful links.
I'll only add that even better than modifying the file in /usr/lib one can simply add an override.conf (made even easier by using `systemctl --user edit gnome-session-restart-dbus`):
~ $ systemctl --user cat gnome-session-restart-dbus
# /usr/lib/systemd/user/gnome-session-restart-dbus.service
[Unit]
Description=Restart DBus after GNOME Session shutdown
# Allow exit.target to start even if this unit is started with replace-irreversibly
# Also put it into a slice that doesn't have such implicit dependencies
DefaultDependencies=no
[Service]
Type=notify
ExecStart=/usr/lib/gnome-session-ctl --restart-dbus
# /home/ghost/.config/systemd/user/gnome-session-restart-dbus.service.d/override.conf
[Service]
Slice=-.slice
Last edited by CarbonChauvinist (2020-12-13 15:15:41)
"the wind-blown way, wanna win? don't play"
Offline
Thanks, but I was asking for information on how to debug the problem, not an actual solution. Thanks for saving me the joy of debugging systemd and gnome-shell.
I challenge you to get Linux from Scratch then.
I used to think that most people use Arch because they want to have a working system without a hassle. I'm getting some irritating troubles lately with Arch and I started thinking about getting some non-rolling-release distro. I've been using Arch for 9 years now because it "just worked" for me.
Offline
Seems to work. Thanks. But can I mark this as solved? Not in all honesty. It has simply taught me to be lazy, to avoid adding logging, and to expect everything delivered to me onto a plate..
Odd take here, even with the provided answer and beside the fact that ignaker descriptively walked you through how they troubleshooted the issue, you could have done the same digging that gatasi laid out for yourself instead of complaining that someone pointed you to [the,a] solution. The only way to do, is by doing.
Last edited by CarbonChauvinist (2020-12-06 18:08:56)
"the wind-blown way, wanna win? don't play"
Offline
I am sorry. I am not going to say I am sorry that @CarbonChauvinist feels that way because that would be insulting. I am sorry that the irony of what normally happens when people ask a question and then expect an answer immediately or a "fix" when they need to make some kind of decision that require compromise has been lost here.
@mkkot I refuse your challenge. For instancec why would I start off from scratch using glibc that hold on, we have a circular dependency here on the compiler (gcc)? Why would I bother starting to learn from scratch all the "mistakes" that were made because of limitations that existed 30 years ago?
I would just like to thank everyone for their help and for the wonderful arch community.
Offline
I encountered the same problem after having done a bit of debugging and searching online I have landed on this thread. I have noticed that the issue has been solved by the gnome team, so installing the new version of gnome-shell fixes the issue, at least it did for me. The version I have installed is the following:
gnome-shell 3.38.2+22+g3a343a8aa-1
I have figured I'll leave an update here.
Offline
Thanks, but I was asking for information on how to debug the problem, not an actual solution. Thanks for saving me the joy of debugging systemd and gnome-shell.
Seems to work. Thanks. But can I mark this as solved? Not in all honesty. It has simply taught me to be lazy, to avoid adding logging, and to expect everything delivered to me onto a plate..
I found your reply very unfair.
Nobody forced you to open the link and nobody forced you to read the page it linked.
By contrast, ignaker clearly pointed out his answer to be a solution to the problem and not a way to debug it.
Last edited by kokoko3k (2021-01-03 07:38:19)
Help me to improve ssh-rdp !
Retroarch User? Try my koko-aio shader !
Offline