lf file manager conflicting with linux compatibility layer - high cpu usage

Earlier last week I decided to switch my Thinkpad x220 from Windows 10 to FreeBSD 13.1-release. In the process of setting things up I found that the lf file manager is showing very high cpu usage when linux capability is enabled. I was able to replicate the issue on the x220 with a fresh install and doing the following after installation:

installing packages: vim htop tmux lf

Under tmux, I run htop and then in another split run lf. Browsing files in the main root folder (going up and down for about 20 seconds) does not cause high cpu load.

After installing the git package I clone https://github.com/mrclksr/linux-browser-installer.git
I then run the installer #./linux-browser-installer install chrome

Once installation is complete, I re-run tmux with htop and lf in split windows. After moving up and down on the main root folder in lf, the cpu usage for the lf process goes high (e.g. 298% at one point). Exiting lf causes the cpu to return back to a "normal" state.

Modifying /etc/rc.conf file to set ubuntu_enable="NO" (instead of yes), restarting the system, and re-running tmux/htop/lf does not cause high cpu usage. Issuing:
service ubuntu onestart and re-running lf tests causes high cpu usage again.

If I tried to manually stop the service by issuing service ubuntu stop or service ubuntu onestop it does not seem to have an effect on tmux/htop/lf test (it shows high cpu usage). I need to edit the rc.conf file (ubuntu_enable="NO") and restart the system for the cpu load to remain low (when running tmux/htop/lf tests).

I was also able to replicate this behaviour on a virtual machine (same FreeBSD 13.1-release) running on a MacBook Pro.

Would this be a bug with the lf file manager? Linux compatibility layer? or something else?
 
Back
Top