Indeed, that sounds like a solution. It's a bit of a philosophical thing though, remainafterexit+oneshot works nicely for things that represent a certain state (powersaving on) which can be inspected and turned off.
oneshot "scripts" don't feel natural to me somehow without such a state (which RemainAfterExit provides). But maybe I need to alter my view on services a bit. For now I will try your solution. Thanks On Wed, Aug 7, 2013 at 1:02 PM, Tom Gundersen <t...@jklm.no> wrote: > On Wed, Aug 7, 2013 at 10:12 AM, Mathijs Kwik <math...@bluescreen303.nl> > wrote: >> I have a few things that need to get run after waking up my laptop >> (things like hdparm to set device power options/spindown time). >> I created oneshot, remainafterexit services for those and made them >> wanted by multi-user.target.This works fine for the first boot. > > Are you sure you want RemainAfterExit? Without it you should be able > to set WantedBy=sleep.target and After=sleep.target. > >> As I consider these services "dead" after a suspend/hibernate, I added >> Conflicts=sleep.target, so now systemd is aware that these services >> are no longer active after a wakeup. >> >> Now I would like to somehow have these services restart on wakeup. >> I can add these services to some new target(wakeup.target), but I >> don't know how to proceed from there. I thought of making >> wakeup.target WantedBy suspend.target, After suspend.target, but since >> suspend.target pulls in sleep.target (which conflicts with these >> services) that will fail. More so, after wakeup.target is started the >> first time, it will never go down itself, so the second wakeup won't >> do anything. The same is true for multi-user.target, once that is >> reached/activated on first boot, it never deactivates until shutdown. >> >> How should a situation like this be handled? >> Ideally, I don't want to use: >> - /usr/lib/systemd/system-sleep (considered hacky) >> - a service/script that runs "systemctl start ..." (secret >> dependency, hidden from systemd) >> >> Thanks, >> Mathijs >> _______________________________________________ >> systemd-devel mailing list >> systemd-devel@lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/systemd-devel _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
