Bug 442178 - cleanup /var/run/pm-utils/locks/* properly
cleanup /var/run/pm-utils/locks/* properly
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: initscripts (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Bill Nottingham
Fedora Extras Quality Assurance
:
: 270841 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-12 10:25 EDT by Alex Lancaster
Modified: 2014-03-16 23:13 EDT (History)
8 users (show)

See Also:
Fixed In Version: 8.70-1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-15 13:06:48 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
pm bug report output (3.20 KB, text/plain)
2008-04-12 10:54 EDT, Alex Lancaster
no flags Details

  None (edit)
Description Alex Lancaster 2008-04-12 10:25:27 EDT
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 10:28:50 EDT
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 10:34:23 EDT
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 10:36:37 EDT
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 10:41:26 EDT
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 10:54:48 EDT
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 11:23:32 EDT
Did you run pm-hibernate as root or as user?
Comment 7 Michal Schmidt 2008-04-12 16:30:34 EDT
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 18:27:00 EDT
removing from PR blocker.  Does not block tier 1 or 2 testcases, nor
ReleaseCriteria.
Comment 9 Alex Lancaster 2008-04-12 19:42:55 EDT
(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 19:46:29 EDT
(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 04:17:28 EDT
(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 04:31:14 EDT
(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 04:32:46 EDT
(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 17:48:50 EDT
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 06:43:28 EDT
*** Bug 270841 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.