Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
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
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
up vote 3 down vote accepted

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.

share|improve this answer
Works with After=suspend.target in Unit and WantedBy=multi-user.target sleep.target in Install. – Emmanuel May 10 at 17:40

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

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