Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 972881 - Suspend is not working when laptop's lid is closed
Suspend is not working when laptop's lid is closed
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
19
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
RejectedFreezeException
: Reopened
: 965351 974861 982890 984782 986621 (view as bug list)
Depends On: 975897
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-10 13:51 EDT by markm
Modified: 2015-01-09 18:03 EST (History)
20 users (show)

See Also:
Fixed In Version: mate-power-manager-1.6.1-3.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-01-09 18:03:23 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
message error log (19.79 KB, text/plain)
2013-07-11 08:44 EDT, Wolfgang Ulbrich
no flags Details
output of ausearch -m avc,user_avc (19.34 KB, text/plain)
2013-07-11 10:42 EDT, Wolfgang Ulbrich
no flags Details

  None (edit)
Description markm 2013-06-10 13:51:39 EDT
Description of problem:

Fresh Fedora 19 BETA installation on intel powered laptop, when closing my laptop's lid, laptop is not suspending.


Version-Release number of selected component (if applicable):

mate-desktop-libs-1.6.1-6.fc19.x86_64
mate-desktop-1.6.1-6.fc19.x86_64

How reproducible:

always

Steps to Reproduce:
1. Install fresh Fedora 19 and choose MATE Desktop
2. Login to user's account
3. Close lid

Actual results:

noting happens, laptop is not suspending

Expected results:

laptop suspended

Additional info:

checked power management settings and it's set to suspend on lid close on both ac power and battery power
Comment 1 Wolfgang Ulbrich 2013-06-11 04:51:38 EDT
I can confirm the issue on a fresh installed Mate from netiso TC2 yesterday.
Suspend on lid close didn't work with my MSI FX600.
Also shutdown and restart from lightdm menu didn't displayed.

I quick workaround is to install consolekit-x11, this do the magic and fix both issues for me.
Comment 2 Wolfgang Ulbrich 2013-06-13 08:30:38 EDT
I did a little bit further testing.
Suspend on lid close is working without consolekit in
1. runlevel 3
2. lightdm loging window

But inside MATE it doesn't work without consolekit.
Comment 3 Wolfgang Ulbrich 2013-06-13 08:34:31 EDT
Missing shutdown/restart in lightdm panel menu entries seems to be a differrent issue. see
https://bugzilla.redhat.com/show_bug.cgi?id=973618
Comment 4 markm 2013-06-14 18:26:05 EDT
Yet installing ConsoleKit-x11 restored suspend and added shutdown/restart options to the login screen.
Comment 5 Dan Mashal 2013-06-16 07:37:28 EDT
This works on F18
Comment 6 markm 2013-06-16 09:32:52 EDT
(In reply to Dan Mashal from comment #5)
> This works on F18

So it looks like regression or bug somewhere.
Comment 7 Wolfgang Ulbrich 2013-06-16 11:49:10 EDT
hmm, does it really work in f18 w/o consolekit....because consolekit is in f18 comps.
But it is definitely a issue with mate-power-manager, because if m-p-m is disabled in session autostart suspend on lid close works like a charm in mate-session.
Comment 8 Wolfgang Ulbrich 2013-06-16 12:55:53 EDT
*** Bug 974861 has been marked as a duplicate of this bug. ***
Comment 9 Dan Mashal 2013-06-17 11:46:01 EDT
Sending to lightdm.
Comment 10 Rex Dieter 2013-06-17 13:11:27 EDT
can't be lightdm inside a mate session, that's the power manager's job. back and ya.  Sounds like you may need some policykit permissions set or some missing dependency to make this work or something.

I'll try to test it myself today.
Comment 11 Rex Dieter 2013-06-17 13:28:04 EDT
*** Bug 965351 has been marked as a duplicate of this bug. ***
Comment 12 Rex Dieter 2013-06-17 13:30:36 EDT
OK, policykit permissions seem ok on my system, logged into mate session:

$ qdbus --system  org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.CanSuspend
yes

(requires qt installed, else you can use dbus-send which is a bit harder to use, or d-feet GUI to get to the same method)


For anyone experiencing this, what does the 'org.freedesktop.login1.Manager.CanSuspend' call return for you?  In particular, is anyone *not* getting 'yes'?
Comment 13 Rex Dieter 2013-06-17 13:43:26 EDT
OK, confirmed nothing happens on lid close.  Looking closer in the mate-power-manager code now.

Running with
mate-power-manager --verbose

and closing lid, it seems it is still trying to use ConsoleKit instead of systemd-login1 methods.  Looks like systemd-login1 support is broken upstream (and/or not fully tested)


TI:12:37:30     TH:0x199b6d0    FI:gpm-manager.c        FN:gpm_manager_button_pressed_cb,909
 - Button press event type=lid-down
TI:12:37:30     TH:0x199b6d0    FI:egg-console-kit.c    FN:egg_console_kit_is_active,215
 - no ConsoleKit session
TI:12:37:30     TH:0x199b6d0    FI:gpm-manager.c        FN:gpm_manager_button_pressed_cb,913
 - ignoring as not on active console
TI:12:37:30     TH:0x199b6d0    FI:gpm-backlight.c      FN:gpm_backlight_button_pressed_cb,432
 - Button press event type=lid-down
TI:12:37:30     TH:0x199b6d0    FI:gpm-backlight.c      FN:gpm_backlight_brightness_evaluate_and_set,298
 - 1. main brightness 1.000000
TI:12:37:30     TH:0x199b6d0    FI:gpm-backlight.c      FN:gpm_backlight_brightness_evaluate_and_set,307
 - Setting initial brightness level
TI:12:37:30     TH:0x199b6d0    FI:gpm-backlight.c      FN:gpm_backlight_brightness_evaluate_and_set,320
 - 2. battery scale 1.000000, brightness 1.000000
TI:12:37:30     TH:0x199b6d0    FI:gpm-backlight.c      FN:gpm_backlight_brightness_evaluate_and_set,339
 - 3. idle scale 1.000000, brightness 1.000000
TI:12:37:30     TH:0x199b6d0    FI:gpm-brightness.c     FN:gpm_brightness_trust_cache,561
 - using cache for value 100 (probably okay)
TI:12:37:30     TH:0x199b6d0    FI:gpm-backlight.c      FN:gpm_backlight_brightness_evaluate_and_set,347
 - values are the same, no action

** (mate-power-manager:16336): WARNING **: levels is 0!
TI:12:37:30     TH:0x199b6d0    FI:gpm-kbd-backlight.c  FN:gpm_kbd_backlight_set,151
 - Set brightness to 0
TI:12:37:34     TH:0x199b6d0    FI:gpm-manager.c        FN:gpm_manager_client_changed_cb,991
 - same state as before, ignoring
TI:12:37:34     TH:0x199b6d0    FI:gpm-button.c FN:gpm_button_emit_type,81
 - emitting button-pressed : lid-up
TI:12:37:34     TH:0x199b6d0    FI:gpm-manager.c        FN:gpm_manager_button_pressed_cb,909
 - Button press event type=lid-up
TI:12:37:34     TH:0x199b6d0    FI:egg-console-kit.c    FN:egg_console_kit_is_active,215
 - no ConsoleKit session
TI:12:37:34     TH:0x199b6d0    FI:gpm-manager.c        FN:gpm_manager_button_pressed_cb,913
 - ignoring as not on active console
TI:12:37:34     TH:0x199b6d0    FI:gpm-backlight.c      FN:gpm_backlight_button_pressed_cb,432
 - Button press event type=lid-up
TI:12:37:34     TH:0x199b6d0    FI:gpm-backlight.c      FN:gpm_backlight_brightness_evaluate_and_set,298
 - 1. main brightness 1.000000
Comment 14 Rex Dieter 2013-06-17 13:53:13 EDT
BUG is in gpm-manager.c in several places like this:

static void
gpm_manager_button_pressed_cb (GpmButton *button, const gchar *type, GpmManager *manager)
{
        gchar *message;
        egg_debug ("Button press event type=%s", type);

        /* ConsoleKit says we are not on active console */
        if (!egg_console_kit_is_active (manager->priv->console)) {
                egg_debug ("ignoring as not on active console");
                return;
        }


In short, if systemd-login1 support is enabled, it needs to skip this ConsoleKit-specific check, and instead query
org.freedesktop.login1.Manager.CanSuspend
and friends for the capability.
Comment 15 Wolfgang Ulbrich 2013-06-17 14:46:35 EDT
Thanks Rex for debugging.
ConsoleKit-x11 is in comps until it is fixed in upstream, so we have no probs with the f19 release.

https://github.com/mate-desktop/mate-power-manager/issues/59
Comment 16 fred smith 2013-06-19 09:25:32 EDT
(In reply to Rex Dieter from comment #12)
> OK, policykit permissions seem ok on my system, logged into mate session:
> 
> $ qdbus --system  org.freedesktop.login1 /org/freedesktop/login1
> org.freedesktop.login1.Manager.CanSuspend
> yes
> 
> (requires qt installed, else you can use dbus-send which is a bit harder to
> use, or d-feet GUI to get to the same method)
> 
> 
> For anyone experiencing this, what does the
> 'org.freedesktop.login1.Manager.CanSuspend' call return for you?  In
> particular, is anyone *not* getting 'yes'?

Yes, I get yes when I run that as a regular user. but suspend when closing lid does NOT work.

Further, I find that I DO have console-kit installed:

[root@aspirebox ~]# yum list installed | grep -y console
ConsoleKit.x86_64                     0.4.5-5.fc19              @anaconda       
ConsoleKit-libs.x86_64                0.4.5-5.fc19              @anaconda       
ConsoleKit-x11.x86_64                 0.4.5-5.fc19              @anaconda   

so I'm thinking it should be working, but it isn't.

I see some other console-kit packages available, but I wouldn't think I'd need any of them for a "normal" non-development system:

[root@aspirebox ~]# yum list available | grep -y console
ConsoleKit-devel.i686                    0.4.5-5.fc19                     fedora
ConsoleKit-devel.x86_64                  0.4.5-5.fc19                     fedora
ConsoleKit-docs.x86_64                   0.4.5-5.fc19                     fedora
ConsoleKit-libs.i686                     0.4.5-5.fc19                     fedora

FYI, this is an Acer Aspire One D255E netbook.
Comment 17 Rex Dieter 2013-06-19 09:29:55 EDT
If you have CK installed, what does this return?

$  ck-list-sessions

??

If it doesn't list your current session, how are you logging in ?  Using lightdm or other?
Comment 18 fred smith 2013-06-19 10:17:55 EDT
(In reply to Rex Dieter from comment #17)
> If you have CK installed, what does this return?
> 
> $  ck-list-sessions
> 
> ??
> 
> If it doesn't list your current session, how are you logging in ?  Using
> lightdm or other?

ck-list-sessions produces no output.

as far as I recall I'm using whatever the default DM is for a Mate session. How can I tell which one it actually is?

er,... running "ps ax | grep dm", as normal user shows two entries for lightdm, "/usr/sbin/lightdm", and "lightdm --session-child 12 19", so it looks like we're running lightdm here.

doing "ps ax | grep dm" turns up several things, but none of them is an alternate for lightdm (kdm, gdm, etc.).
Comment 19 Rex Dieter 2013-06-19 10:26:06 EDT
Arg, ok, looks like we've got 2 bugs here then.

1.  ConsoleKit registration isn't working (apparently a selinux-policy issue, works in permissive for me, but not in enforcing mode)

2.  mate-power-manager only acts on PM events (lid close, etc...) for active ConsoleKit sessions (essentially this bug)

I'll look into filing a bug for issue 1 asap once I have more detail.
Comment 20 Rex Dieter 2013-06-19 10:33:53 EDT
OK, ConsoleKit bug filed, see bug #975897
Comment 21 Rex Dieter 2013-06-20 11:45:21 EDT
Looks like selinux-policy-3.12.1-54.fc19 (see bug #975897) fixes CK session registration, and now mate-power-manager works
Comment 22 fred smith 2013-06-20 12:52:03 EDT
(In reply to Rex Dieter from comment #21)
> Looks like selinux-policy-3.12.1-54.fc19 (see bug #975897) fixes CK session
> registration, and now mate-power-manager works

Rex, thanks for following this through!

I can safely assume (or so I assume :) that this will be along as an update, in due time??

Fred
Comment 23 Wolfgang Ulbrich 2013-06-20 13:01:19 EDT
(In reply to fred smith from comment #22)
> (In reply to Rex Dieter from comment #21)
> > Looks like selinux-policy-3.12.1-54.fc19 (see bug #975897) fixes CK session
> > registration, and now mate-power-manager works
> 
> Rex, thanks for following this through!
> 
> I can safely assume (or so I assume :) that this will be along as an update,
> in due time??
> 
> Fred

You can download it here if you can't wait :)
http://koji.fedoraproject.org/koji/buildinfo?buildID=427908
Comment 24 Fedora Update System 2013-06-20 13:25:51 EDT
mate-power-manager-1.6.1-3.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mate-power-manager-1.6.1-3.fc19
Comment 25 Rex Dieter 2013-06-20 13:32:58 EDT
Update notes include :

Add a dependency on ConsoleKit, as mate-power-manager still needs it for full functionality (work is underway to port fully to systemd-logind). Also requires selinux-policy-3.12.1-54.fc19 (or newer) for proper ConsoleKit registration, see also bug #975897
Comment 26 Fedora Update System 2013-06-21 15:16:57 EDT
Package mate-power-manager-1.6.1-3.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing mate-power-manager-1.6.1-3.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-11448/mate-power-manager-1.6.1-3.fc19
then log in and leave karma (feedback).
Comment 27 James 2013-06-22 13:45:56 EDT
I have mate-power-manager-1.6.1-3.fc19 and selinux-policy-3.12.1-54.fc19 and I still see this issue. Closing the laptop lid does nothing, but opening it IS detected.
Comment 28 Wolfgang Ulbrich 2013-06-22 14:02:30 EDT
(In reply to fedorabugmail from comment #27)
> I have mate-power-manager-1.6.1-3.fc19 and selinux-policy-3.12.1-54.fc19 and
> I still see this issue. Closing the laptop lid does nothing, but opening it
> IS detected.

Is consolekit installed?
If yes try disable selinux
Comment 29 Rex Dieter 2013-06-22 21:59:53 EDT
be mindful you will likely need to reboot (or at least restart your session) to properly test this
Comment 30 markm 2013-06-23 18:41:56 EDT
Just discovered, had to install ConsoleKit-X11 in my virtual machine to get 'power off/reboot' buttons working on login screen... didn't notice it earlier as was closing vm from logged in session. Installing ConsoleKit-X11 solved the problem.
Comment 31 James 2013-06-23 21:25:28 EDT
(In reply to Wolfgang Ulbrich from comment #28)
> (In reply to fedorabugmail from comment #27)
> > I have mate-power-manager-1.6.1-3.fc19 and selinux-policy-3.12.1-54.fc19 and
> > I still see this issue. Closing the laptop lid does nothing, but opening it
> > IS detected.
> 
> Is consolekit installed?
> If yes try disable selinux

Yes.

[root@localhost test]# yum list "*console*"
Loaded plugins: langpacks
Installed Packages
ConsoleKit.x86_64                               0.4.5-5.fc19                     
ConsoleKit-libs.x86_64                          0.4.5-5.fc19                     
ConsoleKit-x11.x86_64                           0.4.5-5.fc19                     
Available Packages
...

How would I disable SELinux?
Comment 32 Rex Dieter 2013-06-23 23:26:22 EDT
Things to test if you're hitting *this* bug:

1.  what does this command in a terminal output?

$ ck-list-sessions


2.  To temporarily disable selinux,  as root:

$ setenforce 0

And then restart your session (logout/login).  What does the output of ck-list-sessions say now?
Comment 33 James 2013-06-24 09:38:15 EDT
(In reply to Rex Dieter from comment #32)
> Things to test if you're hitting *this* bug:
> 
> 1.  what does this command in a terminal output?
> 
> $ ck-list-sessions

Nothing.

> 
> 
> 2.  To temporarily disable selinux,  as root:
> 
> $ setenforce 0
> 
> And then restart your session (logout/login).  What does the output of
> ck-list-sessions say now?


Still nothing.
Comment 34 Rex Dieter 2013-06-24 09:43:01 EDT
OK, ConsoleKit session registration is (still) not working for you.  This is usually a function of your display/login manager, so which are you using (gdm, lightdm) ?

$ systemctl status display-manager

should give a hint.
Comment 35 Rex Dieter 2013-06-24 10:03:53 EDT
In short, you may experiencing effects of dependent bug #975897
Comment 36 Adam Williamson 2013-06-24 14:50:35 EDT
Discussed at 2013-06-24 freeze exception review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-24/f19final-blocker-review-8.2013-06-24-16.00.log.txt . Rejected as a freeze exception issue as suspending on lid close seems like too minor a thing to bother about fixing for the release images; it can well be fixed with an update. We don't expect lid close is a common event with the live images.
Comment 37 fred smith 2013-06-24 20:35:16 EDT
(In reply to fedorabugmail from comment #33)
> (In reply to Rex Dieter from comment #32)
> > Things to test if you're hitting *this* bug:
> > 
> > 1.  what does this command in a terminal output?
> > 
> > $ ck-list-sessions
> 
> Nothing.
> 
> > 
> > 
> > 2.  To temporarily disable selinux,  as root:
> > 
> > $ setenforce 0
> > 
> > And then restart your session (logout/login).  What does the output of
> > ck-list-sessions say now?
> 
> 
> Still nothing.

Ah, for me, once I do "setenforce 0" and log off/in, now the system DOES
suspend when closing the lid!  WhooHoo!

So, does that mean we still have a selinux-policy issue?

also, having done that, ck-list-sessions now lists sessions.
Comment 38 James 2013-06-24 20:39:47 EDT
(In reply to Rex Dieter from comment #34)
> OK, ConsoleKit session registration is (still) not working for you.  This is
> usually a function of your display/login manager, so which are you using
> (gdm, lightdm) ?
> 
> $ systemctl status display-manager
> 
> should give a hint.

[root@localhost test]# systemctl status display-manager
lightdm.service - Light Display Manager
   Loaded: loaded (/usr/lib/systemd/system/lightdm.service; enabled)
   Active: active (running) since Sun 2013-06-23 23:24:38 CDT; 20h ago
     Docs: man:lightdm(1)
...

Nothing about gdm.

> In short, you may experiencing effects of dependent bug #975897

I don't really understand that other issue.
Comment 39 Dan Mashal 2013-06-24 22:38:49 EDT
(In reply to fred smith from comment #37)
> So, does that mean we still have a selinux-policy issue?
> 
> also, having done that, ck-list-sessions now lists sessions.

Yes. I was getting gvfs denials today.
Comment 40 Fedora Update System 2013-06-29 14:42:08 EDT
mate-power-manager-1.6.1-3.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 41 James 2013-06-30 16:32:01 EDT
With mate-power-manager-1.6.1-3.fc19 and selinux-policy.noarch-3.12.1-58.fc19 this issue still exists unless I use 'setenforce 0' and logout/login.
Comment 42 Wolfgang Ulbrich 2013-07-01 10:41:37 EDT
*** Bug 979637 has been marked as a duplicate of this bug. ***
Comment 43 fred smith 2013-07-10 18:26:00 EDT
I confirmed, before the official F19 release, that using setenforce 0, along with the other updated modules suggested earlier in this thread, fixed the problem for me. but I never got a selinux-policy update that totally fixed it (so that I don't need setenforce 0).

For various reasons too boring to list here, I did a fresh install after the actual release, fully updated it, and the issue remains: sleep upon lid close (as well as screen power off when screensaver/power manager time out) only works if I have previously done setenforce 0 then logged of/on.

I have all the appropriate versions of packages (including selinux-policy 3.12.1-59.fc19) that are listed above, so it should work. but it doesn't.

Can any of you gurus offer further advice?
Comment 44 Wolfgang Ulbrich 2013-07-10 18:53:07 EDT
:(
OK, will do a fresh install too for confirming.
But it is definitely a selinux prob.
You can permanently selinus as a workaround.
If you don't use a server this is OK. For a desktop you don't need normaly selinux.
http://www.crypt.gen.nz/selinux/disable_selinux.html
edit /etc/selinux/config and you will see some lines like this:

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - No SELinux policy is loaded.
SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted

... just change SELINUX=enforcing to SELINUX=permissive, and you're done. Reboot if you want to prove it.

I will move this report to selinux-policy which is the right place for further debugging.
Comment 45 Wolfgang Ulbrich 2013-07-10 18:54:54 EDT
i meant,
'You can permanently disable selinux as a workaround.'
Comment 46 Daniel Walsh 2013-07-10 20:04:03 EDT
selinux-policy-3.12.1-62 and probably earlier have consolekit back.  What AVCs are you currently seeing?
Comment 47 fred smith 2013-07-10 21:57:47 EDT
Pardon my ignorance, but: AVCs??
Comment 48 Adam Williamson 2013-07-11 01:09:09 EDT
SELinux denial messages - the things you see in the SELinux troubleshooter GUI.
Comment 49 Wolfgang Ulbrich 2013-07-11 08:43:13 EDT
I did a fresh f19 installation (netiso) today and i can confirm the issue.
Selinux prevent consolekit from workking!
In short:
1) lightdm needs about 10 secs to start after graphical target.
2) Mate desktop needs about 30 secs to start ffrom lightdm.
3) suspend on lid close doesn't work.
4) ck-list-sessions gives no output

Unfortunately i got no AVCs from selinux, but i found a lot of messages like this in logs.

Jul 11 14:14:03 satellite systemd[1]: Starting Console Manager...
Jul 11 14:14:03 satellite dbus-daemon[471]: dbus[471]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'
Jul 11 14:14:03 satellite dbus[471]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'
Jul 11 14:14:03 satellite console-kit-daemon[1235]: console-kit-daemon[1235]: WARNING: Failed to acquire org.freedesktop.ConsoleKit: An SELinux policy prevents this sender from sending this message to this recipient, 0 matched rules; type="method_call", sender=":1.22" (uid=0 pid=1153 comm="lightdm --session-child 12 19 ") interface="org.freedesktop.ConsoleKit.Manager" member="OpenSessionWithParameters" error name="(unset)" requested_reply="0" destination="org.freedesktop.ConsoleKit" (uid=0 pid=1235 comm="/usr/sbin/console-kit-daemon --no-daemon ")
Jul 11 14:14:03 satellite console-kit-daemon[1235]: console-kit-daemon[1235]: WARNING: Could not acquire name; bailing out
Jul 11 14:14:03 satellite systemd[1]: Started Console Manager.
Jul 11 14:14:03 satellite console-kit-daemon[1235]: WARNING: Failed to acquire org.freedesktop.ConsoleKit: An SELinux policy prevents this sender from sending this message to this recipient, 0 matched rules; type="method_call", sender=":1.22" (uid=0 pid=1153 comm="lightdm --session-child 12 19 ") interface="org.freedesktop.ConsoleKit.Manager" member="OpenSessionWithParameters" error name="(unset)" requested_reply="0" destination="org.freedesktop.ConsoleKit" (uid=0 pid=1235 comm="/usr/sbin/console-kit-daemon --no-daemon ")
Jul 11 14:14:03 satellite console-kit-daemon[1235]: WARNING: Could not acquire name; bailing out
Jul 11 14:14:03 satellite systemd[1]: console-kit-daemon.service: main process exited, code=exited, status=1/FAILURE
Jul 11 14:14:03 satellite systemd[1]: Unit console-kit-daemon.service entered failed state.
Jul 11 14:14:28 satellite dbus-daemon[471]: dbus[471]: [system] Failed to activate service 'org.freedesktop.ConsoleKit': timed out
Jul 11 14:14:28 satellite dbus[471]: [system] Failed to activate service 'org.freedesktop.ConsoleKit': timed out
Jul 11 14:14:28 satellite lightdm[519]: ** (process:1153): WARNING **: Failed to open CK session: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Activation of org.freedesktop.ConsoleKit timed out

This happens with selinux-policy 3.12.1-59.fc19 and selinux-policy 3.12.1-63.fc19 from koji.

If i set SELINUX=permissive everthing works well.

Daniel, i think we should re-open https://bugzilla.redhat.com/show_bug.cgi?id=975897
and close this one.
Comment 50 Wolfgang Ulbrich 2013-07-11 08:44:37 EDT
Created attachment 772210 [details]
message error log
Comment 51 Miroslav Grepl 2013-07-11 10:22:53 EDT
Could you try to run in a terminal

# ausearch -m avc,user_avc
Comment 52 Wolfgang Ulbrich 2013-07-11 10:42:48 EDT
Created attachment 772259 [details]
output of ausearch -m avc,user_avc
Comment 53 Miroslav Grepl 2013-07-11 10:45:52 EDT
Ok and

# ps -eZ |grep initrc
# rpm -q selinux-policy-targeted
Comment 54 Wolfgang Ulbrich 2013-07-11 11:09:07 EDT
[root@satellite ~]# ps -eZ |grep initrc
system_u:system_r:initrc_t:s0    1442 ?        00:00:00 console-kit-dae
[root@satellite ~]# rpm -q selinux-policy-targeted
selinux-policy-targeted-3.12.1-63.fc19.noarch
Comment 55 Daniel Walsh 2013-07-11 14:29:51 EDT
ls -lZ /usr/sbin/console-kit-daemon

restorecon -R -v /usr/sbin
Comment 56 Wolfgang Ulbrich 2013-07-11 14:38:02 EDT
[root@satellite ~]# ls -lZ /usr/sbin/console-kit-daemon
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/sbin/console-kit-daemon
[root@satellite ~]# restorecon -R -v /usr/sbin
restorecon reset /usr/sbin/console-kit-daemon context system_u:object_r:bin_t:s0->system_u:object_r:consolekit_exec_t:s0
restorecon reset /usr/sbin/iscsiadm context system_u:object_r:bin_t:s0->system_u:object_r:iscsid_exec_t:s0
restorecon reset /usr/sbin/rngd context system_u:object_r:bin_t:s0->system_u:object_r:rngd_exec_t:s0
Comment 57 Wolfgang Ulbrich 2013-07-11 14:48:16 EDT
amazing, after applying the last 2 commands as root all works well after a restart + enable selinux.
Comment 58 fred smith 2013-07-11 15:33:53 EDT
Reply to #48:

Adam, I don't see anything added to the selinux error list when I close and re-open the lid. in fact, nothing was added during system startup, either. but the current state is that sleep on lid close does not work.

As did Wolfgang in msg #49, I got a ton of things in /var/log/messages about consolekit failures:

Jul 11 15:20:03 aspirebox systemd[1]: Starting Console Manager...
Jul 11 15:20:03 aspirebox dbus-daemon[574]: dbus[574]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'
Jul 11 15:20:03 aspirebox dbus[574]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'
Jul 11 15:20:03 aspirebox console-kit-daemon[1209]: console-kit-daemon[1209]: WARNING: Failed to acquire org.freedesktop.Co
nsoleKit: An SELinux policy prevents this sender from sending this message to this recipient, 0 matched rules; type="method
_call", sender=":1.25" (uid=0 pid=1198 comm="lightdm --session-child 12 19 ") interface="org.freedesktop.ConsoleKit.Manager
" member="OpenSessionWithParameters" error name="(unset)" requested_reply="0" destination="org.freedesktop.ConsoleKit" (uid
=0 pid=1209 comm="/usr/sbin/console-kit-daemon --no-daemon ")
Jul 11 15:20:03 aspirebox systemd[1]: Started Console Manager.
Jul 11 15:20:03 aspirebox console-kit-daemon[1209]: console-kit-daemon[1209]: WARNING: Could not acquire name; bailing out
Jul 11 15:20:03 aspirebox console-kit-daemon[1209]: WARNING: Failed to acquire org.freedesktop.ConsoleKit: An SELinux polic
y prevents this sender from sending this message to this recipient, 0 matched rules; type="method_call", sender=":1.25" (ui
d=0 pid=1198 comm="lightdm --session-child 12 19 ") interface="org.freedesktop.ConsoleKit.Manager" member="OpenSessionWithP
arameters" error name="(unset)" requested_reply="0" destination="org.freedesktop.ConsoleKit" (uid=0 pid=1209 comm="/usr/sbi
n/console-kit-daemon --no-daemon ")
Jul 11 15:20:03 aspirebox console-kit-daemon[1209]: WARNING: Could not acquire name; bailing out
Jul 11 15:20:03 aspirebox systemd[1]: console-kit-daemon.service: main process exited, code=exited, status=1/FAILURE
Jul 11 15:20:03 aspirebox systemd[1]: Unit console-kit-daemon.service entered failed state.
Jul 11 15:20:04 aspirebox chronyd[551]: Selected source 67.18.187.111
Jul 11 15:20:28 aspirebox dbus-daemon[574]: dbus[574]: [system] Failed to activate service 'org.freedesktop.ConsoleKit': ti
med out
Jul 11 15:20:28 aspirebox dbus[574]: [system] Failed to activate service 'org.freedesktop.ConsoleKit': timed out
Jul 11 15:20:29 aspirebox systemd-logind[558]: New session 1 of user fredex.
Jul 11 15:20:29 aspirebox systemd-logind[558]: Linked /tmp/.X11-unix/X0 to /run/user/1000/X11-display.
Jul 11 15:20:29 aspirebox dbus-daemon[574]: dbus[574]: [system] Activating via systemd: service name='org.freedesktop.Conso
leKit' unit='console-kit-daemon.service'
Jul 11 15:20:29 aspirebox dbus[574]: [system] Activating via systemd: service name='org.freedesktop.ConsoleKit' unit='conso
le-kit-daemon.service'
Jul 11 15:20:29 aspirebox systemd[1]: Starting Console Manager...
Jul 11 15:20:29 aspirebox dbus-daemon[574]: dbus[574]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'
Jul 11 15:20:29 aspirebox dbus[574]: [system] Successfully activated service 'org.freedesktop.ConsoleKit'
Jul 11 15:20:29 aspirebox console-kit-daemon[1278]: console-kit-daemon[1278]: WARNING: Failed to acquire org.freedesktop.ConsoleKit: An SELinux policy prevents this sender from sending this message to this recipient, 0 matched rules; type="method_call", sender=":1.24" (uid=0 pid=1198 comm="lightdm --session-child 12 19 ") interface="org.freedesktop.ConsoleKit.Manager" member="OpenSessionWithParameters" error name="(unset)" requested_reply="0" destination="org.freedesktop.ConsoleKit" (uid=0 pid=1278 comm="/usr/sbin/console-kit-daemon --no-daemon ")
Jul 11 15:20:29 aspirebox console-kit-daemon[1278]: console-kit-daemon[1278]: WARNING: Could not acquire name; bailing out
Jul 11 15:20:29 aspirebox console-kit-daemon[1278]: WARNING: Failed to acquire org.freedesktop.ConsoleKit: An SELinux policy prevents this sender from sending this message to this recipient, 0 matched rules; type="method_call", sender=":1.24" (uid=0 pid=1198 comm="lightdm --session-child 12 19 ") interface="org.freedesktop.ConsoleKit.Manager" member="OpenSessionWithParameters" error name="(unset)" requested_reply="0" destination="org.freedesktop.ConsoleKit" (uid=0 pid=1278 comm="/usr/sbin/console-kit-daemon --no-daemon ")
Jul 11 15:20:29 aspirebox console-kit-daemon[1278]: WARNING: Could not acquire name; bailing out
Jul 11 15:20:29 aspirebox systemd[1]: Started Console Manager.
Jul 11 15:20:29 aspirebox systemd[1]: console-kit-daemon.service: main process exited, code=exited, status=1/FAILURE
Jul 11 15:20:29 aspirebox systemd[1]: Unit console-kit-daemon.service entered failed state.

that seems to indicate it failed repeatedly and suffered a timeout. this may explain why first login after boot takes a very long time, whereas subsequent logins are only a relatively few seconds.

Reply to msg #51, I got this when running the suggested command:

time->Thu Jul 11 15:20:03 2013
type=USER_AVC msg=audit(1373570403.520:430): pid=574 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for msgtype=method_call interface=org.freedesktop.ConsoleKit.Manager member=OpenSessionWithParameters dest=org.freedesktop.ConsoleKit spid=1198 tpid=1209 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=dbus  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'
----
time->Thu Jul 11 15:20:29 2013
type=USER_AVC msg=audit(1373570429.317:435): pid=574 uid=81 auid=4294967295 ses=4294967295 subj=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 msg='avc:  denied  { send_msg } for msgtype=method_call interface=org.freedesktop.ConsoleKit.Manager member=OpenSessionWithParameters dest=org.freedesktop.ConsoleKit spid=1198 tpid=1278 scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=system_u:system_r:initrc_t:s0 tclass=dbus  exe="/usr/bin/dbus-daemon" sauid=81 hostname=? addr=? terminal=?'

there is actually a lot more, but these two appear (based on timestamps) to be for the most recent bootup session.

reply to #53:

# ps -eZ |grep initrc
system_u:system_r:initrc_t:s0    1654 ?        00:00:00 console-kit-dae
# rpm -q selinux-policy-targeted
selinux-policy-targeted-3.12.1-59.fc19.noarch

Reply to #55:

# ls -lZ /usr/sbin/console-kit-daemon
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/sbin/console-kit-daemon
Comment 59 fred smith 2013-07-11 15:44:27 EDT
# restorecon -R -v /usr/sbin
restorecon reset /usr/sbin/console-kit-daemon context system_u:object_r:bin_t:s0->system_u:object_r:consolekit_exec_t:s0
restorecon reset /usr/sbin/rngd context system_u:object_r:bin_t:s0->system_u:object_r:rngd_exec_t:s0
restorecon reset /usr/sbin/iscsiadm context system_u:object_r:bin_t:s0->system_u:object_r:iscsid_exec_t:s0

After all the diagnostics above (in #58), I ran the restorecon command above, as did Wolfgang in #57, it produced the output shown immediately above this paragraph, and after a reboot suspend-on-close works (as well as suspend-on-suspend-button-press, which didn't work either).

So, how did the file context get messed up in the first place? Since Wolfgang reproduced it, it apparently wasn't some screw-up of mine.
Comment 60 Wolfgang Ulbrich 2013-07-11 15:54:46 EDT
@ Daniel Walsh
can you decribe more details what's happend for us selinux novices?
This example shows me not to run such a mysterious software if it's not needed :)
Comment 61 Adam Williamson 2013-07-11 16:00:29 EDT
It is not remotely mysterious. It is *extensively* documented in the package, in man pages, and all over the internet. You do have some responsibility to educate yourself about the software you are running.
Comment 62 Wolfgang Ulbrich 2013-07-11 16:08:45 EDT
(In reply to Adam Williamson from comment #61)
> It is not remotely mysterious. It is *extensively* documented in the
> package, in man pages, and all over the internet. You do have some
> responsibility to educate yourself about the software you are running.

Sorry, i didn't asked about using man pages or searching documments all over the internet.
I want to understand why users needs to run 'restorecon -R -v /usr/sbin' in a fixed package.
But i understand your job is to defense fedora.
Comment 63 Wolfgang Ulbrich 2013-07-11 16:10:51 EDT
PS:
I don't use selinux, prob other people :)
Comment 64 Adam Williamson 2013-07-11 16:11:52 EDT
No, that's not the point. You described SELinux as 'mysterious'. It is not remotely mysterious. I get annoyed at the consistent characterization that it's some weird thing any normal person should turn off. It's not. It's an important security tool and it does a disservice to people to suggest turning it off as a matter of course.
Comment 65 James 2013-07-12 00:47:08 EDT
(In reply to Daniel Walsh from comment #55)
> ls -lZ /usr/sbin/console-kit-daemon
> 
> restorecon -R -v /usr/sbin

This command + reboot fixes this issue using selinux-policy-3.12.1-59. It also fixes https://bugzilla.redhat.com/show_bug.cgi?id=979637 and cut a minute off login time. Thank you Adam, Daniel and Miroslav!
Comment 66 Wolfgang Ulbrich 2013-07-12 04:05:23 EDT
@Miroslav Grepl
I'm agree with you to close this report, but there are two open question.
Why this happend in a fresh installation with selinux-policy-3.12.1-59 as i described it in #49  ?
And how can we avoid that users run in this selinux issue if they install f19 with lightdm and MATE?
Comment 67 Miroslav Grepl 2013-07-12 07:02:13 EDT
*** Bug 982890 has been marked as a duplicate of this bug. ***
Comment 68 joshua 2013-07-13 18:30:31 EDT
I made no selinux changes whatsoever, and it is very broken on my laptop.  Why do we have to do a "restorecon -R -v /usr/sbin" for normal operation?  Needing to do so means that something is broken.
Comment 69 Wolfgang Ulbrich 2013-07-15 09:23:57 EDT
By the way, why is /usr/bin/audit2allow in policycoreutils-devel-2.1.14-46.4.fc19 ?
Without installing this devel package "restorecon -R -v /usr/sbin" didn't work to fix this issue.
Also all tips in selinux-gui didn't work without 'audit2allow'. :)
Comment 70 Daniel Walsh 2013-07-15 16:27:30 EDT
The problem is consolekit was removed from policy because it was believed that no packages were using it anymore.  When adding it back in an update for some reason consolekit is not getting relabelled.

audit2allow has been moved in and out of packages based on requirements for minimal install,  It uses selinux-policy-devel for some of its features, which is a large package.  So we don't want that package installed by default.  I guess we could move audit2allow back into policycoreutils-python and then if you try to use an advanced feature, tell the user to install the policycoreutils-devel package.
Comment 71 Joe Zeff 2013-07-15 18:21:18 EDT
I can second Comment 49, except that in my case it was an upgrade via fedup.  (http://forums.fedoraforum.org/showthread.php?t=292562 for details)  In my case, before the restorecon it took 2 minutes to go from the beginning of boot to a working desktop, of which 27 seconds were boot.  Now, it's just under one minute, total.
Comment 72 Miroslav Grepl 2013-07-16 03:49:45 EDT
*** Bug 984782 has been marked as a duplicate of this bug. ***
Comment 73 Stuart D Gathman 2013-07-18 23:28:11 EDT
I also ran into this bug on a fresh install of F19 from MATE-Compiz liveCD, and after fully updating.  I set powermanager to blank screen after 1 min (so short so testing doesn't take forever).  With SELinux enforcing, the screen never blanks.  If I login after setenforce 0, the screen blanks as requested.  And on another laptop, also installed from liveCD and fully updated (and rebooted), the suspend on lid close does not happen with selinux enforcing.
Comment 74 Stuart D Gathman 2013-07-18 23:46:26 EDT
I did the restorecon -R -v /usr/sbin on both laptops.  On one, the console-kit-daemon was relabelled, and the problem was fixed after reboot.  On the other (this will blow your mind), restorecon -R -v /usr/sbin did *not* relabel console-kit-daemon.  So something is screwy with restorecon, or the policy database.  I manually relabelled /usr/sbin/console-kit-daemon with chcon.  Note that both laptops have selinux-policy-3.12.1-63.

[root@gail ~]# ls -lZ /usr/sbin/console*
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/sbin/console-kit-daemon
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/sbin/consoletype
[root@gail ~]# rpm -q selinux-policy
selinux-policy-3.12.1-63.fc19.noarch
[root@gail ~]# restorecon -R -v /usr/sbin
[root@gail ~]# ls -lZ /usr/sbin/console*
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/sbin/console-kit-daemon
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/sbin/consoletype
[root@gail ~]# yum update
Loaded plugins: langpacks
No packages marked for update
[root@gail ~]# uptime
 23:39:06 up  3:53,  2 users,  load average: 0.47, 0.30, 0.29
[root@gail ~]# chcon system_u:object_r:consolekit_exec_t:s0 /usr/sbin/console-kit*
[root@gail ~]# ls -lZ /usr/sbin/console*
-rwxr-xr-x. root root system_u:object_r:consolekit_exec_t:s0 /usr/sbin/console-kit-daemon
-rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/sbin/consoletype
Comment 75 Wolfgang Ulbrich 2013-07-19 04:58:33 EDT
(In reply to Stuart D Gathman from comment #74)
> I did the restorecon -R -v /usr/sbin on both laptops.  On one, the
> console-kit-daemon was relabelled, and the problem was fixed after reboot. 
> On the other (this will blow your mind), restorecon -R -v /usr/sbin did
> *not* relabel console-kit-daemon.  So something is screwy with restorecon,
> or the policy database.  I manually relabelled /usr/sbin/console-kit-daemon
> with chcon.  Note that both laptops have selinux-policy-3.12.1-63.
> 
> [root@gail ~]# ls -lZ /usr/sbin/console*
> -rwxr-xr-x. root root system_u:object_r:bin_t:s0      
> /usr/sbin/console-kit-daemon
> -rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/sbin/consoletype
> [root@gail ~]# rpm -q selinux-policy
> selinux-policy-3.12.1-63.fc19.noarch
> [root@gail ~]# restorecon -R -v /usr/sbin
> [root@gail ~]# ls -lZ /usr/sbin/console*
> -rwxr-xr-x. root root system_u:object_r:bin_t:s0      
> /usr/sbin/console-kit-daemon
> -rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/sbin/consoletype
> [root@gail ~]# yum update
> Loaded plugins: langpacks
> No packages marked for update
> [root@gail ~]# uptime
>  23:39:06 up  3:53,  2 users,  load average: 0.47, 0.30, 0.29
> [root@gail ~]# chcon system_u:object_r:consolekit_exec_t:s0
> /usr/sbin/console-kit*
> [root@gail ~]# ls -lZ /usr/sbin/console*
> -rwxr-xr-x. root root system_u:object_r:consolekit_exec_t:s0
> /usr/sbin/console-kit-daemon
> -rwxr-xr-x. root root system_u:object_r:bin_t:s0       /usr/sbin/consoletype

Check if /usr/bin/audit2allow does exits, if not install policycoreutils-devel and do the 'restorecon -R -v /usr/sbin' again.
Comment 76 Daniel Walsh 2013-07-19 06:37:48 EDT
Most likely you don't have the latest selinux-policy-targeted package on that machine.

rpm -q selinux-policy-targeted

matchpatchon /usr/sbin/console-kit-daemon

Will tell you what the policy currently thinks the file should be labeled.
Comment 77 Stuart D Gathman 2013-07-19 09:30:28 EDT
(In reply to Daniel Walsh from comment #76)
> Most likely you don't have the latest selinux-policy-targeted package on
> that machine.
> 
> rpm -q selinux-policy-targeted
> 
> matchpatchon /usr/sbin/console-kit-daemon
> 
> Will tell you what the policy currently thinks the file should be labeled.

[root@gail ~]# rpm -q selinux-policy-targeted
selinux-policy-targeted-3.12.1-63.fc19.noarch
[root@gail ~]# matchpatchon /usr/sbin/console-kit-daemon
-bash: matchpatchon: command not found
[root@gail ~]# yum provides '*/matchpatchon'
Loaded plugins: langpacks
adobe-linux-i386/filelists                               | 139 kB     00:00     
fedora/19/i386/filelists_db                              |  24 MB     00:18     
gathman/filelists_db                                     |  26 kB     00:00     
rpmfusion-free/19/i386/filelists_db                      | 285 kB     00:00     
rpmfusion-free-updates/19/i386/filelists_db              |  31 kB     00:00     
rpmfusion-nonfree/19/i386/filelists_db                   | 214 kB     00:00     
rpmfusion-nonfree-updates/19/i386/filelists_db           |  13 kB     00:00     
updates/19/i386/filelists_db                             | 6.0 MB     00:04     
No matches found
[root@gail ~]# restorecon -Rnv /usr/sbin
restorecon reset /usr/sbin/console-kit-daemon context system_u:object_r:consolekit_exec_t:s0->system_u:object_r:bin_t:s0
[root@gail ~]#
Comment 78 Rex Dieter 2013-07-19 09:36:23 EDT
to get matchpatchon tool,

yum install libselinux-utils
Comment 79 Stuart D Gathman 2013-07-19 09:45:49 EDT
There are number of symptoms of this problem, not just "laptop won't suspend".  In addition to my issue of "screen won't blank", I have also been researching "MATE takes forever to log in" - both of which go away with console-kit-daemon properly labelled.  Hopefully, mentioning those problems here will help search engines find this issue.  Is there a better title?  Should I file more bugs pointing at this one?

These systems were installed from the MATE-compiz liveCD (which actually fits on a CD!).  Is it possible that the selinux policy database was somehow corrupted on the live image, and doesn't get corrected by updates?
Comment 80 Stuart D Gathman 2013-07-19 09:47:39 EDT
(In reply to Rex Dieter from comment #78)
> to get matchpatchon tool,
> 
> yum install libselinux-utils

[root@gail ~]# matchpathcon /usr/sbin/console-kit-daemon
/usr/sbin/console-kit-daemon	system_u:object_r:bin_t:s0

(you misspelled the matchpathcon!)
Comment 81 Stuart D Gathman 2013-07-19 10:00:20 EDT
I yum reinstalled selinux-policy-targeted-3.12.1-63 (redownloads and rechecked signature).  Still wants wrong label for console-kit-daemon.

Is it possible that a Black Hat has somehow compromised the selinux RPM in the repo?  The working laptops were updated earlier, and the broken one updated yesterday.
Comment 82 Stuart D Gathman 2013-07-19 17:28:24 EDT
Yep, looks like selinux-policy-targeted is either corrupted or compromised:

[root@gail ~]# matchpathcon /usr/sbin/console-kit-daemon
/usr/sbin/console-kit-daemon	system_u:object_r:bin_t:s0
[root@gail ~]# rpm -q selinux-policy-targeted
selinux-policy-targeted-3.12.1-63.fc19.noarch
----------------
[root@silver ~]# matchpathcon /usr/sbin/console-kit-daemon
/usr/sbin/console-kit-daemon	system_u:object_r:consolekit_exec_t:s0
[root@silver ~]# rpm -q selinux-policy-targeted
selinux-policy-targeted-3.12.1-63.fc19.noarch
----------------

Diff in sha256sums:


9c9
< 60c1d21253806aca7deeecff574f69c91bfd3e9df37d081bc24d07833ada09f9  /etc/selinux/targeted/contexts/files/file_contexts.bin
---
> 93417d126d7e1b7ec9789b7f369c940e93fbae5499f8b9a22db4068d0347f564  /etc/selinux/targeted/contexts/files/file_contexts.bin
11c11
< 62aeaf3b6e093c06f56e58abefedbccdada6f059cd4a02f08af037bb0731711b  /etc/selinux/targeted/contexts/files/file_contexts.homedirs.bin
---
> 7c07509b6904dcde5887538bfaaea17c1f7e9549cfaabfb24add3fe414774249  /etc/selinux/targeted/contexts/files/file_contexts.homedirs.bin
Comment 83 Stuart D Gathman 2013-07-19 18:49:23 EDT
Interesting, the source files match.  Only the binaries are different.  How do you recompile the file_contexts (and homedirs) source?
Comment 84 Stuart D Gathman 2013-07-19 19:41:59 EDT
I did an semodule -B to recompile the policy, and now matchpathcon returns the expected results.
Comment 85 Stuart D Gathman 2013-07-19 19:43:40 EDT
And a restorecon -rv / changed a good number of files from the ConsoleKit-x11 package.
Comment 86 Daniel Walsh 2013-07-21 07:11:51 EDT
For some reason the update was not successfully rebuilding the policy,  Did you see any errors?
Comment 87 Stuart D Gathman 2013-07-21 18:36:19 EDT
No errors.  And I just installed another laptop, did the update, carefully looked for any errors (in a terminal session) and didn't see any.  Again, I had to do semodule -B and then restorecon -rv /.

At any rate, there is a work around.
Comment 88 Miroslav Grepl 2013-07-22 04:02:13 EDT
Stuart,
any chance you had disabled SELinux and did an update?

I have been trying to reproduce it but the update works OK.

Preparing...                          ################################# [100%]
Updating / installing...
   1:selinux-policy-3.12.1-54.fc19    ################################# [ 25%]
   2:selinux-policy-targeted-3.12.1-54################################# [ 50%]
Cleaning up / removing...
   3:selinux-policy-targeted-3.12.1-62################################# [ 75%]
   4:selinux-policy-3.12.1-62.fc19    ################################# [100%]
sh-4.2# matchpathcon /usr/sbin/console-kit-daemon/usr/sbin/console-kit-daemon	system_u:object_r:bin_t:s0


Updated:
  selinux-policy.noarch 0:3.12.1-59.fc19                                         
  selinux-policy-targeted.noarch 0:3.12.1-59.fc19                                

Complete!
sh-4.2# matchpathcon /usr/sbin/console-kit-daemon
/usr/sbin/console-kit-daemon	system_u:object_r:consolekit_exec_t:s0
Comment 89 Stuart D Gathman 2013-07-22 13:09:31 EDT
(In reply to Miroslav Grepl from comment #88)
> Stuart,
> any chance you had disabled SELinux and did an update?
> 
> I have been trying to reproduce it but the update works OK.

No chance.  I just install from the LiveCD, and immediately update after logging in and starting wireless.  I'll be doing it twice more, but this has happened consistently the first 4 times (a desktop and 3 laptops).  Did you use the MATE LiveCD?  Perhaps this problem is related to that spin?  

I wonder if the update might work if I did setenforce 0 before logging in, starting the wireless, and updating?  I'll try that with the next laptop.
Comment 90 Miroslav Grepl 2013-07-24 09:56:03 EDT
Ok, I tested on my system. Need to re-test with LiveCD.
Comment 91 Wolfgang Ulbrich 2013-07-24 10:27:16 EDT
MATE upstream has fix systemd-login1 support for mate-power-manager.
Suspend on lid close works now without consolekit.
I did a scratch build for testing.
x86_64
http://koji.fedoraproject.org/koji/taskinfo?taskID=5651458
i686
http://koji.fedoraproject.org/koji/taskinfo?taskID=5651459
Pls install those package, uninstall consolekit and test 'suspend on lid close' in MATE.
Feedback is welcome ;)
Comment 92 Wolfgang Ulbrich 2013-07-24 10:43:39 EDT
(In reply to Wolfgang Ulbrich from comment #91)
> MATE upstream has fix systemd-login1 support for mate-power-manager.
> Suspend on lid close works now without consolekit.
> I did a scratch build for testing.
> x86_64
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5651458
> i686
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5651459
> Pls install those package, uninstall consolekit and test 'suspend on lid
> close' in MATE.
> Feedback is welcome ;)

Sorry, links are for rawhide, try those one for f19.
x86_64
http://koji.fedoraproject.org/koji/taskinfo?taskID=5651547
i386
http://koji.fedoraproject.org/koji/taskinfo?taskID=5651548
Comment 93 Mateusz Sylwestrzak 2013-07-24 14:41:54 EDT
(In reply to Wolfgang Ulbrich from comment #92)
> (In reply to Wolfgang Ulbrich from comment #91)
> > MATE upstream has fix systemd-login1 support for mate-power-manager.
> > Suspend on lid close works now without consolekit.
> > I did a scratch build for testing.
> > x86_64
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=5651458
> > i686
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=5651459
> > Pls install those package, uninstall consolekit and test 'suspend on lid
> > close' in MATE.
> > Feedback is welcome ;)
> 
> Sorry, links are for rawhide, try those one for f19.
> x86_64
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5651547
> i386
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5651548

After following these two steps I got the suspend feature working for MATE.
Comment 94 Fedora Update System 2013-07-24 16:18:56 EDT
mate-power-manager-1.6.2-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/mate-power-manager-1.6.2-1.fc19
Comment 95 Dan Mashal 2013-07-27 07:19:57 EDT
confirmed the fix after removing consolekit*
Comment 96 Wolfgang Ulbrich 2013-07-27 07:51:34 EDT
@ Daniel Walsh
@ Miroslav Grepl
I do not close this report with updated mate-power-manager-1.6.2-1.fc19,
because this issue concern also xfce users who use lightdm too, consolekit is in xfce comps.
From MATE side i will remove consolekit from comps if the update is in stable.
So it is up to xfce maintainer to do the same, lightdm is working well without consolekit in a MATE installation.
You should also thing about to rename the subject of the report.
Comment 97 Wolfgang Ulbrich 2013-08-02 13:45:00 EDT
*** Bug 986621 has been marked as a duplicate of this bug. ***
Comment 98 Fedora Update System 2013-08-02 18:11:01 EDT
mate-power-manager-1.6.2-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 99 hannes 2013-11-05 06:04:08 EST
I need to confirm, that this problem also hit me on a fresh install of the Xfce spin (f19). Is there a way to fix the install images? Because it really gives a bad impression, if you are trying the spin and after the install, you got a very long timeout while logging in.
Comment 100 Fedora End Of Life 2015-01-09 17:08:54 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 101 Adam Williamson 2015-01-09 18:03:23 EST
I think this one should be closed by now.

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