Xfce Forum

Sub domains
 

You are not logged in.

#1 2013-05-05 19:03:34

bremsstrahlung
Member
From: Central Europe
Registered: 2012-08-31
Posts: 6

[Solved] bug in xfce4-session 4.10.1?

Today, xfce4-session 4.10.1 was released and I was quick to compile it, amongst all the other updates released today, and benefit from its improvements. At least, so I thought... :-/ Trouble is, that the shutdown and reboot buttons are now barred by a dialogue field asking for a password. Unfortunately the form doesn't accept any input so the only remedy is to dismiss it.

I doubt the error is on my side. I compiled all the new stuff in the order that is suggested in the documentation. I even went through the hassle of recompiling the entire desktop environment in the suggested order - yet the problem remained. Reverting to 4.10.0 immediately fixes the problem. Before, there has never been such an issue and I did not touch any permissions. I should mention that the dialogue box is not triggered when merely signing off.

It seems the update is doing something the author didn't exactly had in mind, so perhaps you may want to check again. I'm using a self compiled XFCE 4.10 environment using the latest stable versions of the components on Debian Wheezy and apart from the occasional rearrangement of my desktop icons (which I have a back up file for, like many others affected by the bug), I did not encountered any undesired effects.

Thanks for looking into that matter.


Man's achievements rest upon the use of symbols - Alfred Korzybski

Offline

#2 2013-05-06 07:39:11

bremsstrahlung
Member
From: Central Europe
Registered: 2012-08-31
Posts: 6

Re: [Solved] bug in xfce4-session 4.10.1?

A quick follow-up:
Tried xfce4-session 4.10.1 on my laptop (similar environment as my workstation) and get the same result:
- logout works.
- reboot, shut down asks for password to sign off, but form doesn't accept any input.

normally, there should be no dialogue at all, unless root happens to be logged in on one of the consoles. And again, normality returns with reverting to version 4.10.0.
If needed, I can provide a screenshot of the dialogue (I saved one just in case).


Man's achievements rest upon the use of symbols - Alfred Korzybski

Offline

#3 2013-05-07 06:08:26

MountainDewManiac
Member
From: USA police-state welfare-state
Registered: 2013-03-24
Posts: 346

Re: [Solved] bug in xfce4-session 4.10.1?

Could it be that it assumes a new setting which determines whether or not a password shall be required for that session - but there was not actually a setting added yet? Or that there is not yet a newer version of whichever component of Xfce deals with settings, so there is no way to "set" such a setting as of yet?

Offline

#4 2013-05-07 07:33:24

bremsstrahlung
Member
From: Central Europe
Registered: 2012-08-31
Posts: 6

Re: [Solved] bug in xfce4-session 4.10.1?

MountainDewManiac wrote:

Could it be that it assumes a new setting which determines whether or not a password shall be required for that session - but there was not actually a setting added yet?

I took it from the official ticker tape:
http://archive.xfce.org/feeds/project/?C=M;O=D

The update is considered "stable", thus - by definition - it should only deal with bugs or things safe to update - like documentation or translations. Therefore, I assume things are meant to work the same way as its predecessor (apart from the dropped gnome-keyring support which was disabled by default anyway).

Or that there is not yet a newer version of whichever component of Xfce deals with settings, so there is no way to "set" such a setting as of yet?

That could be true if it were a development release, but a minor update of the stable series is unlikely to behave like this. I suppose the best way of analysing what happens is to create a diff between the two versions and see which part of the updated code breaks things. May have a look at it later today when I'll return home from work.

Last edited by bremsstrahlung (2013-05-07 07:34:01)


Man's achievements rest upon the use of symbols - Alfred Korzybski

Offline

#5 2013-05-07 17:18:43

bremsstrahlung
Member
From: Central Europe
Registered: 2012-08-31
Posts: 6

Re: [Solved] bug in xfce4-session 4.10.1?

Meanwhile I looked into the source code and found the root cause and a workaround pretty fast, actually...

There was a major change concerning support for systemd systems. The problem is that the check for such system is based on an errorneous assumption, namely a policy kit library not immediately associated with the systemd package. That logic error led in my case to the error message on reboot or shutdown.

diff of xfce4-session/xfsm-shutdown.c

--- xfce4-session-4.10.0/xfce4-session/xfsm-shutdown.c	2012-04-28 22:43:27.000000000 +0200
+++ xfce4-session-4.10.1/xfce4-session/xfsm-shutdown.c	2013-05-05 17:33:55.000000000 +0200
@@ -66,10 +66,13 @@
 #include <xfce4-session/xfsm-fadeout.h>
 #include <xfce4-session/xfsm-global.h>
 #include <xfce4-session/xfsm-legacy.h>
-#include <xfce4-session/xfsm-consolekit.h>
 #include <xfce4-session/xfsm-upower.h>
 
-
+#ifdef HAVE_SYSTEMD
+#include <xfce4-session/xfsm-systemd.h>
+#else
+#include <xfce4-session/xfsm-consolekit.h>
+#endif
 
 static void xfsm_shutdown_finalize  (GObject      *object);
 static void xfsm_shutdown_sudo_free (XfsmShutdown *shutdown);
@@ -93,7 +96,11 @@
 {
   GObject __parent__;
 
+#ifdef HAVE_SYSTEMD
+  XfsmSystemd    *systemd;
+#else
   XfsmConsolekit *consolekit;
+#endif
   XfsmUPower     *upower;
 
   /* kiosk settings */
@@ -131,7 +138,11 @@
 {
   XfceKiosk *kiosk;
 
+#ifdef HAVE_SYSTEMD
+  shutdown->systemd = xfsm_systemd_get ();
+#else
   shutdown->consolekit = xfsm_consolekit_get ();
+#endif
   shutdown->upower = xfsm_upower_get ();
   shutdown->helper_state = SUDO_NOT_INITIAZED;
   shutdown->helper_require_password = FALSE;
@@ -150,7 +161,11 @@
 {
   XfsmShutdown *shutdown = XFSM_SHUTDOWN (object);
 
+#ifdef HAVE_SYSTEMD
+  g_object_unref (G_OBJECT (shutdown->systemd));
+#else
   g_object_unref (G_OBJECT (shutdown->consolekit));
+#endif
   g_object_unref (G_OBJECT (shutdown->upower));
 
   /* close down helper */
@@ -269,9 +284,9 @@
       signal (SIGPIPE, SIG_IGN);
 
       /* setup environment */
-      xfce_setenv ("LC_ALL", "C", TRUE);
-      xfce_setenv ("LANG", "C", TRUE);
-      xfce_setenv ("LANGUAGE", "C", TRUE);
+      g_setenv ("LC_ALL", "C", TRUE);
+      g_setenv ("LANG", "C", TRUE);
+      g_setenv ("LANGUAGE", "C", TRUE);
 
       /* setup the 3 standard file handles */
       dup2 (child_pipe[0], STDIN_FILENO);
@@ -641,7 +656,11 @@
   if (shutdown->helper_state == SUDO_AVAILABLE)
     return xfsm_shutdown_sudo_try_action (shutdown, XFSM_SHUTDOWN_RESTART, error);
   else
+#ifdef HAVE_SYSTEMD
+    return xfsm_systemd_try_restart (shutdown->systemd, error);
+#else
     return xfsm_consolekit_try_restart (shutdown->consolekit, error);
+#endif
 }
 
 
@@ -658,7 +677,11 @@
   if (shutdown->helper_state == SUDO_AVAILABLE)
     return xfsm_shutdown_sudo_try_action (shutdown, XFSM_SHUTDOWN_SHUTDOWN, error);
   else
+#ifdef HAVE_SYSTEMD
+    return xfsm_systemd_try_shutdown (shutdown->systemd, error);
+#else
     return xfsm_consolekit_try_shutdown (shutdown->consolekit, error);
+#endif
 }
 
 
@@ -698,7 +721,11 @@
       return TRUE;
     }
 
+#ifdef HAVE_SYSTEMD
+  if (xfsm_systemd_can_restart (shutdown->systemd, can_restart, error))
+#else
   if (xfsm_consolekit_can_restart (shutdown->consolekit, can_restart, error))
+#endif
     return TRUE;
 
   if (xfsm_shutdown_sudo_init (shutdown, error))
@@ -725,7 +752,11 @@
       return TRUE;
     }
 
+#ifdef HAVE_SYSTEMD
+  if (xfsm_systemd_can_shutdown (shutdown->systemd, can_shutdown, error))
+#else
   if (xfsm_consolekit_can_shutdown (shutdown->consolekit, can_shutdown, error))
+#endif
     return TRUE;
 
   if (xfsm_shutdown_sudo_init (shutdown, error))

note the addition of the systemd flags and what their activation causes for sysv-based systems ;-)


what ./configure --disable-debug does

./configure --disable-debug
[...]
checking for polkit-gobject-1 >= 0.100... 0.105
checking SYSTEMD_CFLAGS... -pthread -I/usr/include/polkit-1 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include  
checking SYSTEMD_LIBS... -lpolkit-gobject-1 -lgio-2.0 -lgobject-2.0 -lglib-2.0
[...]

Yes, you read it correctly - this is the detection logic that decides whether a system is based on systemd or the traditional sysvinit.
That's the result in config.h:

[...]
/* Define if polkit-gobject-1 >= 0.100 present */
#define HAVE_SYSTEMD 1
[...]

oops.. ;-) And that's enough to trigger the broken password dialogue on reboot or shutdown for sysvinit users

But fear not, it's not all in vain. Fortunately, the addition of the new code resulted in new ./configure flags, too. The one sysvinit users should be interested in is --disable-systemd.

My workaround is to explicitly compile the package with: ./configure --disable-debug --disable-systemd

-> no checks during configure and no HAVE:SYSTEMD define in config.h. -> systemd code remains inactive -> reboot and shut down work as expected -> problem solved ;-)


Man's achievements rest upon the use of symbols - Alfred Korzybski

Offline

#6 2013-05-07 19:31:44

MountainDewManiac
Member
From: USA police-state welfare-state
Registered: 2013-03-24
Posts: 346

Re: [Solved] bug in xfce4-session 4.10.1?

Great, glad you were able to fix it on your system. I hope you were able to forward the above to the developers so that your effort helps everyone.

Best regards,
MDM

Offline

#7 2013-05-07 20:03:04

bremsstrahlung
Member
From: Central Europe
Registered: 2012-08-31
Posts: 6

Re: [Solved] bug in xfce4-session 4.10.1?

MountainDewManiac wrote:

Great, glad you were able to fix it on your system.

I am, too ;-)

I hope you were able to forward the above to the developers so that your effort helps everyone.

I wasn't trying, because I assume the forums are frequented by the developers, too. Since the issue can be resolved by using a configure option, it really isn't much of a show stopper, just a minor nuisance one should be aware of. Others affected by the issue will eventually find this thread with a simple Google search (or whatever search engine they prefer), so eventually they too can solve the problem.

Last edited by bremsstrahlung (2013-05-07 20:04:04)


Man's achievements rest upon the use of symbols - Alfred Korzybski

Offline

Board footer

Powered by FluxBB