[Pm-utils] lockfile creation not really atomic in pm-utils

Victor Lowther victor.lowther at gmail.com
Tue Jan 8 20:01:38 PST 2008

On Jan 8, 2008 1:42 PM, Till Maas <opensource at till.name> wrote:
> On Fri January 4 2008, Victor Lowther wrote:
> > Or move the lock directory to a location that is (or should be
> > auto-cleaned), like /tmp, or just clean it ourselves with a boot-time
> > init script.
> An init script only to remove the lock directory, seems to be too much
> overkill to me.
> > Using PID values seems like a waste of time if you are using them to
> > detect stale lockfiles over reboots -- the presence or absence of a
> > given PID is meaningless in that case.
> The absence of a given PID always means that the lockdirectory is stale, but
> in case it is present after a reboot, there is a problem. What could help
> imho here, would be to store the last boot time[1] and then and compare it
> with a value that was stored in the lockdirectory. In case they do not match,
> then the lockdirectory is also stale.

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.

> > 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. :)

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.

> Regards,
> Till
> [1] This would be enough: LANG=C last -1 reboot | head -n1 | cut -d"(" -f1

More information about the Pm-utils mailing list