On Wed January 9 2008, Victor Lowther wrote: > What happens when your device either does not have a hardware clock or > the hardware clock has failed? The more complicated the mechanism to > detect and remove a stale lock directory, the more ways in which it > can fail, and the more mysterious those failures will be. > Unconditionally nuking the lock directory at boot time (or detecting > the lock directory, annoying the user with some scary verbiage, and > then unconditionally nuking the directory) is pretty much foolproof.
Hm, ok, I do not have any objections against the patch anymore. Only the need for cleaning up /.suspend manually in case of crashes / via an initscript should be documented in INSTALL imho. > > > If there is a case in which suspend/resume fails, the system does not > > > reboot (or hang and get rebooted), and the lock directory does not get > > > removed, then that is a fault in the pm-utils scripting that needs > > > fixed (imao). > > > > I agree here, but I do not know, whether this is currently the case or > > not. > > Sounds like time for a code audit. I will look into it over the > weekend and probably send a much larger patch. :) I am not the author of pm-utils, so my knowledge of this does not mean much. > Speaking of code audits, is there a reason that the scripts are bash > specific in places? I would think that strict POSIX sh compatibility > would be the way to go for these scripts -- makes using them in > embedded systems and the like easier. Do you have a good resource on how to convert bash features into POSIX compatible commands? I guess bash is used, because it makes lot of stuff easier. :-) Regards, Till
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Pm-utils mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/pm-utils
