Hello.

I've been at this now for hours, and it is driving me nuts! I'm still not well acquainted yet with systemd. I'm trying to do, what in my mind, should be a very simple thing: to run a script at startup. A really easy one-liner.

This script has to run as root, and I want it to execute during the boot sequence -- I don't really care when, just sometime during boot.

I've tried doing this via crontab using the @reboot option -- but it doesn't work. The system just seems to ignore it. I've tried a zillion different .service files, and set them to execute at boot -- but again, it seems to ignore it. I run the same exact script after boot, and it executes just fine. I even start the .service file after boot, and it executes fine. It just doesn't want to do it at boot.

Here is my script:

Code: Select all

#!/bin/bash
/usr/bin/cpupower frequency-set -g performance


Here is my latest .service file (located in /etc/systemd/system):

Code: Select all

[Unit]
Description=Set CPU to performance
After=sddm.service

[Service]
Type=simple
ExecStart=/etc/.scripts/cpufix.sh
Restart=on-failure
RestartSec=10
KillMode=process

[Install]
WantedBy=multi-user.target


I then enable it: systemctl enable cpufix.service

Then:

Code: Select all

# systemctl list-unit-files |grep enabled |grep -i cpu
cpufix.service

What am I missing here? Why won't this execute at boot, and yet execute just fine once booted from the command line?

I appreciate the help!

Thanks.

G

Moved, as this is not KDE specific.

Hi!

Perhaps the script runs (use /usr/bin/logger to create debug entries) but the option will be overwritten by the kernel/another unit. As the performance is dynamically adapted, you should consider changing the default governor. See Kernel.org:CPU Governors for details and accept that your hardwares life will be shorter.

koffeinfriedhof wrote:Perhaps the script runs (use /usr/bin/logger to create debug entries) but the option will be overwritten by the kernel/another unit.

I have created some logging for the script, and I do see that it is applied... so something else in the boot sequence must be setting it back afterwards (just like you suggested)-- I'm not having any luck finding what that is.

I read the page you mentioned, and while it is good information, it doesn't really have any good advice on where set this. I have seen people echoing it right into their sys subdir (echo performance > /sys/devices/system/cpu/cpux/cpufreq/scaling_governor), which is fine, but still puts me in the same situation, since it needs to be done as root. I also saw that Arch has a systemd unit specifically for this sort of thing, and I tried to swipe theirs, but the end result was the same when applied to Neon.

koffeinfriedhof wrote:Perhaps the script runs (use /usr/bin/logger to create debug entries) but the option will be overwritten by the kernel/another unit. As the performance is dynamically adapted, you should consider changing the default governor. See Kernel.org:CPU Governors for details and accept that your hardwares life will be shorter.

If it shortens my hardware's life, then so be it. This tweak is not optional for an audio workstation. It has to be set to performance or I will be so steeped in xruns as to make the system useless for its intended purpose.

Since it seems like my script runs, but it is being subsequently stomped, perhaps there is a way to force it to run dead-last? I'm still not that comfortable with systemd yet... I've been using gentoo for a long time now, and it still defaults to init scripts (though you can use systemd if you elect to do so). So, I used to be able to add something like this to rc.local. (incidentally, that is why I posted this under neon, rather than linux in general, since not all linux distros use systemd, but neon does).

Is there an equivalent to rc.local? Or a better way of doing this altogether?

Thanks.

G

There was a package called cpufreq-utils to not have to manually change the /sys/-stuff, but I do not know if it still works on a systemd-platform. See e.g. ThinkWiki: How to use cpufrequtils. The package seems still available in Ubuntu focal: UbuntuPackages:focal:cpufrequtils

A better approach to not run in xruns is to either use a realtime-kernel or to properly setup the jackd. It depends on the amount of audiotracks that are recorded at once. Since about Ubuntu Studio 12.04 I stopped using a RTK as the default kernel was always fast enough to record up to 4 ( 3 wave-tracks and midi ) lines at once without xruns. As I do not have a debian base distro installed natively, I cannot check how progress was going on there, but have a look at KXStudio which has repositories for Ubuntu/Debian that provide a lot of audio tools and an easier setup.

As a general hint for systemd: If you need something to run as a dependency of another unit, check the WantedBy and After options in the configuration file. I think this will not work in this case, as cpu scaling is done dynamically.
You could also use a systemd timer unit to start a script 2 Minutes after boot and checking the state every 10 minutes or so.

koffeinfriedhof wrote:There was a package called cpufreq-utils to not have to manually change the /sys/-stuff, but I do not know if it still works on a systemd-platform. See e.g. ThinkWiki: How to use cpufrequtils. The package seems still available in Ubuntu focal: UbuntuPackages:focal:cpufrequtils

That is very cool... but would also require root permissions, which would put me in the same predicament... but I'm definitely filing that one away.

koffeinfriedhof wrote:A better approach to not run in xruns is to either use a realtime-kernel or to properly setup the jackd. It depends on the amount of audiotracks that are recorded at once. Since about Ubuntu Studio 12.04 I stopped using a RTK as the default kernel was always fast enough to record up to 4 ( 3 wave-tracks and midi ) lines at once without xruns. As I do not have a debian base distro installed natively, I cannot check how progress was going on there, but have a look at KXStudio which has repositories for Ubuntu/Debian that provide a lot of audio tools and an easier setup.

I am using the low-latency kernel. I have not been successful in finding out if "low-latency" and "real-time" (with regards to kernel builds) are different, or synonymous. I do know that there is no build in the standard apt sources, or in KX studio for a "real-time" kernel. The suggestion is to use the low-latency one. Both carla and the realtime perl scripts (mentioned on the ardour wiki) report that this is sufficient... but If there is a difference, and a repository I can use, I'd try another build.

I have spent quite a bit of time testing different Jack settings, and I'm confident it those are optimal given the current limits of my system configuration. The only question that remains for me is : Is there any more system tweaking that needs to be done that the realtime perl scripts do not check for? I'm at 10.7ms... with nothing but guitarix running (and Jack, of course). I dont know how good or bad that is. I was hoping to be single digits. Perhaps that is unrealistic... but my hardware is pretty good...

koffeinfriedhof wrote:You could also use a systemd timer unit to start a script 2 Minutes after boot and checking the state every 10 minutes or so.

That sounds like a great idea. I'll look into that. The other thing that occurred to me is that I might be able to create a sudo for that specific command to run without a password, then add it to that user's bashrc. Since I'm the only one using the system, it isn't much of a risk... I like your idea better though, I'll try that first.

Thanks.

grooveman wrote:Is there any more system tweaking that needs to be done that the realtime perl scripts do not check for?

Your 10ms are good enough I think, but I didn't write down the msecs in my notes. It is better to have a higher latency without xruns though. You could check if there is a process consuming more CPU than expected using top/htop. My external sound device is currently not connected, so I cannot check my settings directly, but I do remember that I had troubles setting up the pulseaudio-jack-port. For debugging you could try to use alsa only. I have a third user account for such things, using DWM as window manager with a clean config and disabled pulseaudio (which is a systemd --user unit), but including timidity resulting in

Code: Select all

/usr/bin/jackd -dalsa -dhw:PCH,0 -r48000 -p1024 -n2 -Xraw -D -Chw:Omega
# X = MIDI, raw | Omega is the external sound interface | PCH the internal four audio output

[/code]