Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ERROR: /etc/systemd/system/auto-cpufreq.service:9: Executable path is not absolute: auto-cpufreq --daemon #42

Closed
filippofontana opened this issue Mar 17, 2020 · 11 comments

Comments

@filippofontana
Copy link

Hi,
firstly thank you for this amazing tool for Linux, in the past days I used the previous version with any issues (except for the log freeze), today I saw the new update and I followed the new installation instructions.
With the new installer I encoutered this pip warning:

WARNING: The directory '/home/filip/.cache/pip' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.

After that the installation was completed and fine.
But when I give the sudo auto-cpufreq --install instruction and after that, I check the systemctl status auto-cpufreq I receive the error in the title:
/etc/systemd/system/auto-cpufreq.service:9: Executable path is not absolute: auto-cpufreq --daemon

My OS is Elementary 5.1.2 (based on Ubuntu 18.04 LTS)

Thank you in advance for your help!

@AdnanHodzic
Copy link
Owner

What happens if you run auto-cpufreq-installer?

I also released auto-cpufreq to Snap store which would definitely fix your problem. But as I stated for full functionality auto-cpufreq needs snapd version 2.4.4 which is currently only available in Ubuntu 20.04.

@filippofontana
Copy link
Author

I got this pip warning:

WARNING: The directory '/home/filip/.cache/pip' or its parent directory is not owned or is not writable by the current user. The cache has been disabled. Check the permissions and owner of that directory. If executing pip with sudo, you may want sudo's -H flag.

And after that, everything goes fine, but after the sudo auto-cpufreq --install command, I had the error stated in the previous message.
Maybe I will just wait the snapd 2.4.4 version.

@volnes
Copy link

volnes commented Mar 25, 2020

Well now i got same error with systemd daemon (daemon not starting):
image

@AdnanHodzic
Copy link
Owner

Since some changes were pushed in meantime. What happens if you do:

sudo auto-cpufreq --remove
sudo ./auto-cpufreq-installer --remove
sudo ./auto-cpufreq-installer --install

@volnes
Copy link

volnes commented Mar 25, 2020

sudo auto-cpufreq --remove
sudo ./auto-cpufreq-installer --remove
sudo ./auto-cpufreq-installer --install

Same error after reinstalling last version.

@AdnanHodzic
Copy link
Owner

What does whereis auto-cpufreq return and are you able to run i.e: auto-cpufreq --live

Does it make any difference if you run:

sudo su -
auto-cpufreq --remove
./auto-cpufreq-installer --remove
./auto-cpufreq-installer --install

@volnes
Copy link

volnes commented Mar 25, 2020

What does whereis auto-cpufreq

image

are you able to run i.e: auto-cpufreq --live

Weird but it works.

sudo su -
auto-cpufreq --remove
./auto-cpufreq-installer --remove
./auto-cpufreq-installer --install

No difference

@AdnanHodzic
Copy link
Owner

Right, so problem is that same path /usr/local/bin/auto-cpufreq for some weird reason isn't found in your case, when it's run by root user as part of the systemd service.

What I suggest you do as a workaround is:

after sudo auto-cpufreq --install

Run: sudo systemctl stop auto-cpufreq

Edit /etc/systemd/system/auto-cpufreq.service file with editor of your choice, i.e:

sudo vim /etc/systemd/system/auto-cpufreq.service

Change line 9:
ExecStart=auto-cpufreq --daemon to:
ExecStart=/usr/local/bin/auto-cpufreq --daemon

Followed by:

sudo systemctl daemon-reload
sudo systemctl start auto-cpufreq

auto-cpufreq daemon should be running now which you can verify by running: auto-cpufreq --log

@volnes
Copy link

volnes commented Mar 25, 2020

Thanks, systemd daemon now works fine!

@AdnanHodzic
Copy link
Owner

Great. I won't make any changes in code yet, as I want to see if anyone else has this problem and until then will leave this issue open.

@AdnanHodzic
Copy link
Owner

This problem has been permanently fixed as part of 1.1.2 release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants