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

Reply via email to