LinuxQuestions.org - [SOLVED] efreetd error-message

- Bodhi (https://www.linuxquestions.org/questions/bodhi-92/)

- - efreetd error-message (https://www.linuxquestions.org/questions/bodhi-92/efreetd-error-message-4175666756/)

efreetd error-message

Hi altogether,

lately I´ve encountered a phenomenon which puzzles me quite a bit. Perhaps there´s someone who can help me.

I run BodhiLinux 5.1.0 (32 bit) in a virtual machine (virt-manager; qemu/kvm). My host is Lubuntu 18.04.3 LTS, 64 bit.
It works fine. However I get an error-message as soon as the log-in is complete.

A pop-up window appears saying the following:

Code:

E: Efreetd cannot be connected toPlease check:

$XDG_RUNTIME_DIR /.ecore/efreetd/0

or

~/.ecore/efreetd/0

Is your system very slow on start so

efreetd cannot be connected to within

0.5sec after launch??

This message didn´t use to pop up until recently. Yet I haven´t changed anything reading config.

Plus I´m not sure what efreeet is or does.
Yet - as I said - the system works fine but this message still keeps popping up.

Can anybody help me?

Thanks a lot in advance.

Greetings.
Rosika :confused:

@teckk:

Hi and thanks for your reply and the links.

Quote:

Efreet is a library designed to help apps work several of the Freedesktop.org standards regarding Icons, Desktop files and Menus.

O.K., now I know that it´s a library helping apps in several ways. That´s fine.

But despite the error-message I can´t notice anything wrong with the system. Everything is displayed as it should be and also behaves that way.

Curious thing: I don´t get this error-message every time I start Bodhi.
The first time I started it today I got it. But the 2nd, 3rd and 4th time I didn´t!

Plus: the 2nd, 3rd and 4th time Bodhi started much quicker.

And the pop-up message says:

Quote:

Is your system very slow on start so
efreetd cannot be connected to within
0.5sec after launch??

So it seems that start speed has something to do with it.
Yet I´m not quite sure why the first start today took longer that the other ones.

Anyway thanks again your help.

Greetings.
Rosika

this discussion seems to be about the same issue (with a seemingly simple fix). though i thought we were using a different version/branch of enlightenment maybe it will help :)

@cordx:

Thanks for the link.Yet I couldn´t apply the fix.

Quote:

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

Deleting ~/.ecore/efreetd/0 clears up the problem.

The thing is: these paths don´t exist in my Bodhi.

I have just one efreetd-path:

Code:

locate efreetd

/usr/bin/efreetd

None of the efreet-related entries in home exist.

Greetings.
Rosika

Hi and a Happy New Year to you all,

meanwhile I´m convinced that my problem is not so much connected to efreetd itself but rather to my system being
rather slow on start. The respective error-message says:

Quote:

[...]
Is your system very slow on start so
efreetd cannot be connected to within
0.5sec after launch??

And this really has to the case here.

Whenever I start Bodhi the 1st time in my VM on any given day (after my host was shut down overnight) I get this
message. And startup is slow indeed.
When shutting down the VM and booting it up again (even after a while) startup is much faster and I don´t get this message.

All this leads me to thinking that the real "problem" here is the slow 1st-time-boot rather than efreetd itself.
It isn´t a real problem though as I don´t get any negative effects running Bodhi even if the error-message appears.

Greetings
Rosika :)

if you are curious about the slow boot time, you could try

Code:

systemd-analyze blame

and compare that to one of the faster boot times to see what the hangup is.

Hi cordx and thanks,

Those are the results of yesterday:

slow start with efreetd-error:

Code:

systemd-analyze blame

        47.155s apt-daily.service

        12.137s networkd-dispatcher.service

        11.948s dev-vda1.device

        11.213s snapd.service

          9.988s NetworkManager.service

          7.562s NetworkManager-wait-online.service

          7.505s udisks2.service

          6.972s accounts-daemon.service

          6.882s ModemManager.service

          6.414s systemd-journal-flush.service

          5.386s lightdm.service

          5.383s plymouth-quit-wait.service

          5.017s grub-common.service

          4.010s wpa_supplicant.service

          3.665s avahi-daemon.service

          3.546s ubiquity.service

          3.546s gpu-manager.service

          3.164s systemd-logind.service

          2.633s apport.service

          2.588s rsyslog.service

          1.794s spice-vdagentd.service

          1.754s lm-sensors.service

          1.610s systemd-tmpfiles-setup-dev.service

          1.576s polkit.service

          1.480s pppd-dns.service

          1.435s systemd-udevd.service

          1.344s systemd-sysctl.service

          1.335s lvm2-monitor.service

          1.262s keyboard-setup.service

          1.130s user@1000.service

          1.102s apt-daily-upgrade.service

          1.089s alsa-restore.service

          791ms motd-news.service

          772ms systemd-tmpfiles-setup.service

          642ms systemd-timesyncd.service

          587ms swapfile.swap

          583ms snapd.seeded.service

          462ms systemd-resolved.service

          323ms systemd-random-seed.service

          274ms systemd-journald.service

          266ms console-setup.service

          255ms udisks.service

          171ms hddtemp.service

          147ms dev-mqueue.mount

          145ms sys-kernel-debug.mount

          144ms systemd-remount-fs.service

          138ms ufw.service

          125ms kmod-static-nodes.service

          122ms blk-availability.service

          118ms dev-hugepages.mount

          100ms systemd-modules-load.service

            96ms setvtrgb.service

            91ms systemd-udev-trigger.service

            61ms systemd-update-utmp.service

            46ms rtkit-daemon.service

            29ms plymouth-start.service

            20ms plymouth-read-write.service

            17ms systemd-user-sessions.service

            8ms systemd-update-utmp-runlevel.service

            7ms sys-fs-fuse-connections.mount

            6ms snapd.socket

faster start without the error-message:

Code:

systemd-analyze blame        

          11.577s dev-vda1.device

          9.720s networkd-dispatcher.service

          9.198s snapd.service

          9.090s ModemManager.service

          9.031s accounts-daemon.service

          8.631s udisks2.service

          6.784s apport.service

          6.380s grub-common.service

          5.834s NetworkManager.service

          5.759s avahi-daemon.service

          5.598s lm-sensors.service

          5.536s alsa-restore.service

          5.497s systemd-logind.service

          5.489s pppd-dns.service

          5.480s rsyslog.service

          5.399s spice-vdagentd.service

          5.357s gpu-manager.service

          5.291s ubiquity.service

          4.992s systemd-journal-flush.service

          4.020s plymouth-quit-wait.service

          4.013s lightdm.service

          2.359s NetworkManager-wait-online.service

          1.963s polkit.service

          1.383s wpa_supplicant.service

          1.219s systemd-udevd.service

          903ms systemd-tmpfiles-setup-dev.service

          500ms keyboard-setup.service

          362ms systemd-sysctl.service

          330ms systemd-timesyncd.service

          312ms snapd.seeded.service

          274ms systemd-tmpfiles-setup.service

          266ms lvm2-monitor.service

          249ms systemd-resolved.service

          217ms systemd-udev-trigger.service

          186ms systemd-modules-load.service

          176ms swapfile.swap

          175ms systemd-journald.service

          162ms console-setup.service

          158ms setvtrgb.service

          131ms ufw.service

          111ms user@1000.service

            90ms systemd-random-seed.service

            88ms sys-kernel-debug.mount

            87ms blk-availability.service

            86ms systemd-update-utmp.service

            79ms systemd-remount-fs.service

            63ms udisks.service

            49ms rtkit-daemon.service

            37ms dev-hugepages.mount

            36ms dev-mqueue.mount

            36ms kmod-static-nodes.service

            30ms hddtemp.service

            26ms systemd-user-sessions.service

            24ms plymouth-start.service

            21ms plymouth-read-write.service

            19ms systemd-update-utmp-runlevel.service

            6ms sys-fs-fuse-connections.mount

            2ms snapd.socket

So apt-daily.service seems to take up most of the time.
I decided to set "software-properties-gtk" so that it doesn´t automatically look for updates and checked again today:

Quote:

12.277s networkd-dispatcher.service
11.021s accounts-daemon.service
10.163s udisks2.service
9.538s dev-vda1.device
9.187s apt-daily.service
9.160s systemd-journal-flush.service
8.945s snapd.service
8.159s NetworkManager.service
7.108s grub-common.service
6.622s apport.service
6.240s ModemManager.service
5.685s spice-vdagentd.service
5.507s avahi-daemon.service
5.497s NetworkManager-wait-online.service
5.295s alsa-restore.service
5.268s gpu-manager.service
5.263s ubiquity.service
[...]

So apt-daily.service has a much lower value. I thought this might be the solution.
However I got the efreetd-error again today.

Greetings.
Rosika

interesting results. sorry to hear they didn't clear your error. i figured since i also run virt-manager with kvm/qemu i might as well fire up a legacy bodhi vm on my 64-bit bodhi host to see if i could recreate the error.

it is a mostly barebones install. i installed htop and lxappearance + qt4-qtconfig to keep an eye on system resources and adjust font sizes. i added spice-vdagent as well. i checked and found that i also do not have a ~/.ecore directory. i will try running it from time to time to see if the error starts appearing.

Hi cordx,

thank you so much for your help.

In the meantime I did the following:

As the error message says

Quote:

E: Efreetd cannot be connected toPlease check:
$XDG_RUNTIME_DIR /.ecore/efreetd/0

I did just that:

Code:

 echo $XDG_RUNTIME_DIR

/run/user/1000

Code:

echo $XDG_RUNTIME_DIR/.ecore/efreetd/0

/run/user/1000/.ecore/efreetd/0

The efreetd folder was empty. That was the situation with slow boot-up plus the error-message:

Code:

ll /run/user/1000/.ecore/efreetd/

total 0

And here are the results for the faster boot-up without the error-message:

Code:

ll /run/user/1000/.ecore/efreetd/

total 0

srwx------ 1 rosika2 rosika2 0 Jan  5 13:28 0=

Now there is some content in the respective folder.
It´s a file with the name "0", size 0 bytes, type: socket.

No idea if that helps at all but there´s definitively a difference.

Do you have any idea why Bodhi starts slowly only at first boot whereas all the following boots are much faster (without the efreetd-error)?

Greetings.
Rosika

at present i am getting the same output to the commands you shared (thanks for teaching me ll by the way. i hadn't seen that one before) in addition to not seeing the efreet error message. i have the same "0" file that is also listed as a socket. for comparison, i also have the same "0" file in the same location on my 64-bit host system.

unfortunately i have no idea what accounts for the start time discrepancy. i created the vm to see if i could reproduce the error. so far it hasn't shown up on mine.

i figured if i did see it, i would compare systemd-analyze and systemd-analyze blame results like you posted previously. in addition, i would run either sudo dmesg | grep efreet or sudo dmesg --level=err (followed by --level=warn) to see if something pops up that might give a hint as to what is going wrong in the background.

Hi cordx,
tnx for your reply.

Quote:

at present i am getting the same output to the commands you shared

Fine, at least the "normal" start looks O.K. then. It´s good to have confirmation.

For now ("normal" start):

Code:

sudo sh -c "dmesg | grep efreet"

yields no results. And:

Code:

sudo dmesg --level=err,warn

[    0.057891] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.

[    0.057900] acpi resource window ([0x100000000-0x17fffffff] ignored, not CPU addressable)

[    0.212760] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10

[    0.256323] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11

[    0.299399] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11

[    0.342095] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10

[    4.348681] cgroup: cgroup2: unknown option "nsdelegate"

[    5.324904] systemd[1]: File /lib/systemd/system/systemd-journald.service:35 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.

[    5.324909] systemd[1]: Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)

So this is to be compared with the next possible slow start. I´ve posted it now so that we have this one already.

In the meantime: thanks again for your help and have a nice rest of the weekend.

Greetings.
Rosika :)

Hello cordx,

I´ve just booted my Bodhi and - as always for the first time on any given day - I had a slow start with the error-message).
So now I can post the missing information as already discussed:

Code:

sudo sh -c "dmesg | grep efreet"

still yields no results.
And

Code:

 sudo dmesg --level=err,warn

[    0.057998] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.

[    0.058006] acpi resource window ([0x100000000-0x17fffffff] ignored, not CPU addressable)

[    0.209099] ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 10

[    0.251812] ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11

[    0.294474] ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11

[    0.337294] ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 10

[    8.036065] cgroup: cgroup2: unknown option "nsdelegate"

[  10.387589] systemd[1]: File /lib/systemd/system/systemd-journald.service:35 configures an IP firewall (IPAddressDeny=any), but the local system does not support BPF/cgroup based firewalling.

[  10.387592] systemd[1]: Proceeding WITHOUT firewalling in effect! (This warning is only shown for the first loaded unit using IP firewalling.)

seems to be the same output as before.

So to sum up: Alas neither of the two commands seems to provide us with any clues as to what might be going on in the background.
Sorry.
But thanks again for your help.

Greetings.
Rosika:)

*****additional information*****

In the meantime I installed debian-goodies which gives me a few additional commands for some utilities.

Quote:

Debian-goodies is a package that includes toolbox-style utilities used to manage Debian and its derivative systems such as Ubuntu, Kali Linux. The utilities under this package are developed in such a way to combine with many recognized shell tools and others are included because they cannot be developed as their own packages on Debian-based Linux distributions.

One of the commands is sudo checkrestart -a (Finds and restarts processes which are using outdated versions of upgraded files)
Perhaps interesting:

Code:

 sudo  checkrestart -a

lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs

      Output information may be incomplete.

Found 6 processes using old versions of upgraded files

(6 distinct programs)

(6 distinct packages)

These processes (6) do not seem to have an associated init script to restart them:

moksha:

        958        /usr/bin/enlightenment

libefl-bin:

        959        /usr/bin/efreetd  # what to do with that one?

network-manager-gnome:

        1003        /usr/bin/nm-applet

at-spi2-core:

        1017        /usr/lib/at-spi2-core/at-spi-bus-launcher

pulseaudio:

        1070        /usr/bin/pulseaudio

terminology:

        1088        /usr/bin/terminology

So there´s an efreetd-related entry in the list. Efreetd seems to be using an old version of an upgraded file.....

Greetings.
Rosika

i didn't figure it was worth reporting that my system didn't have any kind of an error yesterday (nor did it today). i thought i would wait a few days to see if something popped up, but wanted to share my results from installing debian-goodies and running sudo checkrestart -a as well as my results from sudo dmesg -H --level=err,warn.

my dmesg results are exactly the same and my checkrestart are almost identical except that i have htop added to my list.

a while back i found this page to be a helpful description of journalctl options. i tried running journalctl -b -1 | grep efreet (looking at boot logs. also efreetd and efreet*) as well as journalctl -p emerg..err | grep efreet (with the same efreet variations) and just plain journalctl | grep efreet (even though my system hasn't given me the error) just to see if there was anything efreet related, but i got no results.

my preferred log viewer is lnav. i like that it follows syslog if you leave it open and running and there are errors (in red in my terminal) and warnings (yellow) that i don't see show up in dmesg. in case you are interested in another way to check logs :)