19

I use Meld very frequently and it just started bailing on me today. When I try to run meld from commandline, it stalls for some time and then exits with Failed to register: Timeout was reached.

I did an apt remove, apt update and re-install and the issue is still there.

Any suggestions on debugging this?

Timothy C. Quinn
  • 1,361

3 Answers3

20

Likely there's a meld process that hung in the background and wouldn't quit. Just kill the meld process with SIGTERM (or SIGKILL if SIGTERM doesn't work). No need to restart the machine.

Rufus
  • 943
  • 7
  • 17
  • Thanks! Restarting my machine is very rarely the correct solution. We're not running Windows here, right?! – Karl Wilbur May 23 '22 at 15:53
  • I understand that problem is related to some dbus resources ?

    Observing problem on KDE

    https://gitlab.gnome.org/GNOME/meld/-/issues/669

     – rzr Aug 04 '22 at 12:38
  • 2
    For the newbies: this post, that answers how to kill a process by name, might help. I used pkill -f "meld" and meld worked again. – C. Binair Sep 14 '22 at 11:22
  • Note: killall meld doesn't work for this because meld is run via Python, so the command name doesn't match. See also: What's the difference between pkill and killall? – Brent Bradburn Oct 09 '23 at 19:06
  • This can happen if your display server crashed. For some reason Meld isn't sensitive enough to its display server socket dying and can stay running after this happens. Especially true when running under Plasma 6 with its kwin composer recovery: after the composer recovers, Meld will not reconnect and will stay running without a window. – Guss Mar 10 '24 at 16:59
7

For those who hit this issue, try restarting your machine. I found a closed ticket on the meld issue tracker and tried it and sure enough, the issue went away.

Timothy C. Quinn
  • 1,361
  • 1
    Awesome! Not a wildly insightful/technical link; but, it makes the answer complete. We need more responsive users, like you, here! – Kevin Bowen Feb 07 '22 at 09:22
  • Link says that a reboot made the issue go away, but doesn't work for me, still exits with timeout was reached error even after reboot. – Hedede Mar 15 '22 at 08:04
  • @Hedede - I would recommend raising a ticket for this then as it seems you may have a different, but related, problem. Issue Tracker: https://gitlab.gnome.org/GNOME/meld – Timothy C. Quinn Mar 15 '22 at 21:26
  • 6
    wondered why for many people a reboot is an acceptable solution... – SergA Apr 04 '22 at 18:21
3

You asked for suggestions on how to debug this. So here's how I debugged this: I ran sudo meld and it worked. I then ran sudo su username for my username and meld worked in that window. Then I ran a env > blah.txt in the working window and env > blah_busted.txt in the broken window. I pulled up meld blah.txt blah_busted.txt to do a diff and began running unset VAR_NAME for each variable name that was defined in the busted.txt but not in the good one. Finally I ran:

unset XDG_RUNTIME_DIR

And meld magically worked again.

I'm running Ubuntu 22.04 via X2GO. I also had to 'unset DBUS_SESSION_BUS_ADDRESS' in ~/.bashrc to get anything snap related to run via x2go. That's a known issue with x2go. It seems ubuntu does no regression testing via x2go, and I can't find any documentation on how/if ubuntu regression tests at all.

poleguy
  • 175
  • Very creative troubleshooting @poleguy! I will give that a try if I see that issue again. – Timothy C. Quinn Feb 13 '23 at 17:38
  • 1
    I had the same problem with gthumb, unsetting the DBUS variable seems to have solved it. Thanks! – Ketil Malde Mar 03 '24 at 18:08
  • 1
    Likewise, I had the same issue with Nicotine+. This is the only answer that resolves this issue for me. This issue persists for me across both reboots and process terminations. Clearly, DBus is no longer playing nicely with DBus-based apps. Clearly, DBus-based apps should be resilient against the contents of fragile shell variables like ${DBUS_SESSION_BUS_ADDRESS}. Clearly, I am out of my depth here. For the moment, I'm content to just unset that variable. Long-term, though, something in the DBus stack really needs to safeguard itself against fragile shell variables. I am sad face. – Cecil Curry Jun 21 '24 at 06:09