Jump to content

Photo

Excessive CPU useage by menu_cached process


Best Answer ylee, 15 September 2017 - 09:27 AM

I have added the hopeful last set of potential fixes from upstream into the repo. Please let us know if this fixes the menu-cache issue reported here. It should in theory and it does for me locally on my test machines.

 

Just run your system updates as normal to install them. Or if you would prefer not to update your entire system the below should suffice:
 
 

sudo apt-get update
sudo apt-get install libmenu-cache3 libmenu-cache-bin

  
 If these  packages cause any additional issues NOT related to the menu-cache issue please open a new support thread. Thanks for your time and patience.
 

I think I speak for more than myself on this but, Thanks ylee for all your time and effort in keeping Bodhi Linux one of the best distro's around!

 
Thanks Randy :D But really no need to thanks me. It is all in days work or in this case almost a weeks work. And really the true thanks goes to Andriy who had an interest and motivation to fix an LXDE library which worked fine in LXDE to accommodate changes in EFL and who quickly knew how to modify the menu-cache code based up the errors showing up in my debugging sessions. It would have taken me days if not weeks to get to that level of competency  with that code base. 

 

 

Regardless I have always contributed back to Open-source as long as I have been using it. This predates my usage of Bodhi. It is just I am really visible here and Bodhi members of course notice.

Go to the full post


  • Please log in to reply
42 replies to this topic

#1 amerigena

amerigena

    Member

  • Members
  • 39 posts

Posted 02 September 2017 - 12:02 AM

I was working with my new 4.3.1 linstall, let it idle for a few hours, when I came back to it, the system was crawling and virtually useless.

Running top, several instances (3) of a process menu_cached. I'm not familiar with the process, so I output top to a text file and did a sudo killall menu-cached. This brought the system back-to-useable.

Lines detailing the process are below:

 

[7m  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND     (B[m[39;49m[K
(B[m[1m21129 rg        23   3   30908    260      0 R  44.4  0.0  22:51.02 menu-cached (B[m[39;49m[K
(B[m[1m21142 rg        23   3   30908    260      0 R  44.4  0.0  22:50.38 menu-cached (B[m[39;49m[K
(B[m[1m21085 rg        23   3   30880    252      0 R  38.9  0.0  22:51.22 menu-cached (B[m[39;49m[K
(B[m[1m23412 rg        39  19  203188  66868  10184 R  38.9  2.0   0:18.10 efreet_ico+ (B[m[39;49m[K
 
Best I could do.
Output of lspci : 
 
-200:~$ lspci
00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller
 (rev 02)
00:01.0 PCI bridge: Intel Corporation 82G33/G31/P35/P31 Express PCI Express Root
 Port (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express Integrate
d Graphics Controller (rev 02)
00:19.0 Ethernet controller: Intel Corporation 82562V-2 10/100 Network Connectio
n (rev 02)
00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controll
er #4 (rev 02)
00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 02)
00:1a.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 02)
00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92)
00:1f.0 ISA bridge: Intel Corporation 82801IR (ICH9R) LPC Interface Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 4 port SATA Controller [IDE mode] (rev 02)
00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
00:1f.5 IDE interface: Intel Corporation 82801I (ICH9 Family) 2 port SATA Controller [IDE mode] (rev 02)
 
Dmesg was too long. If anyone's interested, I can export it to a text file.
Thanks.

amerigena





A big thank you to everyone who contributes to Bodhi Linux


#2 Jeff

Jeff

    Lead Developer

  • Developer
  • 12493 posts
  • LocationBloomington, IL

Posted 02 September 2017 - 04:40 AM

This is a bug in PCManFM that only affects some systems. Will have to take some time to look into more fixes - the last one I tried to apply apparently didn't solve it.

 

On my one system that has this issue I just uninstall PCManFM for now and replaced it with Thunar. 



#3 The waiter

The waiter

    Module Master

  • Developer
  • 1614 posts
  • LocationBanska Bystrica, Slovakia

Posted 02 September 2017 - 08:32 AM

Is it a matter of particular pcmanfm version? Can upgrade help? I don't know this issue as the first thing after installation is thunar install. I can remember some debate on the forum about the default FM. I can see more pros in case of Thunar...

 

EDIT: Oh, the culprit is menu-cache. 

As sef pointed in another thread http://forums.bodhil...cpu-gets-stuck/ related to 100% CPU issue, the solution should be libmenu-cache ugrade to version 1.0.2. We have 1.0.1 version in the repo which was released in 2015 and does not include the fix. 



#4 Charles@Bodhi

Charles@Bodhi

    Old Faithful

  • Moderators
  • 4558 posts
  • LocationZeist, The Netherlands

Posted 02 September 2017 - 09:26 AM

Might be triggered by the right click options menu in PCManFM using "Open with .." When you give a command like "sudo epad" it can not find a .desktop file with the corresponding exec=?? line which causes an endless loop. As far as I know we use the latest lib  for menu-cached which is supposed to have a patch but it still happens. Not sure this the only cause though.

Thunar is a nice filemanager, but it's heavier than PCManFM.

 

Enjoy,

Charles



#5 The waiter

The waiter

    Module Master

  • Developer
  • 1614 posts
  • LocationBanska Bystrica, Slovakia

Posted 02 September 2017 - 09:30 AM

The screenshot is from my VB with BL 4.3.1. I can see v 1.0.1. Did I miss something? Anyway, 1.0.1 is the last version providing with Xenial repo. Hard to say if v.1.0.2 is possible to install. We should try.

 

e-59aa78ebb34f00.61754286.jpg



#6 Charles@Bodhi

Charles@Bodhi

    Old Faithful

  • Moderators
  • 4558 posts
  • LocationZeist, The Netherlands

Posted 02 September 2017 - 09:53 AM

Hmm, I was talking about this:

charles@B64-S4216:~$ dpkg -l libmenu*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name                           Version              Architecture         Description
+++-==============================-====================-====================-==================================================================
ii  libmenu-cache-bin              1.0.2-1              amd64                LXDE implementation of the freedesktop Menu's cache (libexec)
un  libmenu-cache1                 <none>               <none>               (no description available)
ii  libmenu-cache3:amd64           1.0.2-1              amd64                LXDE implementation of the freedesktop Menu's cache
charles@B64-S4216:~$

Not sure this is a Bodhi problem. It happens in PCManFM and that in turn uses an LXDE version for menu-cache. And lubuntu seems to have the same issue though some say there is a working patch, I did not find it.



#7 ylee

ylee

    King of the Software Page

  • Moderators
  • 1574 posts
  • LocationSouth Carolina, USA

Posted 02 September 2017 - 03:41 PM

I haven't tried to reproduce this issue but for those who have noted this issue:

 

Does updating libmenu-cache-bin  and libmenu-cache3 to version 1.0.2-3 solve this issue? As charles notes "there is a working patch" and from what I have read this issue should be solved using the latest versions of the source code.


"No technology can ever be too arcane or complicated for the black t-shirt crowd."


#8 Charles@Bodhi

Charles@Bodhi

    Old Faithful

  • Moderators
  • 4558 posts
  • LocationZeist, The Netherlands

Posted 02 September 2017 - 06:23 PM

Yeah, I had read that topic about issue#7. That solution should have been integrated in the packages we have in Bodhi, but it was not.

 

Added artful/universe to my sources.list and installed version 1.0.2-3 for both but no dice, still cpu at 100%, even after a reboot.

 

A workaround in the case of calling an app to open with sudo (or gksudo) is using esudo, that will work as expected without causing the cpu usage.

 

Enjoy,

Charles



#9 craigus

craigus

    Member

  • Members
  • 39 posts

Posted 02 September 2017 - 10:26 PM

My ugly kludge fix at the moment is to run /usr/bin/killall menu-cached from the root crontab every 5 minutes :wacko:



#10 michmanbiker

michmanbiker

    Member

  • Members
  • 126 posts
  • LocationMontreal, Quebec, Canada

Posted 03 September 2017 - 03:56 AM

This is a bug in PCManFM that only affects some systems. Will have to take some time to look into more fixes - the last one I tried to apply apparently didn't solve it.

 

On my one system that has this issue I just uninstall PCManFM for now and replaced it with Thunar. 

This happens with Thunar too. 



#11 Jeff

Jeff

    Lead Developer

  • Developer
  • 12493 posts
  • LocationBloomington, IL

Posted 03 September 2017 - 02:21 PM

This happens with Thunar too. 

It does not. The library causing this issue is an LXDE library that Thunar does not use.

We have version 1.0.2 in the repos. That was the first I tried to implement based on other threads I read - it doesn't work. 



#12 michmanbiker

michmanbiker

    Member

  • Members
  • 126 posts
  • LocationMontreal, Quebec, Canada

Posted 03 September 2017 - 02:29 PM

It does not. The library causing this issue is an LXDE library that Thunar does not use.

We have version 1.0.2 in the repos. That was the first I tried to implement based on other threads I read - it doesn't work. 

 

OK so the Thunar we have does not work, do we need to install from outside the repos?



#13 Jeff

Jeff

    Lead Developer

  • Developer
  • 12493 posts
  • LocationBloomington, IL

Posted 03 September 2017 - 04:43 PM

Please open a support thread of your own if you are having issues with Thunar describing your issue. Works as expected on all my systems here. 



#14 michmanbiker

michmanbiker

    Member

  • Members
  • 126 posts
  • LocationMontreal, Quebec, Canada

Posted 04 September 2017 - 01:48 AM

Please open a support thread of your own if you are having issues with Thunar describing your issue. Works as expected on all my systems here. 

OK



#15 ylee

ylee

    King of the Software Page

  • Moderators
  • 1574 posts
  • LocationSouth Carolina, USA

Posted 04 September 2017 - 09:58 PM

I have more closely examined this issue and I can now reliably duplicate it. And have a number of observations and a semi-functional hack to address this issue.
 
First a few clarifications:
 

...

Not sure this is a Bodhi problem. It happens in PCManFM and that in turn uses an LXDE version for menu-cache. And lubuntu seems to have the same issue though some say there is a working patch, I did not find it.


The patch you couldn't find was committed: Merge pull request #12 from mtasaka/localwork
 

Yeah, I had read that topic about issue#7. That solution should have been integrated in the packages we have in Bodhi, but it was not.
 
...


Downloading the source code used to make ubuntu's deb files, this patch is present in version 1.0.2-1. So it is present on Bodhi's version of this library. Regardless I compiled the git version of this library on Bodhi and using it the issue remains, it also remains if I update pcmanfm and the libfm stuff to the latest versions. 

 

But it works on the lubuntu desktop
 
I have a lubuntu 16.04 virtual machine I use  for testing purposes, compiling code and so on. On this VM I have several DEs installed, and snapshots with moksha and several versison of e compiled. Using LXDE on this VM , pcmanfm works fine with no menu-cache issue at all. Logging out and logging into Moksha or enlightenment any version and we have the menu-cache issue with pcmanfm. I am unsure why the command /usr/lib/menu-cache/menu-cached works if called in a terminal but seemingly doesn't work (hangs as above) if called by a gui-process like pcmanfm in enlightenment. 
 
I am unsure why so I can't say for sure this is an issue with the LXDE library or another weirdness with enlightenment. I have not attempted to debug it and am reluctant to do so.
 

 

My ugly kludge fix at the moment is to run /usr/bin/killall menu-cached from the root crontab every 5 minutes :wacko:


:lol:  :lol:  :lol:  :lol:

 

That is indeed rather ugly ....

 

Not that my attempt to 'fix'  is much better but here goes:

 

Download my file, mc_hack.sh make it executable and run it as a regular user in a terminal.  Do not run it as root!! 

 

This script downloads a desktop file from my drop box and installs it. Read it if you understand stuff like that. Also note earlier today I was having issues with dropboxs server timing out so I am hoping that is no longer the case. 

 

It adds a 'program' to Bodhis menu, menu-cache and adds this program to both startup and restart apps in mokshas settings. (it also should work on any version of enlightenment >= 17)

 

In my testing it usually worked but failed sometimes. In this case you may have to kill menu-cached and then rerun the menu-cache program from the menu. In cases where it fails it probably failed because i started pcmanfm 'too soon' after booting or in I clicked on "Applications" in pcmanfms left panel FIRST. It is best to not do either.

 

This is not a proper fix but I am hoping it will suffice for those facing this issue until we can address this issue. If this issue is unresolved Bodhi may have to move away from using pcmanfm as a file manager and move to another fm.  That would be regrettable but linux offers plenty of file managers. 

 

Use at your own risk!!


"No technology can ever be too arcane or complicated for the black t-shirt crowd."


#16 The waiter

The waiter

    Module Master

  • Developer
  • 1614 posts
  • LocationBanska Bystrica, Slovakia

Posted 05 September 2017 - 05:12 PM

I have just done a small research after a debate with Ylee. I am also able to reproduce the pcmanfm issue in BL 4.3.1. What I did was comparing releases:

 

BL 3.2.1 - EFL 1.15    /libmenu v.0.5.1   / PCmanFM 1.2.0/ no problem

BL 4.2.0 - EFL 1.18.4 /libmenu v.1.0.1-1/ PCmanFM 1.2.4/ no problem

BL 4.3.1 - EFL 1.19.1 /libmenu v.1.0.2-1/ PCmanFM 1.2.4/ problem

 

Ylee's suspicion is the EFL could be the culprit. Hard to say. Now we should build the later EFL in hope it could solve the issue

 

EDIT: just upgraded to EFL 1.20.3, the last git release (I hope I did everything properly) and the issue still here :(



#17 ylee

ylee

    King of the Software Page

  • Moderators
  • 1574 posts
  • LocationSouth Carolina, USA

Posted 05 September 2017 - 09:44 PM

I have just done a small research after a debate with Ylee. I am also able to reproduce the pcmanfm issue in BL 4.3.1. What I did was comparing releases:

 

BL 3.2.1 - EFL 1.15    /libmenu v.0.5.1   / PCmanFM 1.2.0/ no problem

BL 4.2.0 - EFL 1.18.4 /libmenu v.1.0.1-1/ PCmanFM 1.2.4/ no problem

BL 4.3.1 - EFL 1.19.1 /libmenu v.1.0.2-1/ PCmanFM 1.2.4/ problem

 

Ylee's suspicion is the EFL could be the culprit. Hard to say. Now we should build the later EFL in hope it could solve the issue

 

EDIT: just upgraded to EFL 1.20.3, the last git release (I hope I did everything properly) and the issue still here :(

 

Debate above means discussion ;)

 

But anyways by the above The waiter means on a default install. As bodhi 4.2 updated is bodhi 4.3.1 for all practical purposes.

 

Regardless of all that my observations are the same, updating efl to 1.20.3 and the menu-cache issue remains :(

 

Further observations on a default install of bodhi 4.2.0. No menu-cache issue and the package versions of stuff relevant to pcmanfm:

  • libmenu-cache-bin 1.0.1-1
  • libmenu-cache3     1.0.1-1
  • libfm-data              1.2.4-1
  • libfm-extra4           1.2.4-1
  • libfm-gtk-data        1.2.4-1
  • libfm-gtk4:i38        1.2.4-1
  • libfm-modules:      1.2.4-1
  • libfm4                    1.2.4-1
  • pcmanfm               1.2.4-1
Upgrading all the above to the latest versions and still no menu-cache issue.
 
Moksha version on a default install of Bodhi 4.2.0 is 20170530bodhi10.2.1 and updating it to the latest version, 20170830bodhi10.2.1 and still no problem. So it is not a Moksha issue but I already knew that or at least suspected it as the issue persists in e21.
 
So that leaves efl. Efl version in Bodhi 4.2 is 201701261.18.4 updating that to the latest version in our repo 201708281.19.1-1 and we have the menu cache issue.
 
The conclusion of all this is that downgrading efl should in theory fix the issue but upgrading efl certainly does not. It is looking very much like an efl issue. I don't have the original efl 201701261.18.4 deb files so perhaps I should rebuild them? Or does anyone have them?
 
EDIT: Jeff had the old efl 1.18.4 debs so I tested taking an up to date bodhi 4.x system and downgrading efl as I thought no menu cache issue. However to use these one needs the old py-efl files that go along with efl 1.18.4 (for apps like epad et al to work right) ... hmm I do have those cause I rebuilt py-efl to include a patch to make fonts work in epad. Tomorrow morning I will upload all the needed files somewhere and post links. Be aware tho downgrading to efl 1.18.4 has its own issues, some users had hard locks and I think memory loss problems ... so this is going to be only a temporary solution for those who need pcmanfm and use the open with feature or the Applications feature in the left panel. 
 
Temporary meaning until someone fixes efl to address this issue. If and when ... no promises.

"No technology can ever be too arcane or complicated for the black t-shirt crowd."


#18 birdmun

birdmun

    Member

  • Members
  • 374 posts
  • LocationWabash, IN

Posted 06 September 2017 - 03:37 AM

I know my comment is off topic.

 

I had to chuckle to myself when I read ylee's comment

 

 

 

"some user had hard locks and I think memory loss problems"

 

I read that as he wasn't sure if there were memory loss problems, so, there were possibly memory loss problems with respect to memory loss problems.  :D



#19 ylee

ylee

    King of the Software Page

  • Moderators
  • 1574 posts
  • LocationSouth Carolina, USA

Posted 06 September 2017 - 11:23 AM

...
EDIT: Jeff had the old efl 1.18.4 debs so I tested taking an up to date bodhi 4.x system and downgrading efl as I thought no menu cache issue. However to use these one needs the old py-efl files that go along with efl 1.18.4 (for apps like epad et al to work right) ... hmm I do have those cause I rebuilt py-efl to include a patch to make fonts work in epad. Tomorrow morning I will upload all the needed files somewhere and post links. Be aware tho downgrading to efl 1.18.4 has its own issues, some users had hard locks and I think memory loss problems ... so this is going to be only a temporary solution for those who need pcmanfm and use the open with feature or the Applications feature in the left panel. 
 
Temporary meaning until someone fixes efl to address this issue. If and when ... no promises.


I placed all relevant efl files in a drop box folder.
 
If you wish to try this 'fix':
 
Download the two needed for whatever version of Bodhi you have installed, 32 bit or 64 bit. Note the 32 bit files end in i386 and the 64 bit files end in amd64.
 
For convenience sake here are the direct links:
 
64 bit debs:

32 bit debs

You need only the efl and python-efl for a default install of Bodhi 4.x. You will only need the python3-efl file if you use a python3 efl app or  are a programmer who needs it.
 
Download the files you need and install them. I would also lock the version of the package so that in the future it will not be upgraded.

 

As an example, for 64 bit bodhi and using the command line, here are the commands needed to download, install and lock the version of efl and python-efl:
 

mkdir efl_downgrade
cd efl_downgrade/
wget https://www.dropbox.com/s/vzr4w8u6y5qlete/efl_201701261.18.4bodhi1-1_amd64.deb
wget https://www.dropbox.com/s/hut6f1meq354kos/python-efl_201704111.18.0bodhi1-1_amd64.deb
sudo dpkg -i *.deb
sudo apt-mark hold efl
sudo apt-mark hold python-efl

 
If you have tried the my first attempt at a 'solution' above mc_hack.sh, you can safely delete the  menu_cache.desktop file found in ~/.local/share/applications and remove menu-cache from BOTH Bodhi's startup and restart Apps in Settings. Of course it is harmless to leave it there.

 

If and when a better solution presents itself (such as efl is patched to prevent this issue) I will post here.


"No technology can ever be too arcane or complicated for the black t-shirt crowd."


#20 ylee

ylee

    King of the Software Page

  • Moderators
  • 1574 posts
  • LocationSouth Carolina, USA

Posted 11 September 2017 - 02:28 PM

...

But it works on the lubuntu desktop
 
I have a lubuntu 16.04 virtual machine I use  for testing purposes, compiling code and so on. On this VM I have several DEs installed, and snapshots with moksha and several versison of e compiled. Using LXDE on this VM , pcmanfm works fine with no menu-cache issue at all. Logging out and logging into Moksha or enlightenment any version and we have the menu-cache issue with pcmanfm. I am unsure why the command /usr/lib/menu-cache/menu-cached works if called in a terminal but seemingly doesn't work (hangs as above) if called by a gui-process like pcmanfm in enlightenment. 
 
I am unsure why so I can't say for sure this is an issue with the LXDE library or another weirdness with enlightenment. I have not attempted to debug it and am reluctant to do so.
 

 

 

I am in the midst of a hurricane here but despite my reluctance to debug this issue I am a little OCD and have made some limited progress. 

 

Using git bisect I have identified the specific git commit which seems responsible. The efl commit efl_net_socket_fd: initialize fds to INVALID_SOCKET is the one that breaks pcmanfm functionality resulting in this menu-cache issue observed here. If I take efl 1.19.1 and undo this patch then pcmanfm works as expected. 

 

But all is evidently not completely well because if I insert the menu-cached command in a desktop file and place in Bodhi's menu as either:

Exec=/usr/lib/menu-cache/menu-cached

or

Exec=/usr/lib/menu-cache/menu-cached /tmp/.menu-cached-:0-USER

where in the latter USER is the users name in Bodhi, then we still have the menu-cache issue when this menu item is started unless we add

Terminal=true

to the desktop command. In other words the menu-cached command only works when started from a terminal :(

 

However If I go back to the previous commit and compile efl at commit elput: Fix resource leak then both pcmanfm as well as the menu-cache menu item work as expected. In other words some latter commit is the one breaking the menu-cache menu item. That one I haven't tried git bisect on. (That process took most of yesterday for me to go thru due to the length of time for efl to compile). [EDIT: I am wrong here see my comment latter.]

 

Even tho efl certainly seems to cause this issue I do not know enough about the underlying code base, the efl socket stuff and the menu-cache code, to say for sure this issue is caused by efl doing something 'wrong' or whether it is an issue with menu-cache.

 

When I know more such as what commit is causing the menu-cache item when started from Bodhi's menu, I will report this issue to the e-devs and if i feel it is a problem with the way the menu-cache library is coded then I will also report  this issue to the LXDE devs. And as soon as I have a seemingly completely working efl 1.19.1 I will place the updated deb files in Bodhi's testing repo. In all likelihood I will do this before the e-devs officially patch this issue. When and if there is an 'official' e-dev solution I will either back port their changes to efl 1.19.1 and or build deb files for the latest version of efl.


"No technology can ever be too arcane or complicated for the black t-shirt crowd."





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users