Xorg hangs use 99% of CPU on systemd reboot

Hans de Goede hdegoede at redhat.com
Thu Jul 23 01:37:29 PDT 2015


Hi,

On Thu, Jul 02, 2015 at 04:26:19PM +0100, Barry Scott wrote:

> The attached patch works around an issue we hit after we
> ported from Fedora 20 to Fedora 21.
>
> When systemd reboot starts something happens to dbus that
> causes Xorg to loop hard using 99% CPU in WaitForSomething.
>
> The reason for the loop is that the bus_info.fd in dbus-core.c
> has been closed. But the expected Disconnected signal is not
> received by the messages filter.
> The patch works around this issue by removing the fd from the
> fd_set that is feed into the Select in WaitForSomething by
> calling RemoveGeneralSocket from within wakeup_handler in
> dbus-core.c.
>
> When systemctl is used to stop and restart Xorg outside of the
> reboot it works without any problems.
>
> Barry
>
>

Ok, so basically the problem is that the socket simply gets closed
without the dbus-daemon sending a Disconnect signal, correct?

Detecting this in the wakeup handler seems like a good solution
for this.

I do wonder why you're not calling teardown() in this case though?

Is this because calling RemoveBlockAndWakeupHandlers from a wakeuphandler
is a bad idea ?

In that case would it not be better to move the RegisterBlockAndWakeupHandlers()
call to dbus_core_init() and the RemoveBlockAndWakeupHandlers() call to
dbus_core_fini() and still use teardown() ?

The way you're dealing with this now means that if the dbus-daemon dies
unexpectedly (eg kill -9 it, which should reproduce your problem case)
that then the disconnect hooks will not be run. Also we should probably
set the timer to try to reconnect when this happens, as it can happen
in the middle of a X session to, rather then on system reboot when the
dbus-daemon unexpectedly shutsdown.

I think that what should be done is add a new disconnected() helper
which contains the disconnect code from the filter, and call that when
disconnect is detected from the wakeup handler too.

Regards,

Hans



> From ca770dd6e8ebb9a780ce68a07535f976f6120247 Mon Sep 17 00:00:00 2001
> From: Barry Scott <barry.scott at onelan.co.uk>
> Date: Tue, 30 Jun 2015 15:58:22 +0100
> Subject: [PATCH] server loops in WaitForSomething when dbus closed by
> systemd>
>  shutdown
>
> Work around issue with dbus fd becoming closed by WaitForSomething
> still using it in Select. The Select return EBADF but becuase the dbus fd
> is not taken out of the fs_set the code loop forever.
>
> This state has been seen when systemd starts to shutdown on Fedora 21.
>
> Signed-off-by: Barry Scott <barry.scott at onelan.co.uk>
> ---
>
>  config/dbus-core.c | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
>
> diff --git a/config/dbus-core.c b/config/dbus-core.c
> index 8351ea4..fac8116 100644
> --- a/config/dbus-core.c
> +++ b/config/dbus-core.c
> @@ -52,6 +52,19 @@ wakeup_handler(void *data, int num_fds, void
> *read_mask)
>
>  {
>
>      struct dbus_core_info *info = data;
>
> +    if (info->fd < 0) {
> +        return;
> +    }
> +
> +    if (!dbus_connection_get_is_connected(info->connection)) {
> +        /* must remove the FD here as WaitForSomething's Select will now  fail
> +           and WaitForSomething will loop hard calling Select.
> +           The "Disconnected" message has been seen to not arrive. */
> +        RemoveGeneralSocket(info->fd);
> +        info->fd = -1;
> +        return;
> +    }
> +
>
>      if (info->connection && num_fds > 0 && FD_ISSET(info->fd, (fd_set *)
>      read_mask)) {>
>          do {
>
>              dbus_connection_read_write_dispatch(info->connection, 0);
>
> _______________________________________________
> xorg-devel at lists.x.org: X.Org development
> Archives: http://lists.x.org/archives/xorg-devel
> Info: http://lists.x.org/mailman/listinfo/xorg-devel


-------------- next part --------------
_______________________________________________
xorg-devel at lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel


More information about the xorg-devel mailing list