[systemd-devel] Suspend does not work from a service

[Colin Guthrie]

Cecil Westerhof wrote on 19/03/16 23:54:
> 2016-03-18 17:16 GMT+01:00 Cecil Westerhof <cldwesterhof at gmail.com
> <mailto:cldwesterhof at gmail.com>>:
> 
>     I wrote as script to put my netbook into suspend when it is locked
>     for five minutes and not connected to the AC adapter:
>        
>     https://github.com/CecilWesterhof/BashLibrary/blob/master/bin/suspend.sh
> 
>     This works perfect when I start it from the command-line, but not
>     when I use it as a systemd service. Then I get:
>         Failed to start suspend.target: Access denied
>     when the
>         systemctl suspend || true
>     is executed.
> 
> 
> ​For what it is worth: normally ‘systemctl​
>  
> ​suspend’ returns 1, but from the systemd service it returns 4.​
> 
>  
> 
>     ​What could be happening here? And how do I solve it?
> 
>     My service file:
>     [Unit]
>     Description=Suspend machine when locked and no AC adaptor
> 
>     [Service]
>     Type=simple
>     ExecStart=/usr/local/bash/bin/suspend.sh
>     Restart=always
>     User=cecil
> 
>     [Install]
>     WantedBy=multi-user.target
>     ​
> 
>     ​On a related note​: why does:
>         systemctl suspend
>     give an exit status of 1?
>     And why does it returns immediately? I had to add a sleep 5 to my
>     script to make it work.

You're running the script as the user cecil (User=cecil).

I suspect the problem is not so much the fact that it's run as this user
(you can probably issue "systemctl suspend" when logged in as the user
right?

However when the screen is locked your user session is in a different
state and thus they do not have the same rights and privileges they did
previously when the session is unlocked. They may not be granted the
same permissions as when logged in and thus the permission checks
performed by systemctl when determining if they are allowed to suspend
the machine might fail when locked vs. unlocked.

You can test this easily by:

1. When logged in, run systemctl suspend as cecil in a terminal.
2. Confirm it works!
3. Repeat step 1 but prefix the command with "sleep 15;" and then lock
the screen.
4. Confirm that it breaks.

This will confirm it's not the fact it's run in a systemd unit that
breaks it, but the fact it's run while the screen is locked.

If this is to blame then you can write a policy kit rule for the suspend
operation that gives your user more rights.

That's my first thought (could be wrong!)

Col



-- 

Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/