The Monitor returned an error [org.freedesktop.DBus.Error.NoReply]

[Mathias Gug]

Hi,

While trying to start sssd 0.5.0 on an Ubuntu Karmic system, I've run
into the following error:

[sssd[dp]] [id_callback] (0): The Monitor returned an error
[org.freedesktop.DBus.Error.NoReply]
[sssd] [global_checks_handler] (0): Unknown child (2552) did exit
[sssd[nss]] [sss_dp_init] (0): Failed to connect to monitor services.
[sssd[nss]] [sss_process_init] (0): fatal error setting up backend connector
[sssd[be[files]]] [be_cli_init] (0): Failed to connect to monitor services.
[sssd[be[files]]] [be_process_init] (0): fatal error setting up server bus
[sssd[be[files]]] [main] (0): Could not initialize backend [5]
[sssd[pam]] [sss_dp_init] (0): Failed to connect to monitor services.
[sssd[pam]] [sss_process_init] (0): fatal error setting up backend connector
[sssd] [global_checks_handler] (0): Unknown child (2553) did exit
[sssd] [global_checks_handler] (0): Unknown child (2554) did exit
[sssd] [global_checks_handler] (0): Unknown child (2555) did exit
[sssd[nss]] [sss_dp_init] (0): Failed to connect to monitor services.
[sssd[nss]] [sss_process_init] (0): fatal error setting up backend connector
[sssd[pam]] [sss_dp_init] (0): Failed to connect to monitor services.
[sssd[pam]] [sss_process_init] (0): fatal error setting up backend connector
[sssd[be[files]]] [be_cli_init] (0): Failed to connect to monitor services.
[sssd[be[files]]] [be_process_init] (0): fatal error setting up server bus
[sssd[be[files]]] [main] (0): Could not initialize backend [5]
[sssd[nss]] [sss_dp_init] (0): Failed to connect to monitor services.
[sssd[nss]] [sss_process_init] (0): fatal error setting up backend connector
[sssd[pam]] [sss_dp_init] (0): Failed to connect to monitor services.
[sssd[pam]] [sss_process_init] (0): fatal error setting up backend connector
[...]

dbus is installed and running:

$ ps -ef | grep dbus
106       2382     1  0 21:27 ?        00:00:00 /bin/dbus-daemon --system

The sssd configuration is the example configuration with using the
LOCAL domain (/etc/sssd/sssd.conf):

[services]
description = Local Service Configuration
activeServices = nss, dp, pam
# Number of times services should attempt to reconnect in the
# event of a Data Provider crash or restart before they give up
reconnection_retries = 3

[services/nss]
description = NSS Responder Configuration
# the following prevents sssd for searching for the root user/group in
# all domains (you can add here a comma separated list of system accounts are
# always going to be /etc/passwd users, or that you want to filter out)
filterGroups = root
filterUsers = root

[services/dp]
description = Data Provider Configuration

[services/pam]
description = PAM Responder Configuration

[services/monitor]
description = Service Monitor Configuration
#if a backend is particularly slow you can raise this timeout here
sbusTimeout = 30

[domains]
description = Domains served by SSSD
domains = LOCAL

[domains/LOCAL]
description = LOCAL migration domain
enumerate = 3
minId = 500
magicPrivateGroups = FALSE
legacy = TRUE

provider = files

-- 
Mathias Gug
Ubuntu Developer  http://www.ubuntu.com

[Simo Sorce]

On Mon, 2009-08-24 at 21:45 -0400, Mathias Gug wrote:
>  
>  While trying to start sssd 0.5.0 on an Ubuntu Karmic system, I've run
>  into the following error: 
Can you start it manually with debug level 4 ?

sssd -i -d 4


Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/25/2009 08:39 AM, Simo Sorce wrote:
>  On Mon, 2009-08-24 at 21:45 -0400, Mathias Gug wrote:
> >
> > While trying to start sssd 0.5.0 on an Ubuntu Karmic system, I've run
> > into the following error:
>  
>  Can you start it manually with debug level 4 ?
>  
>  sssd -i -d 4
>  
>  
>  Simo.
>   
I can reproduce this at will on my Ubuntu VM. For some reason, none of
the services are sending their identity (or at least getting it TO the
monitor) so the monitor is killing them off.

Strangely, the services sending it are also seeing the monitor returning
NoReply. I think it may be a bug in their version of libdbus.

- -- 
Stephen Gallagher
RHCE 804006346421761

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkqT4lYACgkQeiVVYja6o6MonACfXtJEz7Z0j7ZaP1nN9WZsTzTl
> Rm8AnRppdicK06Q7FuoSuAFlc9HBR1wj
> =IWi5
> -----END PGP SIGNATURE-----

[Mathias Gug]

Hi,

On Tue, Aug 25, 2009 at 9:08 AM, Stephen Gallagher<sgallagh(a)redhat.com> wrote:
>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  I can reproduce this at will on my Ubuntu VM. For some reason, none of
>  the services are sending their identity (or at least getting it TO the
>  monitor) so the monitor is killing them off.
>
>  Strangely, the services sending it are also seeing the monitor returning
>  NoReply. I think it may be a bug in their version of libdbus.
>  
It seems that the dbus security file is not installed. If there's no
security policy, then the bus daemon will *deny*  all messages. It's
probably even refused the service from registering any name on the bus
to begin with.

Is there is a Dbus security file in the released tarball?

-- 
Mathias Gug
Ubuntu Developer  http://www.ubuntu.com

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/25/2009 01:06 PM, Mathias Gug wrote:
>  Hi,
>  
>  On Tue, Aug 25, 2009 at 9:08 AM, Stephen Gallagher<sgallagh(a)redhat.com> wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > I can reproduce this at will on my Ubuntu VM. For some reason, none of
> > the services are sending their identity (or at least getting it TO the
> > monitor) so the monitor is killing them off.
> >
> > Strangely, the services sending it are also seeing the monitor returning
> > NoReply. I think it may be a bug in their version of libdbus.
> >
>  
>  It seems that the dbus security file is not installed. If there's no
>  security policy, then the bus daemon will *deny*  all messages. It's
>  probably even refused the service from registering any name on the bus
>  to begin with.
>  
>  Is there is a Dbus security file in the released tarball?
>   
Mathias, we're not using the system bus, we are using the D-BUS protocol
internally only. No security file is needed. Can you join us in #freeipa
to discuss this matter in depth?

- -- 
Stephen Gallagher
RHCE 804006346421761

Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkqUGqMACgkQeiVVYja6o6MYhACfQNO1aP7qsqrqyviU8PsFlDut
> XHoAmgOlgR5xTXddDev3TJQPPOk7SD3a
> =qxYz
> -----END PGP SIGNATURE-----