Comment # 17 on bug 917221 from John Leys

(In reply to Takashi Iwai from comment #16)
> (In reply to John Leys from comment #15)
> > I noticed that a few things in the pm-hibernate execution path and the
> > 'systemctl hibernate' execution path were duplicative, e.g. 'grub-once',
> > which likely needs to be addressed.  It seems that the new hibernation
> > strategy implementation, i.e using systemd, did not adequately address
> > conflicts with the old hibernation strategy implemenation, i.e. using
> > pm-utils.
> 
> Well, the openSUSE 13.2 systemd has an integration of pm-utils by the own
> patch.  systemd invokes pm-utils stuff when it's found.  If not, systemd
> tries to write /sys/power/state.  In addition, systemd has its own hooks in
> /usr/lib/systemd/system-sleep/*.  This is usually empty as default, though.
>  
> > I tried various things:
> > 1. systemctl hibernate
> > 2. Removing all files in the /var/lib/pm-utils/sleep.d
> > (/etc/pm-utils/sleep.d was empty)
> > 3. Removal of the pm-utils package
> > 4. Revert to kernel 3.16.7-7-desktop (not OBS kernel) with no pm-utils
> > 
> > With 3 and 4 i only used 'systemctl hibernate' to effect hibernation.  Of
> > these both 3 and 4 are very successful, but 3 still has intermittent
> > problems.  With 3 the hibernation occasionally fails to power off the
> > machine at the end of the hibernation and occasionally fails to restore the
> > display on resume, though it successfully restores teh image.  With 4 the
> > process has not had any problems so far, though i have not tested this
> > configuration for a long period of time; i will update the bug if it appears
> > to still have problems.
> 
> 3 and 4 are effectively doing the kernel hibernation (/sys/power/state).
>  
> > With options 1 and 2 there was occasional success, but often failures of the
> > same kind as before, i.e. failue in the process of restoring the image.
> > 
> > I noticed that the pm-utils attempted to lock out concurrent hibernation by
> > using 'flock'; i wonder if teh systemd approach did the same thing.  While
> > executing grub-once is idempotent, other actions performed in the processing
> > of hibernation are not necessarily idempotent, so if there are 2 threads
> > performing the same processing, even successively, it could be problematic.
> > 
> > For now, the problem seems to be resolved by just removing the pm-utils
> > package, though YAST keeps on trying to re-install it whenever i go into the
> > software management dialog.  If i continue to have problems, i will update
> > the bug accordingly.
> 
> Could you try just to remove /usr/lib/pm-utils/sleep.d/99Zgrub?  If it's
> about pm-utils hooks, this one appears most suspicious.

Because of the problems with BTRFS and grub-once, removing 99Zgrub was one of
the first things that i did, even before filing this bug, and it was not
effective; i also effectively nulled the systemd grub-once and the problem
still occurred.  Also, as i pointed out, i tried with nothing in
/usr/lib/pm-utils/sleep.d and the problem still occurred.  But 99Zgrub only
targets a particular grub.cfg entry for use on the next startup, it does not
modify the hibernate image; hibernate image creation and modification occurs
after all of the sleep.d modules have been executed.