my Dell laptop is subject to this bug with kernel 3.14. As a workaround I wrote a simple script



echo 0 > /sys/class/backlight/intel_backlight/brightnes

(and made executable: chmod +x /usr/bin/brightness-fix)

and a systemd service calling it that is executed at startup:


Description=Fixes intel backlight control with Kernel 3.14



and enabled: systemctl enable /etc/systemd/system/brightness-fix.service

That works like a charm and I can control my display brightness as wanted. The problem comes when the laptop resumes after going to sleep mode (e.g. when closing the laptop lip): brightness control doesn't work anymore unless I manually execute my fisrt script above: /usr/bin/brightness-fix

How can I create another systemd service like mine above to be executed at resume time?

EDIT: According to comments below I have modified my brightness-fix.service like this:

Description=Fixes intel backlight control with Kernel 3.14


WantedBy=multi-user.target sleep.target

also I have added echo "$1 $2" > /home/luca/br.log to my script to check whether it is actually executed. The script it is actually executed also at resume (post suspend) but it has no effect (backlit is 100% and cannot be changed). I also tried logging $DISPLAY and $USER and, at resume time, they are empty. So my guess is that the script is executed too early when waking up from sleep. Any hint?

| improve this question | | | | |
  • 2
    WantedBy=sleep.target... – jasonwryan Apr 11 '14 at 6:37
  • Really?! Is that so simple?! :) Can I add 'sleep.target' to my script above or shall I create a new dedicated systemd service script for it? – lviggiani Apr 11 '14 at 6:41
  • ...according to documentation "This option may be used more than once, or a space-separated list of unit names may be given". I'm gonna try now. – lviggiani Apr 11 '14 at 6:44
  • you must add it to your existing systemd service file (which, by the way, is not a script; it's a static configuration file). and as a side note, the Filesystem Hierarchy Standard states that the proper place to put scripts you wrote yourself is /usr/local/bin, not /usr/bin. that directory is reserved for the package manager only. – strugee Apr 11 '14 at 6:45
  • 2
    I believe using the sleep.target will run the unit when the computer sleeps, rather than when it resumes. See my answer below for a unit file that worked for me with a similar problem. – jat255 Sep 3 '15 at 15:09

I know this is an old question, but the following unit file worked for me to run a script upon resume from sleep:

Description=<your description>

ExecStart=<your script here>


I believe it is the After=suspend.target that makes it run on resume, rather than when the computer goes to sleep.

| improve this answer | | | | |
  • 5
    Works with After=suspend.target in Unit and WantedBy=multi-user.target sleep.target in Install. – Emmanuel May 10 '16 at 17:40
  • I'm using the following units successfully here on Ubuntu 16.04 (elementary Loki). – Naftuli Kay Dec 22 '17 at 2:51
  • @Emmanuel I don't understand why the WantedBy parameter is not enough. Once I click on the power button to resume the computer, am I not back inside the multi-user.target ? Can you please explain the WantedBy parameter because the man systemd.unit is not clear to me ? – SebMa Feb 28 at 13:36

As an alternative to writing and enabling a unit file, you can also put a shell script (or a symlink to your script) into /lib/systemd/system-sleep/.

It will be called before sleep/hibernate, and at resume time.

From man systemd-suspend.service :

Immediately before entering system suspend and/or hibernation systemd-suspend.service (and the other mentioned units, respectively) will run all executables in /usr/lib/systemd/system-sleep/ and pass two arguments to them. The first argument will be "pre", the second either "suspend", "hibernate", or "hybrid-sleep" depending on the chosen action. Immediately after leaving system suspend and/or hibernation the same executables are run, but the first argument is now "post". All executables in this directory are executed in parallel, and execution of the action is not continued until all executables have finished.

Test it with this:

## This file (or a link to it) must be in /lib/systemd/system-sleep/

logger -t "test" "\$0=$0, \$1=$1, \$2=$2"
| improve this answer | | | | |
  • The man page you link mentions a file placed in /usr/lib but all your examples refer to files under /lib – qdii Sep 7 '17 at 23:54
  • @qdii : it may depend on the distribution and/or version. In Debian 8 Jessie and Ubuntu 16.04, the system-sleep directory appears to be in /lib/systemd/, and /usr/lib/systemd contains other stuff. – mivk Sep 9 '17 at 10:11

Followup to mivk's answer, in which I avoid mucking with a new unit file (see my question here How to react to laptop lid events?). Here's my solution; it's not 100% straightforward (sigh) because the system is not stable when it's coming out of sleep:

On my Fedora 26 box I put a symlink here: /usr/lib/systemd/system-sleep/sleepyhead which points here: /root/bin/sleepyhead, which contains:

## This file (or a link to it) must be in /lib/systemd/system-sleep/

# This is called when the lid is closed, as follows:
# $0=/usr/lib/systemd/system-sleep/sleepyhead, $1=pre, $2=suspend
# ...and when the lid is opened, as follows:
# $0=/usr/lib/systemd/system-sleep/sleepyhead, $1=post, $2=suspend

touch /tmp/sleepyrun
logger -t "sleepyhead" "Start: \$1=$1, \$2=$2"
if [ "$1" = "post" ] ; then
    action="RUN trackpoint in background"
    bash /root/bin/trackpoint >/tmp/trackpoint-run 2>&1
    action="NO ACTION"
logger -t "sleepyhead" "${action}: " "\$1=$1, \$2=$2"

The /root/bin/trackpoint script follows. Note that the first sleep is critical. The device is set up every time the lid is opened, so it doesn't exist at first. If I try to do anything but sleep, the "sleepyhead" script takes a really long time to exit and my pointer will be frozen for at least 60 seconds. Furthermore, note that you cannot put the /root/bin/trackpoint script in the background in sleepyhead, above. If you do, the process will be killed when sleepyhead exits.

# This is /root/bin/trackpoint

echo "Start $0"

# dirlist can look like:
# /sys/devices/platform/i8042/serio1/serio25/speed
# /sys/devices/platform/i8042/serio1/serio24/speed
# ...the older one appears to get cleaned a little later.

sleep 1 # If I don't put this in here, my pointer locks up for a really long time...
for i in 1 2 3 4; do
    speedfiles=$(find /sys/devices/platform/i8042 -name speed) # There may be multiple speed files at this point.
    [ -z "$speedfiles" ] && { sleep 1; continue; }
    dirlist=$(dirname $speedfiles)
    printf "Speed file(s) at $(find /sys/devices/platform/i8042 -name speed | tail -1) \n"
    # All this remaking of the path is here because the filenames change with
    # every resume, and what's bigger: 9 or 10? ...Depends if you're
    # lexicographical or numerical. We need to always be numerical.
    largest_number="$(echo $dirlist | tr ' ' '\n' | sed -e 's/.*serio//' | sort -n | tail -1)"
    dir="$(echo $dirlist | tr ' ' '\n' | egrep serio${largest_number}\$ )"
    echo "Dir is $dir number is $largest_number" 
    [ -n "$dir" ] && found=true && break
$found || exit 1

echo -n 4 > $dir/inertia
echo -n 220 > $dir/sensitivity
echo -n 128 > $dir/speed
echo "Done $0"
| improve this answer | | | | |
  • Very nicely organized and documented. I'd give you multiple up votes if I could! – MountainX Dec 23 '18 at 17:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.