Comment # 61 on bug 925873 from
(In reply to Cristian Rodr�guez from comment #60)
> (In reply to Takashi Iwai from comment #56)
> 
> > 02rtcwake:
> > This is an own RTC alarm setup.  Do we have an alternative in systemd or
> > else?
> 
> http://joeyh.name/blog/entry/a_programmable_alarm_clock_using_systemd/ -->
> WakeSystem= timer setting..

How to script this at hibernation time?

> > 06autofs:
> > The autofs hook should be in systemd.  I thought we have some hook in
> > NetworkManager, though.  Need to check.
> 
> Isn't this an autofs bug ? if it needs to be restarted after resume or does
> not respond.. maybe it misses an event ? a timer does not respond correctly
> ? is it using CLOCK_MONOTONIC where it should be using CLOCK_BOOTTIME ? is
> there a race condition ?

Well, we need to check what problem actually this has solved.  I vaguely
remember autofs issue in 11.x time, but haven't tracked since then.

> > 75modules:
> > This is an optional hook, and I guess some users have its own setup as a
> > workaround.  Any systemd alternative?
> 
> No, why would systemd have to unload kernel drivers before suspend ? this is
> to workaround buggy devices/drivers that do not come up correctly on system
> resume.. (usually devices that need reset-on-resume quirk afaik) Need to
> identify the buggy drivers ..

*We* as a distro need to provide a workaround until the kernel gets the fix.
Sure, you can blame kernel, but it's no excuse to ignore the breakage.  Show
must go on.  The system must keep working like before.

(And why systemd?  Because it ate others' cookies :)

> > 90clock:
> > This is also an optional hook.  This might be interesting to have in
> > systemd, too.
> 
> The top comment says:
> 
> "#!/bin/sh
> # Synchronize system time with hardware time.
> # Modern kernels handle this correctly so we skip this hook by default.
> "
> Yeah and if the kernel does not.. then there is a bug ..

True.


You are receiving this mail because: