Bug 972881

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.

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.

Missing shutdown/restart in lightdm panel menu entries seems to be a differrent issue. see
https://bugzilla.redhat.com/show_bug.cgi?id=973618

Yet installing ConsoleKit-x11 restored suspend and added shutdown/restart options to the login screen.

This works on F18

(In reply to Dan Mashal from comment #5)
> This works on F18

So it looks like regression or bug somewhere.

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.

*** Bug 974861 has been marked as a duplicate of this bug. ***

Sending to lightdm.

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.

*** Bug 965351 has been marked as a duplicate of this bug. ***

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'?

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

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.

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

(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.

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?

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

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.

OK, ConsoleKit bug filed, see bug #975897

Looks like selinux-policy-3.12.1-54.fc19 (see bug #975897) fixes CK session registration, and now mate-power-manager works

(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

(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

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

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

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

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.

(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

be mindful you will likely need to reboot (or at least restart your session) to properly test this

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.

(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?

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?

(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.

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.

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

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.

(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.

(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.

(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.

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.

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.

*** Bug 979637 has been marked as a duplicate of this bug. ***

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?

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

i meant,
'You can permanently disable selinux as a workaround.'

selinux-policy-3.12.1-62 and probably earlier have consolekit back.  What AVCs are you currently seeing?

Pardon my ignorance, but: AVCs??

SELinux denial messages - the things you see in the SELinux troubleshooter GUI.

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.

Created attachment 772210 [details]
message error log

Could you try to run in a terminal

# ausearch -m avc,user_avc

Created attachment 772259 [details]
output of ausearch -m avc,user_avc

Ok and

# ps -eZ |grep initrc
# rpm -q selinux-policy-targeted

[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

ls -lZ /usr/sbin/console-kit-daemon

restorecon -R -v /usr/sbin

[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

amazing, after applying the last 2 commands as root all works well after a restart + enable selinux.

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

# 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.

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

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.

(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.

PS:
I don't use selinux, prob other people :)

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.

(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!

@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?

*** Bug 982890 has been marked as a duplicate of this bug. ***

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.

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

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.

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.

*** Bug 984782 has been marked as a duplicate of this bug. ***

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.

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

(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.

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.

(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 ~]#

to get matchpatchon tool,

yum install libselinux-utils

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?

(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!)

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.

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

Interesting, the source files match.  Only the binaries are different.  How do you recompile the file_contexts (and homedirs) source?

I did an semodule -B to recompile the policy, and now matchpathcon returns the expected results.

And a restorecon -rv / changed a good number of files from the ConsoleKit-x11 package.

For some reason the update was not successfully rebuilding the policy,  Did you see any errors?

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.

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

(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.

Ok, I tested on my system. Need to re-test with LiveCD.

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 ;)

(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

(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.

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

confirmed the fix after removing consolekit*

@ 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.

*** Bug 986621 has been marked as a duplicate of this bug. ***

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.

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.

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.

I think this one should be closed by now.