Bug 442178

Summary: cleanup /var/run/pm-utils/locks/* properly
Product: [Fedora] Fedora Reporter: Alex Lancaster <alex>
Component: initscriptsAssignee: Bill Nottingham <notting>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: rawhideCC: jonstanley, mschmidt, nphilipp, opensource, pknirsch, rhughes, richard, rvokal
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 8.70-1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-04-15 17:06:48 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
pm bug report output none

Description Alex Lancaster 2008-04-12 14:25:27 UTC
Description of problem:


Version-Release number of selected component (if applicable):
pm-utils-1.1.0-4.fc9.i386

How reproducible:
Always

Steps to Reproduce:
1. pm-hibernate

Actual results:
Nothing, prompt returns.   Nothing written to /var/log/pm-hibernate.log

Expected results:
Hibernation to start and machine shuts down.

Additional info:
This was working as far as I recall with the previous pm-utils.  I have also
switched to kernels that had hibernate/resume working and they no longer work
either, so it seems very likely that pm-utils is the culprit as it is the only
thing that has recently changed.

Comment 1 Alex Lancaster 2008-04-12 14:28:50 UTC
Also trying the gnome-power management applet or the "Shut Down" button and
selecting "Hibernate" has the same effect: no attempt at hibernation is made.

Comment 2 Alex Lancaster 2008-04-12 14:34:23 UTC
Seems it was only just recently updated to 1.1.0, a major release just before
the f9 freeze on April 8 2008:

http://koji.fedoraproject.org/koji/buildinfo?buildID=45548

Is it possible this may have introduced regressions with respect to the way
suspend/hibernation is setup in Fedora?

Comment 3 Alex Lancaster 2008-04-12 14:36:37 UTC
from http://pm-utils.freedesktop.org/wiki/ :

"1.1.0 Release announcement"
There have been several changes to the way hooks are detected and invoked. If
you have a custom-written hook that breaks upon installation of this package,
you may have to perform some minor fixups to make it work again. All the hooks
that are supplied with pm-utils have been updated to take full advantage of
these changes, so use them as examples. For more detailed information, see
pm/HOWTO.hooks."

Comment 4 Till Maas 2008-04-12 14:41:26 UTC
Can you attach the output of:
/usr/bin/pm-utils-bugreport-info.sh
(run it as root pls).

Comment 5 Alex Lancaster 2008-04-12 14:54:48 UTC
Created attachment 302222 [details]
pm bug report output

Note that the kernel I've booted into: -121 was the kernel that previously
worked for me.	I do get exactly the same issue on the latest kernel.

Comment 6 Till Maas 2008-04-12 15:23:32 UTC
Did you run pm-hibernate as root or as user?

Comment 7 Michal Schmidt 2008-04-12 20:30:34 UTC
Do you perhaps have a stale lock file in /var/run/pm-utils/locks? I noticed the
lock in that directory does not get deleted by /etc/rc.d/rc.sysinit. Maybe it
should be.

Comment 8 Jon Stanley 2008-04-12 22:27:00 UTC
removing from PR blocker.  Does not block tier 1 or 2 testcases, nor
ReleaseCriteria.

Comment 9 Alex Lancaster 2008-04-12 23:42:55 UTC
(In reply to comment #6)
> Did you run pm-hibernate as root or as user?

Both.

(In reply to comment #7)
> Do you perhaps have a stale lock file in /var/run/pm-utils/locks? I noticed the
> lock in that directory does not get deleted by /etc/rc.d/rc.sysinit. Maybe it
> should be.

Hmm, I did look around for a such a file, but I was looking in /var/lock and
/var/tmp/ and other places.  I'll check now and see if that was it (don't have
access to my rawhide machine just now).  

If this turns out to be the problem, this must be a behaviour change in pm-utils
because previously a failed hibernate/resume cycle didn't prevent a subsequent
successful one.


Comment 10 Alex Lancaster 2008-04-12 23:46:29 UTC
(In reply to comment #9)
> (In reply to comment #6)
> > Did you run pm-hibernate as root or as user?
> 
> Both.

To clarify, the command that generated the attachment was done as root.


Comment 11 Till Maas 2008-04-13 08:17:28 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #6)
> > > Did you run pm-hibernate as root or as user?
> > 
> > Both.
> 
> To clarify, the command that generated the attachment was done as root.

Now I am confused, did you run "pm-hibernate" as root to try to hibernate.

Comment 12 Alex Lancaster 2008-04-13 08:31:14 UTC
(In reply to comment #11)

> > To clarify, the command that generated the attachment was done as root.
> 
> Now I am confused, did you run "pm-hibernate" as root to try to hibernate.

I ran the following

1) pm-hibernate as root and as user
2) /usr/bin/pm-utils-bugreport-info.sh as root (output attached)

In any case it appears that the problem is the stale lock file
/var/run/pm-utils/locks/pm-hibernate.log (or somesuch).  Once I removed that,
pm-hibernate works fine, so changing bug summary.

I did notice that upon a fresh startup, I do see something like the following in
the initscripts output:

"cannot remove /var/run/pm-utils/locks it is a directory"

so it does seem to be attempting to cleanup the lock files, but fails because it
may be looking in the wrong place.


Comment 13 Alex Lancaster 2008-04-13 08:32:46 UTC
(In reply to comment #12)

> "cannot remove /var/run/pm-utils/locks it is a directory"
> 
> so it does seem to be attempting to cleanup the lock files, but fails because it
> may be looking in the wrong place.

This seems to be consistent with comment #7



Comment 14 Till Maas 2008-04-14 21:48:50 UTC
rc.sysinit needs to clean /var/run/pm-utils/locks/* on bootup and maybe
/var/run/pm-utils/storage/*, too. (it would not hurt ;-)). Maybe it should even
remove every file below /var/run on bootup. Directories may be an issue, because
of selinux, but I may be wrong here.

Comment 16 Till Maas 2008-04-19 10:43:28 UTC
*** Bug 270841 has been marked as a duplicate of this bug. ***