Page MenuHomePhabricator

E: Efreet did not update cache. Please check your Efreet setup
Closed, ResolvedPublic

Description

I get this popup every time I start E. Happens with a fresh install of 0.22.3

@charlesgwaldman

Which version of EFL are you using. Also, which operating system?

Can you also provide the output of this command:

ulimit -a

I'm on Gentoo Linux, running dev-libs/efl-1.20.7 (latest version in Gentoo repo)

ulimit -a says:

core file size (blocks, -c) unlimited
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 63265
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 99
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 63265
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited

According to discussion on IRC, lots of people are seeing this Efreet popup

charlesgwaldman mentioned this in Unknown Object (Maniphest Task).Jun 21 2018, 7:42 AM

ERR<20449>:efreet_cache lib/efreet/efreet_cache.c:169 _cb_server_del() efreetd connection failed 10 times! check for stale socket files in /home/cgw/.run//.ecore/efreetd

/usr/lib64/libeina.so.1  | ??/??: 0 @ _eina_semaphore_free()
/usr/lib64/libeina.so.1  | ??/??: 0 @ eina_log_print_cb_stdout()
/usr/lib64/libeina.so.1  | ??/??: 0 @ eina_log_print()
/usr/lib64/libefreet.so.1| ??/??: 0 @ efreet_cache_array_string_free()
/usr/lib64/libecore.so.1 | ??/??: 0 @ ecore_event_add()
/usr/lib64/libecore.so.1 | ??/??: 0 @ ecore_main_fd_handler_add()
/usr/lib64/libecore.so.1 | ??/??: 0 @ ecore_main_loop_begin()
  /usr/bin/enlightenment | ??/??: 0 @ main()
    /lib64/libc.so.6     | ??/??: 0 @ __libc_start_main()
  /usr/bin/enlightenment | ??/??: 0 @ _start()

I noticed that the directory ~/.run/.ecore did not exist, I created that, as well as ~/.run/.ecore/efreetd
The problem persists

charlesgwaldman added a comment.EditedJun 21 2018, 8:08 AM

Next message in log: (this doesn't seem right, since efreet *did* notify via popup)

E: efreet didn't notify about cache update
ERR<20449>:evas-gl_x11 modules/evas/engines/gl_x11/evas_engine.c:1995 _native_bind_cb() eglCreateImage() for Pixmap 0x0x80003d failed: 0x3004

                                       /usr/lib64/libeina.so.1      | ??/??: 0 @ _eina_semaphore_free()
                                       /usr/lib64/libeina.so.1      | ??/??: 0 @ eina_log_print_cb_stdout()
                                       /usr/lib64/libeina.so.1      | ??/??: 0 @ eina_log_print()
    /usr/lib64/evas/modules/engines/gl_x11/v-1.20/module.so         |   /  : 0 @ ()
/usr/lib64/evas/modules/engines/gl_generic/v-1.20/module.so         |   /  : 0 @ ()
                                       /usr/lib64/libevas.so.1      | ??/??: 0 @ evas_filter_program_source_set_all()
                                       /usr/lib64/libevas.so.1      | ??/??: 0 @ evas_font_reinit()
                                       /usr/lib64/libevas.so.1      | ??/??: 0 @ evas_font_reinit()
                                       /usr/lib64/libevas.so.1      | ??/??: 0 @ evas_render_updates_free()
                                       /usr/lib64/libevas.so.1      | ??/??: 0 @ evas_canvas_render_updates()
           /usr/lib64/ecore_evas/engines/x/v-1.20/module.so         |   /  : 0 @ ()
                                       /usr/lib64/libecore_evas.so.1| ??/??: 0 @ _ecore_evas_fps_debug_rendertime_add()
                                       /usr/lib64/libecore.so.1     | ??/??: 0 @ ecore_idle_exiter_del()
                                       /usr/lib64/libeo.so.1        | ??/??: 0 @ efl_composite_part_is()
                                       /usr/lib64/libeo.so.1        | ??/??: 0 @ efl_event_callback_call()
                                       /usr/lib64/libecore.so.1     | ??/??: 0 @ ecore_main_fd_handler_add()
                                       /usr/lib64/libecore.so.1     | ??/??: 0 @ ecore_main_loop_begin()
                                         /usr/bin/enlightenment     | ??/??: 0 @ main()
                                           /lib64/libc.so.6         | ??/??: 0 @ __libc_start_main()
                                         /usr/bin/enlightenment     | ??/??: 0 @ _start()
zmike added a subscriber: zmike.Jun 22 2018, 2:28 PM

Try running with EINA_LOG_LEVELS=ecore_con:4.

zmike merged a task: Unknown Object (Maniphest Task).Jun 22 2018, 2:29 PM

My suspicion is the UNIX domain socket might not be getting unlinked. Just a thought.

ERR<20449>:efreet_cache lib/efreet/efreet_cache.c:169 _cb_server_del() efreetd connection failed 10 times! check for stale socket files in /home/cgw/.run//.ecore/efreetd

$ ls ~/.ecore/efreetd/0
/home/cgw/.ecore/efreetd/0

Deleting ~/.ecore/efreetd/0 clears up the problem. I would have found this sooner but the log message says to check in ~/.run, which is not the correct dir. I just found the right dir by poking around ...

ERR<20449>:efreet_cache lib/efreet/efreet_cache.c:169 _cb_server_del() efreetd connection failed 10 times! check for stale socket files in /home/cgw/.run//.ecore/efreetd

$ ls ~/.ecore/efreetd/0
/home/cgw/.ecore/efreetd/0

Deleting ~/.ecore/efreetd/0 clears up the problem. I would have found this sooner but the log message says to check in ~/.run, which is not the correct dir. I just found the right dir by poking around ...

Running with EINA_LOG_LEVELS=ecore_con:4 did not yield any additional information

zmike edited projects, added efl: system integration; removed efl.Jun 25 2018, 9:44 AM

Oh, okay so the error message is using the wrong directory. Thanks, I'll get this fixed!

zmike claimed this task.Jun 25 2018, 9:45 AM
zmike added a subscriber: OnlyHuman.

So it seems like in some circumstances the socket isn't being unlinked.

zmike added a comment.Jun 25 2018, 2:00 PM

Yes, if it gets killed then it will not delete the socket. That's why the error message exists.

The only real issue here is that the error message was referring to the wrong location, which should be resolved by D6425.

Just my $0.02, but it would probably be a good idea and would prevent problems if the socket were put in a directory that is cleaned up automatically (/tmp, /run, etc). Instead of fixing the error message, perhaps the use of ~/.ecore is incorrect -

See comments in
src/lib/efl/interfaces/efl_vpath_core.c: // fallback - make ~/.run

why are we creating ~/.run if not using it?

Also see comments about XDG_RUNTIME_DIR in https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

 $XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700.

The lifetime of the directory MUST be bound to the user being logged in. It MUST be created when the user first logs in and if the user fully logs out the directory MUST be removed.

Thanks for your consideration

Just my $0.02, but it would probably be a good idea and would prevent problems if the socket were put in a directory that is cleaned up automatically (/tmp, /run, etc). Instead of fixing the error message, perhaps the use of ~/.ecore is incorrect -

See comments in
src/lib/efl/interfaces/efl_vpath_core.c: // fallback - make ~/.run

why are we creating ~/.run if not using it?

Also see comments about XDG_RUNTIME_DIR in https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

 $XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700.

The lifetime of the directory MUST be bound to the user being logged in. It MUST be created when the user first logs in and if the user fully logs out the directory MUST be removed.

Thanks for your consideration

By default, and unless the process is using suid to assume root privileges, XDG_RUNTIME_DIR is used for the socket. In the case where XDG_RUNTIME_DIR is not used, or the directory is not cleaned up, this is outside the scope of EFL and is a user/distro configuration error.

zmike triaged this task as Normal priority.Jun 27 2018, 12:35 PM

Hi Mike. I understand your comment.

But there's something here that doesn't quite make sense.

efl/interfaces/efl_vpath_core.c:

125          // fallback - make ~/.run
126          snprintf(buf, sizeof(buf), "%s/.run", home);

So, why are we creating ~/.run if we're not going to use it?

I think the code that is using ~/.ecore is incorrect, and the error message is correct. I think it would make more sense to put these files in ~/.run.

zmike added a comment.Jun 28 2018, 8:25 AM

Two points:

  1. The updated error message simply uses the same path construction method that the ipc connection uses to find the socket file, so this is absolutely correct
  2. The code you cited no longer exists: https://git.enlightenment.org/core/efl.git/tree/src/lib/efl/interfaces/efl_vpath_core.c

Thanks Mike.

Perhaps I should start running the git version of E. efl_vpath_core.c is present as of version 0.22.3 which is what I'm running here.

I'll update to the git version before submitting any further bug reports.

  • Charles

Hi again, I'm running the latest version from Git. I think there are still some irregularities regarding the efreet socket location:

  1. You are correct - ef_vpath_core.c does not exist any more. But:

in ./src/lib/eina/eina_vpath.c we have _fallback_runtime_dir(const char *home)

63     // fallback - make ~/.run
64     snprintf(buf, sizeof(buf), "%s/.run", home);

so the ~/.run directory is still getting created, but not used for anything.

  1. XDG_RUNTIME_DIR is set:

$ env|grep XDG

XDG_MENU_PREFIX=e-
XDG_DATA_DIRS=/usr/share/enlightenment:/usr/local/share:/usr/share
XDG_RUNTIME_DIR=/tmp/xdg-aQ4l64
XDG_CONFIG_DIRS=/usr/etc/xdg:/etc/xdg

The main socket for Enlightenment winds up in $XDG_RUNTIME_DIR, but the efreet socket is in ~/.ecore:

$ ls -l ~/.ecore/efreetd/0 /tmp/xdg-aQ4l64/e-cgw@0/7149\|0
srwx------ 1 cgw cgw 0 Jul 2 06:42 /home/cgw/.ecore/efreetd/0
srwxrwxrwx 1 cgw cgw 0 Jul 2 06:42 '/tmp/xdg-aQ4l64/e-cgw@0/7149|0'

$ find /tmp/xdg-aQ4l64/
/tmp/xdg-aQ4l64/
/tmp/xdg-aQ4l64/e-cgw@0
/tmp/xdg-aQ4l64/e-cgw@0/7149|0

But, if I restart Enlightenment, the efreetd socket migrates from ~/.ecore to $XDG_RUNTIME_DIR

(after restarting:)

$ ls -l ~/.ecore/efreetd/
total 0

$ find /tmp/xdg-aQ4l64/
/tmp/xdg-aQ4l64/
/tmp/xdg-aQ4l64/e-cgw@0
/tmp/xdg-aQ4l64/e-cgw@0/7149|0
/tmp/xdg-aQ4l64/.ecore
/tmp/xdg-aQ4l64/.ecore/efreetd/0