Services failing

I had two services pointing to SH and BASH in /bin directory but those are at /usr/bin. Fixed it. Need some advice on which should I use SH or BASH for these scripts. I’m having fail errors.

The curious thing is that I wasn’t getting screen tearing so I wonder if that was fixed and maybe I don’t need the GPU-FIX service anymore. Or was it running anyways?

Can anyone tell me what’s wrong? And where do I look for logs to confirm I’m still failing after I tried to fix it.

echo "manual" > /sys/class/drm/card0/device/power_dpm_force_performance_level;
echo "2" > /sys/class/drm/card0/device/pp_dpm_mclk;

Also, a Logitech color cycle sync command.

g213-led -fx cycle all 20000ms && sudo g203-led cycle 20000;


Description=Fix VRAM artifacts with GPU energy saving



Description=Logitech led startup



There is nothing to fix:

$ ls -l /bin
lrwxrwxrwx 1 root root 7 26. Sep 14:06 /bin -> usr/bin

If you’re using bashisms you’d obviously need bash. The two examples you posted don’t use any - so it’s entirely possible to use sh.

What do those look like exactly? It’s difficult to give advice without seeing the exact error messages.

One thing comes to mind: you’ve marked the scripts as executable (set the x bit)?

$ chmod +x /usr/bin/gpu-fix /usr/bin/

Last: Those 2 handwritten scripts would better be located in /usr/local/bin/, see FHS.

Yeah the scripts were executables but the services weren’t and I check and the others were. So I set mine with chmod +x. The GPU service was running after that but I’ve been changing the led fix from plain led-fix to and back an forth. Disabling and enabling the service to make it catch the executable because it was complaining not found with systemctl status led-fix.service

So I moved it to the name it was looking for and that was it.

Will do that, TY for the tip

If the service file changes, one has to:

$ systemctl daemon-reload

Yeah TY,

The GPU service can be onshot but maybe I should make the Leds service like this:

Description=<description about this service>

ExecStart=<script which needs to be executed>



Probably not a good idea: this is no continously running program, which systemd should automatically restart, see

Nice Thank you very much for the link

Led-fix service failed again, I think I need to use autostart. I’m on KDE, should I run it a startup or before sessions startup if I want it to light up for login?

● led-fix.service - Logitech led startup
     Loaded: loaded (/etc/systemd/system/led-fix.service; enabled; vendor preset: disabled)
     Active: failed (Result: exit-code) since Sun 2020-10-11 06:22:04 AST; 4min 32s ago
    Process: 626 ExecStart=/usr/bin/led-fix (code=exited, status=2)
   Main PID: 626 (code=exited, status=2)

Oct 11 06:22:04 localhost systemd[1]: Starting Logitech led startup...
Oct 11 06:22:04 localhost led-fix[638]: Matching or compatible device not found !
Oct 11 06:22:04 localhost systemd[1]: led-fix.service: Main process exited, code=exited, status=2/INVALIDARGUMENT
Oct 11 06:22:04 localhost systemd[1]: led-fix.service: Failed with result 'exit-code'.
Oct 11 06:22:04 localhost systemd[1]: Failed to start Logitech led startup.

Looks like an error message from either g213-led or g203-led in that script:

g213-led -fx cycle all 20000ms && sudo g203-led cycle 20000

If those commands work despite the service failing it might be a race condition.
Waiting some time before issuing the commands can be a viable workaround in such cases:

sleep 30 && g213-led -fx cycle all 20000ms && sudo g203-led cycle 20000

5 seconds did the trick