users and groups prog does not work on first launch

Does this happen with a more recent version of Karmic? The authentication system has been updated. Thanks!

Still happening here, yes, but the error dialog box has changed from:
"The configuration could not be loaded
You are not allowed to access the system configuration"

to:
"The configuration could not be loaded
An unknown error occurred"

Other than that, it is the same symptom. Users & Groups runs as expected if started a second time and all subsequent runs during session.

Hey, glad my recent fixes helped making things clearer... :-p

So the explanation to that change is that we now make the distinction between error types, and no longer consider there's an "access denied' issue. This is useful to get more information about your problem, which has visibly nothing to do with permissions.

Could you run 'sudo killall system-tools-backends; system-tools-backends -nd' and post the result here? That should definitely help. Thanks!

Thanks for getting on this. Looks like system-tools-backends is not started by default and should be. Everything works as expected when following the instructions above:

marc@galvatron:~$ sudo killall system-tools-backends
[sudo] password for marc:
system-tools-backends: no process found
marc@galvatron:~$ sudo system-tools-backends -nd
** (system-tools-backends:3655): DEBUG: dispatching message to: /org/freedesktop/SystemToolsBackends/Platform
** (system-tools-backends:3655): DEBUG: sending reply from: /org/freedesktop/SystemToolsBackends/Platform
** (system-tools-backends:3655): DEBUG: dispatching message to: /org/freedesktop/SystemToolsBackends/UsersConfig
** (system-tools-backends:3655): DEBUG: dispatching message to: /org/freedesktop/SystemToolsBackends/GroupsConfig
** (system-tools-backends:3655): DEBUG: dispatching message to: /org/freedesktop/SystemToolsBackends/UserConfig
** (system-tools-backends:3655): DEBUG: dispatching message to: /org/freedesktop/SystemToolsBackends/Platform
** (system-tools-backends:3655): DEBUG: sending reply from: /org/freedesktop/SystemToolsBackends/Platform
** (system-tools-backends:3655): DEBUG: sending reply from: /org/freedesktop/SystemToolsBackends/GroupsConfig
** (system-tools-backends:3655): DEBUG: dispatching message to: /org/freedesktop/SystemToolsBackends/Platform
** (system-tools-backends:3655): DEBUG: sending reply from: /org/freedesktop/SystemToolsBackends/Platform
** (system-tools-backends:3655): DEBUG: sending reply from: /org/freedesktop/SystemToolsBackends/UsersConfig
** (system-tools-backends:3655): DEBUG: dispatching message to: /org/freedesktop/SystemToolsBackends/Platform
** (system-tools-backends:3655): DEBUG: sending reply from: /org/freedesktop/SystemToolsBackends/Platform
** (system-tools-backends:3655): DEBUG: sending reply from: /org/freedesktop/SystemToolsBackends/UserConfig

Well, the backends should not be started on boot, since they should start automatically when needed. Could you attach here your /var/log/syslog, /var/log/auth.log and /var/log/messages after having tried to run the users config tool (without starting it manually as in the previous post)?

Also, the output of 'apt-cache policy system-tools-backends gnome-system-tools' would be useful. Doesn't running 'users-admin' from a console print any error message? Thanks!

I'm sorry to say that absolutely nothing is logged in syslog, auth.log, message, kern.log, debug, daemon.log or user.log.

It appears to fail silently (other than the dialog telling me it failed!). Also output when run from the terminal is identical to a successful run, so nothing to gather there:

marc@galvatron:~$ users-admin

(users-admin:3557): GLib-GIO-WARNING **: g_simple_async_result_complete() called from outside main loop!

(users-admin:3557): GLib-GIO-WARNING **: g_simple_async_result_complete() called from outside main loop!

(users-admin:3557): GLib-GIO-WARNING **: g_simple_async_result_complete() called from outside main loop!

marc@galvatron:~$ apt-cache policy system-tools-backends gnome-system-tools
system-tools-backends:
  Installed: 2.8.1-0ubuntu1
  Candidate: 2.8.1-0ubuntu1
  Version table:
 *** 2.8.1-0ubuntu1 0
        500 http://us.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status
gnome-system-tools:
  Installed: 2.27.3-0ubuntu1
  Candidate: 2.27.3-0ubuntu1
  Version table:
 *** 2.27.3-0ubuntu1 0
        500 http://us.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

Let me know what else I can try to get more verbose debugging information from users-admin. Thanks

You could try the following procedure, which will help but won't really tell us what's the root problem:
- run users-admin for the first time
- type 'ps ax | grep -i backends'
- reproduce the procedure once again

This way we would know if the tools are started the first time, possibly with a delay. But I'd need the help of a D-Bus guru to get the required logs.

Another thing: do you experience the same problem with time-admin and services-admin?

>do you experience the same problem with time-admin and services-admin?

Yes I do, for time-admin, services-admin, and of course users-admin

system-tools-backends is indeed started prior to this error

marc@galvatron:~$ ps ax | grep -i backends
 3587 ? Ss 0:00 /usr/sbin/system-tools-backends
 3615 pts/0 S+ 0:00 grep -i backends

I've attached a screenshot of the process you requested and the resulting error dialog box.

The one difference I spot with system-tools-backends is with the process state code.

Prior to first attempt, (fresh boot) it is S+ (Interruptible sleep, is in the foreground process group).

Subsequently, it is Ss (Interruptible sleep, is a session leader).

I am not savvy enough to determine if this is normal or if it is an indication or clue as to the problem.

I guess you meant "prior to second attempt". On fresh boot, before starting users-admin, the stb should not be running (as on your screenshot).

A standard way to get information would be to use gdb. Can you try "pidof system-tools-backends; gdb attach <PID>" and then "thread apply all bt"? I guess you'll need to install debug symbols packages for the traces to be readable to me. You should install those packages (if you're using the 32 buts version):
http://ddebs.ubuntu.com/pool/main/g/gnome-system-tools/gnome-system-tools-dbgsym_2.27.3-0ubuntu1_i386.ddeb
http://ddebs.ubuntu.com/pool/main/g/glibc/libc6-dbgsym_2.9-4ubuntu6_i386.ddeb

Else you can add the line
deb http://ddebs.ubuntu.com karmic main restricted universe multiverse
to /etc/apt/sources.list, and then install the packages gnome-system-tools-dbgsym and libc6-dbgsym. See https://wiki.ubuntu.com/Backtrace (same result).

I know that's a little complex, but that could help. Thanks!

Nope, I meant prior to first attempt. The screenshot is taken upon fresh
boot. I can replicate it every time by booting, starting gnome-terminal,
then
ps ax | grep -i backends

always returns what was shown in the screenshot. I'll give the debug symbols
a shot tomorrow.

On Sun, Aug 30, 2009 at 4:18 PM, Milan Bouchet-Valat <email address hidden>wrote:

> I guess you meant "prior to second attempt". On fresh boot, before
> starting users-admin, the stb should not be running (as on your
> screenshot).
>
> A standard way to get information would be to use gdb. Can you try "pidof
> system-tools-backends; gdb attach <PID>" and then "thread apply all bt"? I
> guess you'll need to install debug symbols packages for the traces to be
> readable to me. You should install those packages (if you're using the 32
> buts version):
>
> http://ddebs.ubuntu.com/pool/main/g/gnome-system-tools/gnome-system-tools-dbgsym_2.27.3-0ubuntu1_i386.ddeb
>
> http://ddebs.ubuntu.com/pool/main/g/glibc/libc6-dbgsym_2.9-4ubuntu6_i386.ddeb
>
> Else you can add the line
> deb http://ddebs.ubuntu.com karmic main restricted universe multiverse
> to /etc/apt/sources.list, and then install the packages
> gnome-system-tools-dbgsym and libc6-dbgsym. See
> https://wiki.ubuntu.com/Backtrace (same result).
>
> I know that's a little complex, but that could help. Thanks!
>
> --
> users and groups prog blocked on first launch
> https://bugs.launchpad.net/bugs/411533
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>
> Status in “gnome-system-tools” package in Ubuntu: Incomplete
>
> Bug description:
> Binary package hint: gnome-system-tools
>
> Upon launching the users and group dialogue You get at "You don't have
> privileges" notification and no dialogue.
>
> Launch users and groups a second time and everything is fine.
>
> Though the `Unlock' button seems to have become a `_Unlock' button
>
>
> xprop WM_CLASS give users-admin as the name but this isn't a package.
> gnome-system-tools seems likley
>
>
>
> Karmic Alpha 3
>

Nope, I meant prior to first attempt. The screenshot is taken upon fresh boot. I can replicate it every time by booting, starting gnome-terminal, then

ps ax | grep -i backends

always returns what was shown in the screenshot. I'll give the debug symbols a whirl tomorrow.

What the screenshot shows is actually that the backends are not running. The only line returned is about the command 'grep -i backends' showing itself (stupid, I know).

So the line that shows us that the backends are running is:
 3587 ? Ss 0:00 /usr/sbin/system-tools-backends
(which may/should be completed with one line per configuration module if you're using them)

Thanks for your work investigating!

Doh! Of course that's the case. Silly of me. I think I am just hoping for something to be obviously wrong. Sorry 'bout that.

No-go so far with debug symbols. Running into this:

$ sudo gdebi libc6*.deb
Reading package lists: Done
Reading state information: Done
Reading state information: Done
Reading state information: Done
Analysing dependencies: 00 /usr/lib/python2.6/dist-packages/GDebi/DebPackage.py:273: DeprecationWarning: Accessed deprecated property Package.installedDependencies, please see the Version class for alternatives.
  for dep_or in pkg.installedDependencies:
Reading state information: Done
/usr/lib/python2.6/dist-packages/GDebi/DebPackage.py:78: DeprecationWarning: Accessed deprecated property Package.installedVersion, please see the Version class for alternatives.
  instver = inst.installedVersion
This package is uninstallable
Dependency is not satisfiable: libc6 (= 2.9-4ubuntu6)

Is this because of my newer version of libc6?

$ apt-cache policy libc6
libc6:
  Installed: 2.10.1-0ubuntu8
  Candidate: 2.10.1-0ubuntu8
  Version table:
 *** 2.10.1-0ubuntu8 0
        500 http://us.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

Okay, installed the latest from the repository:

$ apt-cache policy libc6-dbgsym
libc6-dbgsym:
  Installed: 2.10.1-0ubuntu8
  Candidate: 2.10.1-0ubuntu8
  Version table:
 *** 2.10.1-0ubuntu8 0
        500 http://ddebs.ubuntu.com karmic/main Packages
        500 http://ddebs.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

$ pidof system-tools-backends
3991

$ sudo gdb attach 3991
[sudo] password for marc:
GNU gdb (GDB) 6.8.50.20090628-cvs-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
attach: No such file or directory.
Attaching to process 3991
Reading symbols from /usr/sbin/system-tools-backends...(no debugging symbols found)...done.
Reading symbols from /usr/lib/libdbus-glib-1.so.2...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libdbus-glib-1.so.2
Reading symbols from /lib/libdbus-1.so.3...(no debugging symbols found)...done.
Loaded symbols for /lib/libdbus-1.so.3
Reading symbols from /lib/tls/i686/cmov/libpthread.so.0...(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
Loaded symbols for /lib/tls/i686/cmov/libpthread.so.0
Reading symbols from /lib/tls/i686/cmov/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/librt.so.1
Reading symbols from /usr/lib/libpolkit-gobject-1.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libpolkit-gobject-1.so.0
Reading symbols from /usr/lib/libgio-2.0.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgio-2.0.so.0
Reading symbols from /usr/lib/libgobject-2.0.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgobject-2.0.so.0
Reading symbols from /usr/lib/libgmodule-2.0.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libgmodule-2.0.so.0
Reading symbols from /usr/lib/libglib-2.0.so.0...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libglib-2.0.so.0
Reading symbols from /lib/tls/i686/cmov/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2...Reading symbols from /usr/lib/debug/lib/ld-2.10.1.so...done.
done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/lib/libeggdbus-1.so.0...done.
Loaded symbols for /usr/lib/libeggdbus-1.so.0
Reading symbols from /lib/tls/i686/cmov/libdl.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libdl.so.2
Reading symbols from /lib/libpcre.so.3...done.
Loaded symbols for /lib/libpcre.so.3
Reading symbols from /lib/tls/i686/cmov/libresolv.so.2...done.
Loaded symbols for /lib/tls/i686/cmov/libresolv.so.2
Reading symbols from /lib/libselinux.so.1...done.
Loaded symbols for /lib/libselinux.so.1
0x009da422 in __kernel_vsyscall ()
(gdb) thread apply all bt

Thread 1 (Thread 0xb806972...

Much thanks for achieving that painful task. Comparing with normal behavior of the backends, it seems that everything is working fine, i.e. it's waiting for calls from D-Bus - which is quite sad for solving this bug... :-p

So it could be more of a D-Bus issue. Could you run 'sudo dbus-monitor --system' and then run users-admin twice, separating the two logs (type a few RETURN in the console before you run it the second time)? I'm still hoping some error message could be shown.

Else, you could 'sudo killall polkitd; sudo /usr/libexec/polkitd' and then try running users-admin, and posting the logs from polkitd. I could be that polkitd is blocking the backends for some reason before they can answer to the GUI...

Another question: do you see an important delay when starting users-admin for the first time? It could be that the timeout is reached for some reason, while subsequent calls go faster.

If these don't help, we can still go into the gst/liboobs code to get the D-Bus returned error codes more precisely.

I don't see any abnormal delay. When it fails, it fails much more quickly than the time it takes to launch successfully.

I've attached the dbus information. Not much to glean there, it seems. Also, got nothing from polkitd for either a failed or successful run:

$ sudo /usr/lib/policykit/polkitd
(polkitd:3850): polkitd-DEBUG: Starting polkitd version 0.9
(polkitd:3850): polkitd-DEBUG: Setting killtimer to 30 seconds...
(polkitd:3850): polkitd-DEBUG: Exiting due to inactivity
$ sudo /usr/lib/policykit/polkitd
(polkitd:3880): polkitd-DEBUG: Starting polkitd version 0.9
(polkitd:3880): polkitd-DEBUG: Setting killtimer to 30 seconds...
(polkitd:3880): polkitd-DEBUG: Exiting due to inactivity

Sorry, the path to the PolicyKit1 daemon seems to be /usr/lib/policykit-1/polkitd in Karmic (and not /usr/lib/policykit-1/polkitd as in my custom install). You were starting the daemon version 0.9, which did not get any calls (as it should).

The D-Bus logs don't show much, but at least we can check that the backends dispatcher is started, while no other module is loaded. You can see on the successful log that org.freedesktop.SystemToolBackends.Platform is started, which is where errors often happen. Here, the problem occurs earlier. PolicyKit should not be involved at all at this point.

We can try getting the D-Bus error from liboobs. You should install
http://ddebs.ubuntu.com/pool/main/libo/liboobs/liboobs-1-4-dbgsym_2.22.0-2ubuntu1_i386.ddeb
end then run 'gdb users-admin', then type 'break oobs-session.c:316', then when it has stopped at the breakpoint, 'print priv->dbus_error.message'. If this does not work, you may want to stop at line 308 instead. In the new version, I'll print this error message to the console to make things simpler.

hmm... something not quite right with this.

$ gdb users-admin
GNU gdb (GDB) 6.8.50.20090628-cvs-debian
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(gdb) break oobs-session:316
No source file named oobs-session.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (oobs-session:316) pending.
(gdb) print priv->dbus_error.message
No symbol "priv" in current context.
(gdb) quit

$ apt-cache policy liboobs-1-4 liboobs-1-4-dbgsym
liboobs-1-4:
  Installed: 2.22.0-2ubuntu1
  Candidate: 2.22.0-2ubuntu1
  Version table:
 *** 2.22.0-2ubuntu1 0
        500 http://us.archive.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status
liboobs-1-4-dbgsym:
  Installed: 2.22.0-2ubuntu1
  Candidate: 2.22.0-2ubuntu1
  Version table:
 *** 2.22.0-2ubuntu1 0
        500 http://ddebs.ubuntu.com karmic/main Packages
        500 http://ddebs.ubuntu.com karmic/main Packages
        100 /var/lib/dpkg/status

Oh, I forgot to say you need to type 'run' after setting the breakpoint, so that the program is started. It may still not work, but without it we're sure we'll get nothing...

(And the break point is in "oobs-session.c", not just "oobs-session".)

Right. I've become a little more familiar with backtraces and such due to other issues. Log attached.

Good catch! Thanks for going until that point in debugging.

This extract from the log explains that's going on:
"Launch helper exited with unknown return code 0"

So the problem is on D-Bus side, it seems that the program responsible for starting the Platform backend exited without returning an error (0 means success). I don't know whether this can mean that the backend exited too early, or that the launch helper itself has a problem.

I hope somebody familiar with D-Bus can help us on that point.

It occurred to me just now: is there anything interesting in /var/log/daemon.log that isn't in the other journals? I've just found bug 231180 about users-admin reporting the very same error, but with different symptoms.

And even more interestingly, bug 332050 is about a problem with bzr-gtk failing to work *the first time it is run* because of the seahorse D-Bus service. So that problem is not only with the gnome-system-tools.

Okay, apparently this problem could come from the fact that the backends daemonize when activated from D-Bus. The problem is, I don't think the modules actually daemonize.

Could you try to change in /usr/share/dbus-1/system-services/org.freedesktop.SystemToolsBackends.service the line
Exec=/opt/gnome/sbin/system-tools-backends
to
Exec=/opt/gnome/sbin/system-tools-backends -n

> Exec=/opt/gnome/sbin/system-tools-backends -n

Following this change, I am unable to replicate the issue! I have power cycled and booted 7 consecutive times followed by launching users-admin on 5 occasions and time-admin and services-admin once each. Previously, I could replicate this 100% of the time at every boot.

It is fantastic that you seem to have isolated the cause/fix for this, but I have been curious all the while if this problem is a result of upgrading from previous releases? Perhaps something that was changed in a package, but not applied during the upgrade process? My next step was to do a clean install of alpha 5 in a VM and try to spot the differences. I assume, due to the lack of activity on this bug that this does not affect people using karmic installed clean from an alpha.

Cool! This problem must have appeared in Karmic, since in previous releases the backends were started at boot time before they were actually needed (which is wrong BTW). But I really don't see how it could affect some users and not all of them. And still I don't have seen other reports about that.

Were you able to reproduce the bug with a clean Karmic install in a VM? I'd expect so, but...

I'll do some research, and make this fix available by the next release, which should be in Karmic. Thanks for your patience!

Yes, this bug does indeed affect Karmic Alpha 5. I'm really surprised now that this bug report is so low-key.

STR:

1) Boot karmic alpha 5 live CD
2) Launch System > Administration > Users and Groups

Fails with same error dialog reported here earlier:

"The configuration could not be loaded
An unknown error occurred"

Comment #26 fixed it for me :)

Thanks Milan

#26 worked for me also

Indeed, Chris Coulson also found out that d-bus activated services don't play well with forking. And they don't really have to, either. So we will just pass --no-daemon.

I'll release the fix soon as part of 2.8.2.

Uploaded

This bug was fixed in the package system-tools-backends - 2.8.1-0ubuntu2

---------------
system-tools-backends (2.8.1-0ubuntu2) karmic; urgency=low

  * debian/patches/07_dont_fork_on_dbus_activation.patch:
    - Don't fork the dispatcher when activated by DBus, as it makes
      DBus think that activation failed (LP: #411533)

 -- Chris Coulson <email address hidden> Thu, 01 Oct 2009 23:50:03 +0200