Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash on stale dbus file #400

Open
mokraemer opened this issue Oct 2, 2024 · 6 comments · May be fixed by #401
Open

Crash on stale dbus file #400

mokraemer opened this issue Oct 2, 2024 · 6 comments · May be fixed by #401

Comments

@mokraemer
Copy link

mokraemer commented Oct 2, 2024

Expected behaviour

starting mate-power-manager should start up

Actual behaviour

it crashes with the error
(mate-power-manager:245007): PowerManager-ERROR **: 11:10:26.798: Error in dbus - GDBus.Error:System.Error.ESTALE: Stale file handle

Steps to reproduce the behaviour

Backtrace:


#0  g_log_structured_array (log_level=<optimized out>, fields=0x7fffffffd430, n_fields=4) at ../glib/gmessages.c:555
        __func__ = "g_log_structured_array"
#1  0x00007ffff700d66e in g_log_default_handler
    (log_domain=log_domain@entry=0x41e974 "PowerManager", log_level=log_level@entry=6, message=message@entry=0x7fffe0002c40 "Error in dbus - GDBus.Error:System.Error.ESTALE: Stale file handle", unused_data=unused_data@entry=0x0)
    at ../glib/gmessages.c:3284

                    fields = {{key = 0x7ffff706952f "GLIB_OLD_LOG_API", value = 0x7ffff70671ac, length = -1}, {key = 0x7ffff7069445 "MESSAGE", value = 0x7fffe0002c40, length = -1}, {key = 0x7ffff7069458 "PRIORITY", value = 0x7ffff70627da, length = -1}, {key = 0x7ffff70694b2 "GLIB_DOMAIN", value = 0x41e974, length = -1}}
        n_fields = <optimized out>
#2  0x00007ffff700d8a8 in g_logv (log_domain=0x41e974 "PowerManager", log_level=G_LOG_LEVEL_ERROR, format=<optimized out>, args=<optimized out>) at ../glib/gmessages.c:1391
        domain = 0x0
        data = 0x0
        depth = <optimized out>
        log_func = 0x7ffff700d5c0 <g_log_default_handler>
        domain_fatal_mask = <optimized out>
        masquerade_fatal = 0
        test_level = 6
        msg_alloc = 0x7fffe0002c40 "Error in dbus - GDBus.Error:System.Error.ESTALE: Stale file handle"
        msg = 0x7fffe0002c40 "Error in dbus - GDBus.Error:System.Error.ESTALE: Stale file handle"
        i = 2
#3  0x00007ffff700db52 in g_log (log_domain=log_domain@entry=0x41e974 "PowerManager", log_level=log_level@entry=G_LOG_LEVEL_ERROR, format=format@entry=0x41e025 "Error in dbus - %s") at ../glib/gmessages.c:1460
        args = {{gp_offset = 32, fp_offset = 48, overflow_arg_area = 0x7fffffffd650, reg_save_area = 0x7fffffffd590}}
#4  0x000000000040f908 in gpm_manager_systemd_inhibit (proxy=<optimized out>) at gpm-manager.c:1774
        fd = -1
        fd_list = 0x0
        arg_who = 0x644490 "marc"
        arg_why = 0x41f7d0 "Mate power manager handles these events"
        arg_mode = 0x41ee7c "block"
        error = 0x7fffe00025a0
        r = -1
        res = 0x0
        arg_what = 0x41f7f8 "handle-power-key:handle-suspend-key:handle-lid-switch"
        check_type_cpu = <optimized out>
        connection = 0x5244e8
        error = 0x0
#5  gpm_manager_init (manager=0x644460 [GpmManager]) at gpm-manager.c:1829
        check_type_cpu = <optimized out>
        connection = 0x5244e8
        error = 0x0
#6  0x00007ffff71255f8 in g_type_create_instance (type=0x711e80 [GpmManager]) at ../gobject/gtype.c:1983
        node = 0x711e80
        instance = 0x644460 [GpmManager]
        class = 0x711e80 [g_type: GpmManager]
        allocated = <optimized out>
        private_size = <optimized out>
        ivar_size = <optimized out>
        i = <optimized out>
#7  0x00007ffff7109b50 in g_object_new_internal (class=class@entry=0x644310, params=params@entry=0x0, n_params=n_params@entry=0) at ../gobject/gobject.c:2246
        nqueue = 0x0
        object = <optimized out>
        i = <optimized out>
        __func__ = "g_object_new_internal"
#8  0x00007ffff710b0fc in g_object_new_with_properties (object_type=0x711e80 [GpmManager], n_properties=<optimized out>, names=names@entry=0x0, values=values@entry=0x0) at ../gobject/gobject.c:2409
        class = 0x644310
        unref_class = 0x644310
        object = <optimized out>

MATE general version

1.26.1

Package version

1.26.1

Linux Distribution

mageia

Link to bugreport of your Distribution (requirement)

https://bugs.mageia.org/show_bug.cgi?id=33550

@cwendling cwendling linked a pull request Oct 2, 2024 that will close this issue
@cwendling
Copy link
Member

I have submitted a fix for MPM not to error-out in this case (see #401) BUT this error is not normal. You likely have something very wrong in your system, although it might just be leftover stuff that confuses it or such, or some NFS failures -- not that I ever saw this error though.

@mokraemer
Copy link
Author

At the moment it looks like the crash occures after the last systemd update. But I don't see this has anything to do with gdbus, which states the error...

@cwendling
Copy link
Member

Yeah I don't think it does either. What we can do in MSM is avoid aborting in this situation given it doesn't seem to be a hard-blocker for all features, which is what I did in #401. However, that doesn't necessarily guarantee everything's gonna work as it should given this is likely to hide a deeper issue in the dbus/logind on your system(s)

@mokraemer
Copy link
Author

You're right. But the error I get from dbus (stale file) does not help me much. I don't see which file is stale at least.

@mokraemer
Copy link
Author

On my tests, systemd-253 patch level >16 breaks mate-power-manager.
The package is almost vanilla. In version 253.16 it works, the next release (in my distro) .24 breaks it and .25 (which I compiled for a test) did not make it work again.

@mokraemer
Copy link
Author

at least this bug is due to an systemd patch:
systemd bug
systemd-patch

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants