Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#60229 - [thunar] Fails to start with "Failed to register: Timeout was reached"

Attached to Project: Arch Linux
Opened by David P. Kaylor (dkaylor) - Friday, 28 September 2018, 10:14 GMT
Last edited by Doug Newgard (Scimmia) - Thursday, 04 October 2018, 16:11 GMT
Task Type Bug Report
Category Packages: Extra
Status Assigned
Assigned To Tobias Powalowski (tpowa)
Evangelos Foutras (foutrelis)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 12
Private No

Details

Description:

Thunar fails to start, only message is "Failed to register: Timeout was reached"


Additional info:

package version 1.8.2-1
downgrading to 1.8.1.11.gf5147445-1 does not help
nothing in systemd journal

Steps to reproduce:

run /usr/bin/thunar from terminal
This task depends upon

Comment by David P. Kaylor (dkaylor) - Friday, 28 September 2018, 10:26 GMT
Major correction: downgrading to 1.8.1.11.gf5147445-1 does fix issue. Needed to restart xfce4 session first.
Comment by David P. Kaylor (dkaylor) - Friday, 28 September 2018, 13:29 GMT
After downgrade, thunar opened normally. Upgraded back to 1.8.2-1 and it continued to work. Did reboot, still continued to work. No other packages were upgraded in the interim. Leaving open for now in case anyone else encounters.
Comment by Rick (Riyyi) - Saturday, 29 September 2018, 13:53 GMT
I have the same issue and can confirm that downgrading to '1.8.1.11.gf5147445-1' does fix it.
But updating back to 1.8.2-1 and rebooting breaks it again.
Comment by David P. Kaylor (dkaylor) - Saturday, 29 September 2018, 14:51 GMT
Interesting. Found a lot of references to other applications (gedit, gnome-control-center, baobab and others) in the past that showed the same message. But nothing for thunar, and nothing in the Arch Forums.
Looks like applications fail to start and get stuck in an unterminated state.

Not sure why a reboot doesn't clear that state.
Comment by Luigi Coniglio (werew) - Sunday, 30 September 2018, 13:28 GMT
Same issue here, downgrading to 1.8.1.11.gf5147445-1 fixed it.
Comment by Brent Groves (bgroves) - Friday, 05 October 2018, 22:22 GMT
If I run sudo /usr/bin/thunar
I get the error message:
Thunar: Failed to initialize Xfconfig: Server address of type unix was missing argument path ...
But it runs.
If I run without sudo nothing seems to happen.
Comment by Dave Jones (esuhl) - Saturday, 06 October 2018, 19:04 GMT
I also get the error "Failed to register: Timeout was reached" when starting thunar as a user. But it does start as root (and also using sudo).

This is on a virtual machine on a Win7 host. My native PC installation of Arch doesn't have this issue. Not sure if that's relevant.
Comment by Valerio (interferon) - Sunday, 07 October 2018, 07:44 GMT
I confirm the issue with Thunar 1.8.2
Comment by Strephil (strephil) - Sunday, 07 October 2018, 07:47 GMT
I get this error when I run thunar as one user but it works well when I run it as another.
Downgrading didn't help me.
Comment by James (ronnie_p) - Monday, 08 October 2018, 08:36 GMT
I am also experiencing this timeout was reached issue and can confirm that on my system thunar can also still be executed using sudo privileges, with the same output as @bgroves. I have not yet tried downgrading to a previous version as I have an alternate to utilise in the meantime.
Comment by Alexander F. Rødseth (xyproto) - Monday, 08 October 2018, 08:42 GMT
I'm unable to reproduce the issue under i3, as a regular user. I'm running /usr/bin/thunar, and everything seems to work.

Which windowmanager are people running when Thunar fails to run?

Does it work if ~/.config/Thunar is temporarily renamed?
Comment by James (ronnie_p) - Monday, 08 October 2018, 09:05 GMT
@xyproto

1. I'm using xfce4 with xfwm4.

2. No, renaming the Thunar folder in ~/.config doesn't change anything. It doesn't even create a new default instance of the folder upon executing. (I'm assuming as an outsider that this would normally be the case). For the record I did not restart xfce after moving the folder.
Comment by Antonio Ghu (aghu) - Tuesday, 09 October 2018, 13:18 GMT
I experienced the same issue under i3 after update.Thunar worked with sudo.
Tried to remove .config/Thunar, without any result.
After the command
killall thunar
Thunar worked again, but I needed to do it after a reboot (maybe also after a simple logout because of the following).
Commenting out from configuration of i3 the following line
exec --no-startup-id thunar --daemon &
Thunar is now correctly working and also when starting i3 Thunar starts without problem
(it starts because of the line
exec --no-startup-id thunar
still present in the configuration file of i3)
I suppose that the problem is in the early launch of Thunar as a daemon done by the wm in use to speed up following launches of Thunar.
Hope that this will help!
Comment by James (ronnie_p) - Tuesday, 09 October 2018, 14:09 GMT
I also managed to retrieve functionality through $ killall Thunar #I found it to be case sensitive

At present I can't comment on reboot behaviour. Thanks to @aghu
Comment by Timothy Lee (timothy.ty.lee) - Tuesday, 06 November 2018, 08:05 GMT
I was able to fix this permanently without downgrading to 1.8.1.11.gf5147445-1 by deleting the file ~/.cache/sessions/xfce4-session-<hostname>:0
Comment by drew (slaqer) - Wednesday, 07 November 2018, 01:15 GMT
I can second deleting ~/.cache/sessions/xfce4-session-<hostname>:0 as a fix.

So far Thunar 1.8.2-1 is now working for me, even after reboot.
Comment by Khurram Mahmood (makh) - Tuesday, 21 May 2019, 03:52 GMT
I am having this problem at random: sometimes Thunar starts, sometimes it doesnt.

Updated System with thunar 1.8.4-2 (xfce4) [installed]

Terminal Response: "Failed to register: Timeout was reached"
Comment by Thomas Jäger (xunil64) - Friday, 03 January 2020, 11:37 GMT
Is there any update on this?

Since some time i have this during a xfce session (initially fine, after some time thunar couldnt be opened any longer).
When this happens thunar couldnt be restarted (killall thunar not working - no thunar process)
Maybe related to gvfs-udisks2 - but just an asumption (found some things about this)
Volume Management inside thunar is switched off (thunar-volman and thunar-volman-settings can still be opened)
NFS or SMB connections are fine too (when using a terminal everything can be reached)
Comment by muddy (muddyh20) - Tuesday, 21 January 2020, 01:32 GMT
I'm getting the same as Thomas and I've traced it back to the thunar-1.8.11-1 update back in November.
I have to reboot every couple days to get Thunar working again
I can run Thunar as root no issues but as my normal user I get :
$ thunar
Failed to register: Timeout was reached

and also seeing in the logs:
Failed to set property "thunar::/last-details-view-column-widths": Operation was cancelled

Have tried various cures like clearing out ~/.cache/sessions/ and other tweaks all have had no impact.
Comment by esmaeel (esmaeelE) - Wednesday, 12 February 2020, 21:04 GMT
I remove thunar and compile latest version Thunar-1.8.12 from source. Also this version not start with default user.
> Failed to register: Timeout was reached
Only running with superuser $ sudo thunar will open it.
But after reboot new installed thunar open will current user.
Comment by Stefan Förster (HotblackDesiato) - Saturday, 16 May 2020, 03:20 GMT
I get the same error in version 1.8.14-1. Deleting the xfce4 session files doesn't help.

sudo thunar works.

Comment by Any Somebody (AnySomebody) - Monday, 03 August 2020, 10:49 GMT
Same error here with 1.8.15-1 after thunar crashed.
Comment by mattia (nTia89) - Tuesday, 08 December 2020, 20:21 GMT
Can't reproduce the issue on latest update (.16);
please be sure it's not a .config problem: for safety, you can test it creating a new user; in this way you are sure configuration files are not broken.
Comment by Royce Williams (tychotithonus) - Thursday, 10 June 2021, 15:43 GMT
FWIW, I have been able to (somewhat) reliably reproduce this error when real RAM is maxed out and a system is heavily into swap.

Loading...