Trying to execute command at startup with systemd, not working

josherick · 2014-11-24 23:31:36

I'm having the issue described here where there is a runaway gpe something or other that needs to be disabled.

I can manually disable the gpe once booted and logged in by going

 sudo echo "disable" > /sys/firmware/acpi/interrupts/gpe66

and this seems to solve the problem. However, I'd like to have it automatically disabled at boot. The post I linked above is for Ubuntu and suggests using cron. I don't want to install cron, since I think systemd should work perfectly well for what I'm trying to do.

I looked on the systemd FAQ Arch Wiki article for how to execute a command at startup with systemd, and followed the instructions, creating a file at /etc/systemd/system/suppress-gpe66.service:

 [Unit]
Description=My script

[Service]
ExecStart=echo "disable" > /sys/firmware/acpi/interrupts/gpe66

[Install]
WantedBy=multi-user.target

and ran

systemctl enable suppress-gpe66.service

and rebooted.

After the computer rebooted, gpe66 was still going crazy. I thought it might be an issue with this specific command, so I changed the ExecStart line to

ExecStart=echo "hello" > /home/joshsherick/hello.txt

but still, after disabling/re-enabling the service and rebooting, there was no file created in my home directory.

Newbie here, is there anything obvious I'm doing incorrectly? Thanks.

TheSaint · 2014-11-25 00:20:08

FYI you don't need to reboot, just

# systemctl reload yourservice

Then you may trace the results in the journal

# journalctl -xn20 -u yourservice

Let us see what the journal got to say.

Trilby · 2014-11-25 01:00:46

you can't use redirection in an exec line. The contents of that line are passed to an exec-family function (man 3 exec), not to the shell. Redirection is a shell-dependent behavior.

You could put that line in a shell script, then call the script. EDIT: or I suppose something like the following would be easier:

ExecStart=/usr/bin/bash -c 'echo "something" > /path/to/somewhere'

A better idea might be to first check if you can access the variable with sysctl. The files in /sys/ are not on-disk file, but just representations of kernel variables. Sysctl allows you to set those variables directly which would save a call to a shell. EDIT: it seems these may not be accessible to sysctl.

Last edited by Trilby (2014-11-25 01:06:19)

TheSaint · 2014-11-25 02:27:02

It is to consider when /sys is ready to use. Maybe it should be at the multi-user.target or even earlier (I think). Anyhow should be good practice to put a Wants=multi-user.target in the service script.

oceans11 · 2014-11-25 20:37:31

You can give (man 8) systemd-tmpfiles a try. It's not the right solution though, since /sys is not guaranteed to be mounted when the tmpfile is sourced.

TheSaint · 2014-11-26 09:37:54

I thought this things. If the gpe66, is found into /proc then sysctl is tool to do the job without worry about /sys readiness.

AbsoluteZero · 2014-12-29 04:43:33

Just wanted to report that the following systemd service solved the runaway GPE66 issue on my MacBook Pro:

[Unit]
Description=Disables GPE 66, an interrupt that is going crazy on Macs

[Service]
ExecStart=/usr/bin/bash -c 'echo "disable" > /sys/firmware/acpi/interrupts/gpe66'

[Install]
WantedBy=multi-user.target

TheSaint · 2014-12-29 07:07:45

What could be the difference?

$ uname -r

Last edited by TheSaint (2014-12-29 07:07:59)

ayekat · 2014-12-31 16:28:54

I don't know whether this is applicable for your problem, but I've got a file /etc/sysctl.d/99-ip-forward.conf which contains:

# enable IP packet forwarding
net.ipv4.ip_forward = 1

So instead of fighting with systemd, try creating a sysctl configuration file containing

firmware.acpi.interrupts.gpe66 = disable

and test if that works (maybe alternatively 'disabled' or '0' - I don't know exactly what it's supposed to take as a value).

To me it seems cleaner to use configuration files provided by a program rather than changing the behaviour at runtime.

AbsoluteZero · 2014-12-31 17:11:09

ayekat wrote:

I don't know whether this is applicable for your problem, but I've got a file /etc/sysctl.d/99-ip-forward.conf which contains:
# enable IP packet forwarding
net.ipv4.ip_forward = 1
So instead of fighting with systemd, try creating a sysctl configuration file containing
firmware.acpi.interrupts.gpe66 = disable
and test if that works (maybe alternatively 'disabled' or '0' - I don't know exactly what it's supposed to take as a value).
To me it seems cleaner to use configuration files provided by a program rather than changing the behaviour at runtime.

Ah! This was exactly what I was looking for. I wholeheartedly agree that this is cleaner than a systemd task running a bash script. It completely avoids the assumption that the systemd script will run after /proc is mounted, and captures the semantics of what needs to happen.

I knew the correct solution had to involve sysctl.d, but I couldn't quite wrap my mind around the documentation. I'll get around to testing it later today and report back.

Thanks!

Drive · 2015-01-01 20:38:10

Systemd script worked also for me. Do not forget to chmod 755.

Arch Linux

#1 2014-11-24 23:31:36

Trying to execute command at startup with systemd, not working

#2 2014-11-25 00:20:08

Re: Trying to execute command at startup with systemd, not working

#3 2014-11-25 01:00:46

Re: Trying to execute command at startup with systemd, not working

#4 2014-11-25 02:27:02

Re: Trying to execute command at startup with systemd, not working

#5 2014-11-25 20:37:31

Re: Trying to execute command at startup with systemd, not working

#6 2014-11-26 09:37:54

Re: Trying to execute command at startup with systemd, not working

#7 2014-12-29 04:43:33

Re: Trying to execute command at startup with systemd, not working

#8 2014-12-29 07:07:45

Re: Trying to execute command at startup with systemd, not working

#9 2014-12-31 16:28:54

Re: Trying to execute command at startup with systemd, not working

#10 2014-12-31 17:11:09

Re: Trying to execute command at startup with systemd, not working

#11 2015-01-01 20:38:10

Re: Trying to execute command at startup with systemd, not working

Board footer