Leap 15.1 delayed shutdown, at-spi-dbus-bus.service
Hello: My openSUSE Leap 15.1 system has a 90 seconds delay at shutdown. I use KDE3. It seems that some process is not stopped normally and systemd uses up its default timeout until it steps the next step of the shotdown process. Indeed, journalctl shows: # journalctl -rb -1 ... Apr 04 18:31:52 linux systemd[2014]: at-spi-dbus-bus.service: Killing process 2381 (at-spi-bus-laun) with signal SIGKILL. Apr 04 18:31:52 linux systemd[2014]: at-spi-dbus-bus.service: State 'stop-sigterm' timed out. Killing. Apr 04 18:30:23 linux systemd[1]: Stopped Restore /run/initramfs on shutdown. The above last tow lines shows the 90 seconds delay. ps shows: # ps -ef|grep at-spi 3555 2043 0 18:38 ? 00:00:00 /usr/lib/at-spi2/at-spi-bus-launcher 3560 3555 0 18:38 ? 00:00:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 3562 2043 0 18:38 ? 00:00:00 /usr/lib/at-spi2/at-spi2-registryd --use-gnome-session There is no at-spi-dbus-bus service running but there is a at-spi-bus-launcher. I don't know how they are related. Maybe the delay occurs because there is no process to kill? How cold I fix this? The goal would be to get rid of the 90 seconds shutdown delay. Thanks in advance, Istvan
On 4/4/21 12:10 PM, Istvan Gabor wrote:
ello:
My openSUSE Leap 15.1 system has a 90 seconds delay at shutdown. I use KDE3. It seems that some process is not stopped normally and systemd uses up its default timeout until it steps the next step of the shotdown process.
Indeed, journalctl shows:
# journalctl -rb -1 ... Apr 04 18:31:52 linux systemd[2014]: at-spi-dbus-bus.service: Killing process 2381 (at-spi-bus-laun) with signal SIGKILL.
I have had problems with that too in the past and ended up preventing it from starting. If I recall it is related to accessibility tools like screen readers, etc.. I don't know where it is started currently. In the past it was one of those started through /etc/xdg/autostart You could simply move the desktop file out of the directory to prevent startup on desktop start. It may be a systemd service you can disable now. You will have to check both places. I don't even have whatever provided it installed any longer (and no shutdown delays either...) -- David C. Rankin, J.D.,P.E.
On 4/4/21 9:07 PM, David C. Rankin wrote:
On 4/4/21 12:10 PM, Istvan Gabor wrote:
ello:
My openSUSE Leap 15.1 system has a 90 seconds delay at shutdown. I use KDE3. It seems that some process is not stopped normally and systemd uses up its default timeout until it steps the next step of the shotdown process.
Indeed, journalctl shows:
# journalctl -rb -1 ... Apr 04 18:31:52 linux systemd[2014]: at-spi-dbus-bus.service: Killing process 2381 (at-spi-bus-laun) with signal SIGKILL.
I have had problems with that too in the past and ended up preventing it from starting. If I recall it is related to accessibility tools like screen readers, etc..
I don't know where it is started currently. In the past it was one of those started through
/etc/xdg/autostart
You could simply move the desktop file out of the directory to prevent startup on desktop start. It may be a systemd service you can disable now. You will have to check both places. I don't even have whatever provided it installed any longer (and no shutdown delays either...)
Correction, I do have all the at-spi libs installed (they are needed to build Gtk apps), but I do not have the service running. On the current 15.0 box I have: at-spi2-atk-common-2.26.3-lp150.3.3.1.x86_64 at-spi2-atk-devel-2.26.3-lp150.3.3.1.x86_64 at-spi2-atk-gtk2-2.26.3-lp150.3.3.1.x86_64 at-spi2-core-2.26.3-lp150.4.3.1.x86_64 at-spi2-core-devel-2.26.3-lp150.4.3.1.x86_64 (this is the older saner Gtk+2 set of files, I'll check 15.2 and see what version is installed now) -- David C. Rankin, J.D.,P.E.
On 04.04.2021 20:10, Istvan Gabor wrote:
Hello:
My openSUSE Leap 15.1 system has a 90 seconds delay at shutdown. I use KDE3. It seems that some process is not stopped normally and systemd uses up its default timeout until it steps the next step of the shotdown process.
Indeed, journalctl shows:
# journalctl -rb -1 ... Apr 04 18:31:52 linux systemd[2014]: at-spi-dbus-bus.service: Killing process 2381 (at-spi-bus-laun) with signal SIGKILL. Apr 04 18:31:52 linux systemd[2014]: at-spi-dbus-bus.service: State 'stop-sigterm' timed out. Killing. Apr 04 18:30:23 linux systemd[1]: Stopped Restore /run/initramfs on shutdown.
What exactly do you expect service manager to do? It requested service stop and waits until it completes. It is reasonable to allow service some time to perform all cleanup before assuming it is not responding and hard killing it.
The above last tow lines shows the 90 seconds delay.
ps shows:
# ps -ef|grep at-spi 3555 2043 0 18:38 ? 00:00:00 /usr/lib/at-spi2/at-spi-bus-launcher 3560 3555 0 18:38 ? 00:00:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 3562 2043 0 18:38 ? 00:00:00 /usr/lib/at-spi2/at-spi2-registryd --use-gnome-session
There is no at-spi-dbus-bus service running
How do you know it?
but there is a at-spi-bus-launcher. I don't know how they are related.
Maybe the delay occurs because there is no process to kill?
May be. Only you can answer this as only you have access to your system.
How cold I fix this?
You need to debug it and find out why it happens. I do not observe it here on Leap 15.1 with Xfce desktop. Does it happen on logout (and not on reboot)? Are all processes of your previous session including at-spi correctly stopped in this case?
The goal would be to get rid of the 90 seconds shutdown delay.
Well, the simplest way is to explicitly set TimeoutStopSec=1s for this service.
Thank you all for answering. Mon, 5 Apr 2021 08:42:42 +0300 időpontban Andrei Borzenkov írta:
On 04.04.2021 20:10, Istvan Gabor wrote:
Hello:
My openSUSE Leap 15.1 system has a 90 seconds delay at shutdown. I use KDE3. It seems that some process is not stopped normally and systemd uses up its default timeout until it steps the next step of the shotdown process.
Indeed, journalctl shows:
# journalctl -rb -1 ... Apr 04 18:31:52 linux systemd[2014]: at-spi-dbus-bus.service: Killing process 2381 (at-spi-bus-laun) with signal SIGKILL. Apr 04 18:31:52 linux systemd[2014]: at-spi-dbus-bus.service: State 'stop-sigterm' timed out. Killing. Apr 04 18:30:23 linux systemd[1]: Stopped Restore /run/initramfs on shutdown.
What exactly do you expect service manager to do? It requested service stop and waits until it completes. It is reasonable to allow service some time to perform all cleanup before assuming it is not responding and hard killing it.
The above last tow lines shows the 90 seconds delay.
ps shows:
# ps -ef|grep at-spi 3555 2043 0 18:38 ? 00:00:00 /usr/lib/at-spi2/at-spi-bus-launcher 3560 3555 0 18:38 ? 00:00:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 3562 2043 0 18:38 ? 00:00:00 /usr/lib/at-spi2/at-spi2-registryd --use-gnome-session
There is no at-spi-dbus-bus service running
How do you know it?
If i do: # systemctl status at-spi-dbus-bus.service Unit at-spi-dbus-bus.service could not be found. # systemctl status at-spi-dbus-bus Unit at-spi-dbus-bus.service could not be found. # systemctl | grep -i at-spi-dbus-bus # There is no running service called at-spi-dbus-bus. Or do I misunderstand something?
but there is a at-spi-bus-launcher. I don't know how they are related.
Maybe the delay occurs because there is no process to kill?
May be. Only you can answer this as only you have access to your system.
How cold I fix this?
You need to debug it and find out why it happens. I do not observe it here on Leap 15.1 with Xfce desktop.
How do I debug it? I deleted /etc/xdg/autostart/at-spi-dbus-bus.desktop file but the problem persists.
Does it happen on logout (and not on reboot)? Are all processes of your previous session including at-spi correctly stopped in this case?
I checked it: In vt1 terminal I have these when user is logged in: user 16167 15970 0 23:22 ? 00:00:00 /usr/lib/at-spi2/at-spi-bus-launcher user 16173 16167 0 23:22 ? 00:00:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 user 16175 15970 0 23:22 ? 00:00:00 /usr/lib/at-spi2/at-spi2-registryd --use-gnome-session After logging out from KDE session I have these: user 16167 15970 0 23:22 ? 00:00:00 /usr/lib/at-spi2/at-spi-bus-launcher user 16173 16167 0 23:22 ? 00:00:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 These processes are not killed. Cause of the problem?
The goal would be to get rid of the 90 seconds shutdown delay.
Well, the simplest way is to explicitly set TimeoutStopSec=1s for this service.
I did it as a temporary solution until I find out the real cause. Thanks, Istvan
Wed, 07 Apr 2021 23:35:19 +0200 időpontban Istvan Gabor írta:
Thank you all for answering.
[LONG SNIP]
In vt1 terminal I have these when user is logged in:
user 16167 15970 0 23:22 ? 00:00:00 /usr/lib/at-spi2/at-spi-bus-launcher user 16173 16167 0 23:22 ? 00:00:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 user 16175 15970 0 23:22 ? 00:00:00 /usr/lib/at-spi2/at-spi2-registryd --use-gnome-session
After logging out from KDE session I have these:
user 16167 15970 0 23:22 ? 00:00:00 /usr/lib/at-spi2/at-spi-bus-launcher user 16173 16167 0 23:22 ? 00:00:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
These processes are not killed. Cause of the problem?
If I kill the above processes before shutdown (/sbin/poweroff), shutdown occurs normal, fast. If I don't kill them, the shutdown delay occurs. The question now is why those processes are not killed when I log out from KDE 3 session. Can it be related to graphics driver used? nouveau instead of intel? Thanks, Istvan
On 08.04.2021 00:35, Istvan Gabor wrote:
Thank you all for answering.
Mon, 5 Apr 2021 08:42:42 +0300 időpontban Andrei Borzenkov írta:
On 04.04.2021 20:10, Istvan Gabor wrote:
Hello:
My openSUSE Leap 15.1 system has a 90 seconds delay at shutdown. I use KDE3. It seems that some process is not stopped normally and systemd uses up its default timeout until it steps the next step of the shotdown process.
Indeed, journalctl shows:
# journalctl -rb -1 ... Apr 04 18:31:52 linux systemd[2014]: at-spi-dbus-bus.service: Killing process 2381 (at-spi-bus-laun) with signal SIGKILL. Apr 04 18:31:52 linux systemd[2014]: at-spi-dbus-bus.service: State 'stop-sigterm' timed out. Killing. Apr 04 18:30:23 linux systemd[1]: Stopped Restore /run/initramfs on shutdown.
What exactly do you expect service manager to do? It requested service stop and waits until it completes. It is reasonable to allow service some time to perform all cleanup before assuming it is not responding and hard killing it.
The above last tow lines shows the 90 seconds delay.
ps shows:
# ps -ef|grep at-spi 3555 2043 0 18:38 ? 00:00:00 /usr/lib/at-spi2/at-spi-bus-launcher 3560 3555 0 18:38 ? 00:00:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 3562 2043 0 18:38 ? 00:00:00 /usr/lib/at-spi2/at-spi2-registryd --use-gnome-session
There is no at-spi-dbus-bus service running
How do you know it?
If i do:
# systemctl status at-spi-dbus-bus.service Unit at-spi-dbus-bus.service could not be found.
It is user, not system service.
# systemctl status at-spi-dbus-bus Unit at-spi-dbus-bus.service could not be found.
# systemctl | grep -i at-spi-dbus-bus #
There is no running service called at-spi-dbus-bus. Or do I misunderstand something?
You need to check user services. systemctl --user ...
but there is a at-spi-bus-launcher. I don't know how they are related.
Maybe the delay occurs because there is no process to kill?
May be. Only you can answer this as only you have access to your system.
How cold I fix this?
You need to debug it and find out why it happens. I do not observe it here on Leap 15.1 with Xfce desktop.
How do I debug it? I deleted /etc/xdg/autostart/at-spi-dbus-bus.desktop file but the problem persists.
Here it is started on access to D-Bus service, you can check logs what triggers it in your case.
Does it happen on logout (and not on reboot)? Are all processes of your previous session including at-spi correctly stopped in this case?
I checked it:
In vt1 terminal I have these when user is logged in:
user 16167 15970 0 23:22 ? 00:00:00 /usr/lib/at-spi2/at-spi-bus-launcher user 16173 16167 0 23:22 ? 00:00:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3 user 16175 15970 0 23:22 ? 00:00:00 /usr/lib/at-spi2/at-spi2-registryd --use-gnome-session
After logging out from KDE session I have these:
user 16167 15970 0 23:22 ? 00:00:00 /usr/lib/at-spi2/at-spi-bus-launcher user 16173 16167 0 23:22 ? 00:00:00 /usr/bin/dbus-daemon --config-file=/usr/share/defaults/at-spi2/accessibility.conf --nofork --print-address 3
These processes are not killed. Cause of the problem?
Yes.
The goal would be to get rid of the 90 seconds shutdown delay.
Well, the simplest way is to explicitly set TimeoutStopSec=1s for this service.
I did it as a temporary solution until I find out the real cause.
Thanks,
Istvan
On 4/7/21 11:50 PM, Andrei Borzenkov wrote:
There is no running service called at-spi-dbus-bus. Or do I misunderstand something?
You need to check user services. systemctl --user ...
IMHO user service files should not be used. They are damn near impossible to interact with in some cases and end up creating frustration while solving nothing. 99% of openSUSE users are single user installs. Segregating system and user services just needlessly complicates matters for those type installs. If the devs have a design "choice" whether to implement via a system server or a user server -- go with the system service... -- David C. Rankin, J.D.,P.E.
On Thu, 8 Apr 2021 00:54:52 -0500
"David C. Rankin"
99% of openSUSE users are single user installs
I proudly claim to be the 1% then ... (and I suspect there are a lot more like me that use different accounts for different purposes. I don't log in to my wife's and my share/stock accounts using a browser under the same user account, for example)
On 2021-04-08 09:46:29 Dave Howorth wrote:
|On Thu, 8 Apr 2021 00:54:52 -0500 | |"David C. Rankin"
wrote: |> 99% of openSUSE users are single user installs | |I proudly claim to be the 1% then ... | |(and I suspect there are a lot more like me that use different accounts |for different purposes. I don't log in to my wife's and my share/stock |accounts using a browser under the same user account, for example)
Aye, there are a few of us out here. Leslie -- openSUSE Leap 15.2 x86_64
On 4/8/21 9:46 AM, Dave Howorth wrote:
On Thu, 8 Apr 2021 00:54:52 -0500 "David C. Rankin"
wrote: 99% of openSUSE users are single user installs
I proudly claim to be the 1% then ...
(and I suspect there are a lot more like me that use different accounts for different purposes. I don't log in to my wife's and my share/stock accounts using a browser under the same user account, for example)
I too have server installs, and I cuss the user services there too :) I can see there use, different users same machine in a shift-work environment, etc... But you literally have to use the command line equivalent of hopping on one foot, tugging on your left-ear while whistling Dixie to successfully, change, remove, or otherwise adjust user services.... -- David C. Rankin, J.D.,P.E.
On 2021-04-04 1:10 p.m., Istvan Gabor wrote:
The goal would be to get rid of the 90 seconds shutdown delay.
I can think of two obvious ways. The first is to (as I often do (regardless of the GUI) to CLI shutdown --poweroff now Note: see also SYSTEMD-HALT.SERVICE(8) which notes Immediately before executing the actual system halt/poweroff/reboot/kexec systemd-shutdown will run all executables in /usr/lib/systemd/system-shutdown/ and pass one arguments to them: either "halt", "poweroff", "reboot" or "kexec", depending on the chosen action. All executables in this directory are executed in parallel, and execution of the action is not continued before all executables finished. Note that systemd-halt.service (and the related units) should never be executed directly. Instead, trigger system shutdown with a command such as "systemctl halt" or suchlike. of course # file /sbin/shutdown /sbin/shutdown: symbolic link to /usr/bin/systemctl See SYSTEMCTL(1) under poweroff, halt or reboot -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg
On 4/5/21 8:24 PM, Anton Aylward wrote:
On 2021-04-04 1:10 p.m., Istvan Gabor wrote:
The goal would be to get rid of the 90 seconds shutdown delay.
I can think of two obvious ways.
The first is to (as I often do (regardless of the GUI) to CLI shutdown --poweroff now
Note: see also SYSTEMD-HALT.SERVICE(8) which notes Immediately before executing the actual system halt/poweroff/reboot/kexec systemd-shutdown will run all executables in /usr/lib/systemd/system-shutdown/ and pass one arguments to them: either "halt", "poweroff", "reboot" or "kexec", depending on the chosen action. All executables in this directory are executed in parallel, and execution of the action is not continued before all executables finished. Note that systemd-halt.service (and the related units) should never be executed directly. Instead, trigger system shutdown with a command such as "systemctl halt" or suchlike.
of course # file /sbin/shutdown /sbin/shutdown: symbolic link to /usr/bin/systemctl
See SYSTEMCTL(1) under poweroff, halt or reboot
Adding KillUserProcesses=yes to /etc/systemd/logind.conf might be another way but this also kills background processes such as screen etc unless you do specific handling. I beleive problems like yours are exactly what it tried to solve though -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
On 09.04.2021 07:51, Simon Lees wrote:
On 2021-04-04 1:10 p.m., Istvan Gabor wrote:
The goal would be to get rid of the 90 seconds shutdown delay.
...
Adding KillUserProcesses=yes to /etc/systemd/logind.conf might be another way but this also kills background processes such as screen etc unless you do specific handling. I beleive problems like yours are exactly what it tried to solve though
This applies to processes that are part of user session while at-spi-bus.service is user service that conceptually exists outside of any user session.
participants (7)
-
Andrei Borzenkov
-
Anton Aylward
-
Dave Howorth
-
David C. Rankin
-
Istvan Gabor
-
J Leslie Turriff
-
Simon Lees