Systemd suspend/resume service files

firecat53 · 2012-10-28 22:34:12

I created four different systemd service files to accomplish some pre-suspend and post-resume tasks. It seems to be working (finally!! A lot of trial and error involved here), but I was wondering if anyone has any suggestions for improving/simplifying these, or perhaps a different way of accomplishing these tasks. I'd like to add something coherent to the wiki so people who are interested can more easily start moving away from /etc/acpi/handler.sh for their suspend/resume needs.

Thanks!
Scott

1. As user: Kill any ongoing unison process, stop the music, and stop the mysql slave before suspending

local-user-user-suspend.service
[Unit]
Description=User suspend actions
Before=sleep.target
Wants=local-system-suspend.service
Before=local-system-suspend.service

[Service]
User=firecat53
Type=forking
Environment=DISPLAY=:0
ExecStartPre= -/usr/bin/pkill -u %u unison ; /home/firecat53/.local/bin/music.sh stop ; /usr/bin/mysql -e 'slave stop'
ExecStart=/usr/bin/sflock

[Install]
WantedBy=sleep.target

2. As root: Kill all sshfs processes before suspending

local-system-suspend.service
[Unit]
Description=Local system suspend actions
Before=sleep.target

[Service]
Type=simple
ExecStart=-/usr/bin/pkill -9 sshfs

[Install]
WantedBy=sleep.target

3. As user: Reconnect ssh tunnels/restart autossh and restart mysql slave after resuming from suspend

local-user-resume.service
[Unit]
Description=User resume actions
After=suspend.target
Wants=local-system-resume.service
Before=local-system-resume.service

[Service]
User=firecat53
Type=simple
ExecStartPre=/home/firecat53/.local/bin/ssh-connect.sh
ExecStart=/usr/bin/mysql -e 'slave start'

[Install]
WantedBy=suspend.target

4. As root: Restart my sshfs automount (because otherwise it gets 'stuck')

local-system-resume.service
[Unit]
Description=Local system resume actions
After=suspend.target

[Service]
Type=simple
ExecStart=/usr/bin/systemctl restart mnt-media.automount

[Install]
WantedBy=suspend.target

Last edited by firecat53 (2012-10-28 22:35:49)

jakob · 2012-10-29 23:35:14

Hey, nice idea!

I started putting some things into a file sleep.sh in /usr/lib/systemd/system-sleep doing the following:
1) mute alsa
2) save and restore hwclock
3) lock (not sure whether I should use a service file for that or simply put it there, thus commented

#!/bin/bash
if [ "$1" = "pre" ]; then
       /usr/bin/amixer set Master mute
       /sbin/hwclock --systohc
#       /usr/bin/xtrlock &
fi

if [ "$1" = "post" ]; then
	/sbin/hwclock --hctosys
fi

firecat53 · 2012-10-30 22:17:02

I specifically wanted to stay away from putting files in /usr/lib/systemd/system-sleep because

1. /usr/lib is not a normally good place to put user-customized files
2. Because of this statement in man systemd-sleep:

Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should
       be considered hacks. If applications want to be notified of system suspend and resume there are much nicer
       interfaces available.

I'm hoping that the "nicer interfaces" includes creating service .files!

Does anyone use service files like these for systemd suspend/resume actions?

Thanks,
Scott

jakob · 2012-10-31 00:13:03

firecat53 wrote:

I specifically wanted to stay away from putting files in /usr/lib/systemd/system-sleep because
1. /usr/lib is not a normally good place to put user-customized files
2. Because of this statement in man systemd-sleep:
Note that scripts or binaries dropped in /usr/lib/systemd/system-sleep/ are intended for local use only and should
       be considered hacks. If applications want to be notified of system suspend and resume there are much nicer
       interfaces available.
I'm hoping that the "nicer interfaces" includes creating service .files!
Does anyone use service files like these for systemd suspend/resume actions?
Thanks,
Scott

You're probably right by doing so! However, I consider the things I do in my sleep.sh hackish and to be applied only locally. As a service woul be an almost equal amont of lines with slightly more to think about, I'm right now just to lazy to change it, but it's probably the nicer interface.

I use this to lock my screen: (Idea gleaned from here)

[Unit]
Description=Lock X session using xtrlock

[Service]
User=jakob
Environment=DISPLAY=:0
ExecStart=/usr/bin/xtrlock

[Install]
WantedBy=sleep.target

Best, J

tomk · 2012-10-31 00:40:49

Yes, the nicer interfaces are systemd units tied to sleep.target.

I use just one, to lock my screen on resume with i3lock.

vostok4 · 2012-11-01 03:31:35

Hm, thanks for this post but its still getting stuck over here.

Does anything down there look amiss?

[Unit]
Description=User resume actions
After=sleep.target

[Service]
User=matt
Type=simple
Environment=DISPLAY=:0
ExecStartPre=xset -b
ExecStart=xmodmap -e 'clear Lock' -e 'keycode 0x42 = Super_L'

[Install]
WantedBy=sleep.target

WonderWoofy · 2012-11-01 03:34:17

Does your xmodmap actually get reset after sleep? For that matter does the bell get reset after sleep? Because mine definitely does not...

In any case, I think the type you want is oneshot not simple.

vostok4 · 2012-11-01 03:49:36

Yes, both bell and xmodmap get reset after sleep (and since I remap my meta key in Awesome, this is increasingly frustrating). I'll try oneshot.

Also, is the proper way of reloading the service after editing still: systemctl daemon-reload ?

--edit-- no dice with oneshot.

Last edited by vostok4 (2012-11-01 03:51:30)

WonderWoofy · 2012-11-01 03:53:38

Why don't you simply put a script in /usr/lib/systemd/system-sleep ? See the man page, as it is super super easy to make something work. It basically runs the script with pre|post sleep|hibernate, so you can set things to run before or after sleep and before or after hibernate.

vostok4 · 2012-11-01 04:01:05

As both the manpage and earlier on this page note, putting stuff in /usr/lib/systemd/... is a hackish solution and there are cleaner methods. I don't there's a guarantee your stuff won't be overwritten in in the /usr/lib folder.

Moreover, if I've spent all this time coming to systemd, you better damn believe I'm going to try and do it the right way Copping out now... I might as well have stayed on sysvinit I'll do it as my last resort, but for now, its something to play with.

WonderWoofy · 2012-11-01 04:08:23

It will certainly not be overwritten by anything, as that rule applies for files that are owned by the package. Hence, you edit service files in /etc rather than /usr/lib.

Personally I don't have a use for that function, but I think about it this way: when we were all using sysvinit and therefore pm-utils, this is exactly what pm-utils was doing to save/restore all kinds of things. I am not saying that you shouldn't continue to pursue the service file, but if there is a way to implement it now instead of waiting for success, why not? Also, the rc.local stuff i sysvinit was definitely a hack, yet we all did that as well. It was convenient and functional, and served its purpose until we found the better way (or didn't).

vostok4 · 2012-11-01 04:16:41

Hey, I'm very much so in the favour of sysvinit, and I agree that I should chase the easier solution right now, and trust me, I want to.

But, I want to get this to work, if its possible. There's some measure of fuzziness that gets given to me when I do things "the right way", which with systemd seems to be the roundabout way

WonderWoofy · 2012-11-01 04:23:27

Well in any case you should probably start a new thread so that your issues get attention on their own. Don't forget to post any error output, logs, etc. that you may think is relevent. I think start with systemctl status after trying to run the thing and see what it gives you.

firecat53 · 2012-11-01 16:20:47

vostok4 wrote:

Hm, thanks for this post but its still getting stuck over here.
Does anything down there look amiss?
[Unit]
Description=User resume actions
After=sleep.target

[Service]
User=matt
Type=simple
Environment=DISPLAY=:0
ExecStartPre=xset -b
ExecStart=xmodmap -e 'clear Lock' -e 'keycode 0x42 = Super_L'

[Install]
WantedBy=sleep.target

Try changing sleep.target to suspend.target. And make sure you DISPLAY is correct...I had mine set wrong for a short time. Don't forget to check journalctl and your systemctl status if something doesn't work.

Scott

jakob · 2012-11-01 21:28:46

Hey, how would you guys include the "post suspend|hibernate" (to hacks in /usr/lib/systemd/system-sleep) equivalent into a service file?

WonderWoofy · 2012-11-01 21:40:48

@jakob, what exactly are you asking? That is what this thread has been all about. I am not sure I understand...

jakob · 2012-11-01 21:50:41

Oh pardon! I confused two threads! I'm sorry! I didn't see the “After=suspend.target“ services. Will try them immediately to see if this works for me!

Last edited by jakob (2012-11-01 21:53:09)

vostok4 · 2012-11-01 22:38:37

firecat53 wrote:

Try changing sleep.target to suspend.target. And make sure you DISPLAY is correct...I had mine set wrong for a short time. Don't forget to check journalctl and your systemctl status if something doesn't work.
Scott

Yeah, I tried that afterwards. I'll check on the DISPLAY, maybe that's it. I've been using :0 forever and it seems to work :S I'll poke around more at home.

jakob · 2012-11-02 00:33:42

Ok, additionally to the locker script posted above, I'm now using this as

pre-sleep.service

[Unit]
Description=Prepare System Sleep

[Service]
Type=oneshot
ExecStart=/usr/bin/amixer set Master mute
ExecStart=/usr/bin/mpc pause
ExecStart=/sbin/hwclock --systohc

[Install]
WantedBy=sleep.target

post-sleep.service

[Unit]
Description=Finish System Sleep
After=sleep.target

[Service]
Type=oneshot
Environment=DISPLAY=:0
ExecStart=/sbin/hwclock --hctosys

[Install]
WantedBy=suspend.target

And it works fine.

ayonix · 2012-11-08 11:29:36

The solution you posted doesn't work for me. (I reenabled the service already)

         i3lock.service - i3lock
	 Loaded: loaded (/usr/lib/systemd/system/i3lock.service; enabled)
	 Active: failed (Result: exit-code) since Thu, 2012-11-08 12:22:36 CET; 14s ago
	 Process: 22484 ExecStart=/usr/bin/i3lock (code=exited, status=1/FAILURE)
	 CGroup: name=systemd:/system/i3lock.service

systemd[1]: Starting i3lock...
i3lock[22484]: No protocol specified
i3lock[22484]: i3lock: Could not connect to X11, maybe you need to set DISPLAY?
systemd[1]: Failed to start i3lock.
systemd[1]: Unit i3lock.service entered failed state

w returns:

USER     TTY        LOGIN@   IDLE   JCPU   PCPU WHAT
user       :0        11:19   ?xdm?  12:07   0.06s gdm-session-worker [pam/gdm-password]

cat /usr/lib/systemd/system/i3lock.service

[Unit]
Description=i3lock
Before=sleep.target

[Service]
User=myusername
Type=forking
Environment=DISPLAY=:0
ExecStart=/usr/bin/i3lock

[Install]
WantedBy=sleep.target

Have you got any idea why?

firecat53 · 2012-11-08 15:14:12

Make sure your DISPLAY is actually :0 . Sometimes (depending on how you login to X) you might be on a different VT.

Scott

ayonix · 2012-11-08 16:33:47

I changed from gdm to lxdm and now it works, I'm not sure if that was the problem though...

root · 2012-11-16 00:52:01

So if I understand correctly if I want to restore my sound with ALSA (which I previously muted) I have to create 4 unit files, that is, 2 for sleep (before/mute and after/unmute) and 2 for suspend (before/mute and after/unmute). Correct?

firecat53 · 2012-11-16 04:52:27

Not necessarily -- I had to set up 4 files because I have both user and root actions to accomplish on suspend and resume. If you just have user OR root actions, you should just need one service file for suspend and one for resume.

You can execute multiple commands from one file by utilizing ExecStart and ExecStartPre. Unless the type is oneshot, you can only have one ExecStart command. For ExecStartPre (see man systemd.service for details) you can execute multiple commands by having them separated by a ; like:

ExecStartPre= -/usr/bin/pkill -u %u unison ; /home/firecat53/.local/bin/music.sh stop ; /usr/bin/mysql -e 'slave stop'

Don't forget the spaces around the ; ! You can see my full example files at the top of the thread.

Hope that answers your question...

Scott

root · 2012-11-18 01:07:37

Your example files firecat53 and those of jakob were really helpful. Thank you.

After some tests I realized that according to the journal in both cases, suspend and hibernation, apparently the same sleep unit is used and therefore my file count is down to 3, one for sleep (before), one for suspend (after) and the final one for hibernate (after).
I have noticed double reference to the units in the journal log though, one right after another. Someone knows what the reason for this may be?

Here are the files I have set up, to share and to ask for suitable improvements

alsa-sleep.service

[Unit]
Description=Muting ALSA prior to sleep
Before=sleep.target

[Service]
Type=oneshot
ExecStart=/usr/bin/amixer set Master mute
ExecStart=/usr/bin/amixer set PCM mute
ExecStart=/usr/bin/amixer set CD mute

[Install]
WantedBy=sleep.target

alsa-wake.service

[Unit]
Description=Unmuting ALSA after sleep
After=suspend.target

[Service]
Type=oneshot
ExecStart=/usr/bin/amixer set Master unmute
ExecStart=/usr/bin/amixer set PCM unmute
ExecStart=/usr/bin/amixer set CD unmute

[Install]
WantedBy=suspend.target

alsa-resume.service

[Unit]
Description=Unmuting ALSA after suspension
After=hibernate.target

[Service]
Type=oneshot
ExecStart=/usr/bin/amixer set Master unmute
ExecStart=/usr/bin/amixer set PCM unmute
ExecStart=/usr/bin/amixer set CD unmute

[Install]
WantedBy=hibernate.target

Arch Linux

#1 2012-10-28 22:34:12

Systemd suspend/resume service files

#2 2012-10-29 23:35:14

Re: Systemd suspend/resume service files

#3 2012-10-30 22:17:02

Re: Systemd suspend/resume service files

#4 2012-10-31 00:13:03

Re: Systemd suspend/resume service files

#5 2012-10-31 00:40:49

Re: Systemd suspend/resume service files

#6 2012-11-01 03:31:35

Re: Systemd suspend/resume service files

#7 2012-11-01 03:34:17

Re: Systemd suspend/resume service files

#8 2012-11-01 03:49:36

Re: Systemd suspend/resume service files

#9 2012-11-01 03:53:38

Re: Systemd suspend/resume service files

#10 2012-11-01 04:01:05

Re: Systemd suspend/resume service files

#11 2012-11-01 04:08:23

Re: Systemd suspend/resume service files

#12 2012-11-01 04:16:41

Re: Systemd suspend/resume service files

#13 2012-11-01 04:23:27

Re: Systemd suspend/resume service files

#14 2012-11-01 16:20:47

Re: Systemd suspend/resume service files

#15 2012-11-01 21:28:46

Re: Systemd suspend/resume service files

#16 2012-11-01 21:40:48

Re: Systemd suspend/resume service files

#17 2012-11-01 21:50:41

Re: Systemd suspend/resume service files

#18 2012-11-01 22:38:37

Re: Systemd suspend/resume service files

#19 2012-11-02 00:33:42

Re: Systemd suspend/resume service files

#20 2012-11-08 11:29:36

Re: Systemd suspend/resume service files

#21 2012-11-08 15:14:12

Re: Systemd suspend/resume service files

#22 2012-11-08 16:33:47

Re: Systemd suspend/resume service files

#23 2012-11-16 00:52:01

Re: Systemd suspend/resume service files

#24 2012-11-16 04:52:27

Re: Systemd suspend/resume service files

#25 2012-11-18 01:07:37

Re: Systemd suspend/resume service files

Board footer