kcm fails to start if /var/lib/sss/db is empty

[joakim-tjernlund]

Booting a freshly installed machine fails to start kcm when /var/lib/sss/db is empty.
Boot log(from Gentoo, openrc) I have:

[sssd] [get_monitor_config] (0x0010): No services configured!                                   
[sssd] [main] (0x0010): SSSD couldn't load the configuration database.                          
 * ERROR: sssd-kcm failed to start                                                              
 * Starting sssd ... 

[alexey-tikhonov]

Does main sssd process start completely before kcm in your case?

[joakim-tjernlund]

It does, but kcm should not depend on sssd, right?

[justin-stephenson]

Does gentoo/openrc execute /usr/sbin/sssd --genconf-section=kcm on startup? What is the order of service startup if gentoo/openrc is not using systemd?

Is the issue that this command fails when /var/lib/sss/db/ is empty?

[joakim-tjernlund]

Does gentoo/openrc execute /usr/sbin/sssd --genconf-section=kcm on startup? What is the order of service startup if gentoo/openrc is not using systemd?

Yes, openrc init scripte has:

start_pre()
{
    "/usr/sbin/sssd" --genconf-section=kcm || return $?
}

Order is kcm starts before sssd.

Is the issue that this command fails when /var/lib/sss/db/ is empty?

Yes, as far as I can tell.

[joakim-tjernlund]

Here is a log with debug:

/usr/sbin/sssd -d=9 --genconf-section=kcm
[sssd] [ldb] (0x0400): server_sort:Unable to register control with rootdse!
[sssd] [sss_confdb_create_ldif] (0x0400): Processing config section [sssd]
[sssd] [sss_confdb_create_ldif] (0x0400): Skipping section sssd
[sssd] [sss_confdb_create_ldif] (0x0400): Processing config section [nss]
[sssd] [sss_confdb_create_ldif] (0x0400): Skipping section nss
[sssd] [sss_confdb_create_ldif] (0x0400): Processing config section [kcm]
[sssd] [sss_confdb_create_ldif] (0x0400): Processing attribute [responder_idle_timeout]
[sssd] [sss_confdb_create_ldif] (0x4000): responder_idle_timeout: 0

[sssd] [sss_confdb_create_ldif] (0x0400): Processing attribute [tgt_renewal]
[sssd] [sss_confdb_create_ldif] (0x4000): tgt_renewal: true

[sssd] [sss_confdb_create_ldif] (0x0400): Processing attribute [krb5_renewable_lifetime]
[sssd] [sss_confdb_create_ldif] (0x4000): krb5_renewable_lifetime: 7d

[sssd] [sss_confdb_create_ldif] (0x0400): Processing attribute [krb5_lifetime]
[sssd] [sss_confdb_create_ldif] (0x4000): krb5_lifetime: 10h

[sssd] [sss_confdb_create_ldif] (0x0400): Processing attribute [krb5_renew_interval]
[sssd] [sss_confdb_create_ldif] (0x4000): krb5_renew_interval: 2h

[sssd] [sss_confdb_create_ldif] (0x0400): Processing attribute [debug_level]
[sssd] [sss_confdb_create_ldif] (0x4000): debug_level: 0x0400

[sssd] [sss_confdb_create_ldif] (0x0400): Processing attribute [debug_backtrace_enabled]
[sssd] [sss_confdb_create_ldif] (0x4000): debug_backtrace_enabled: false

[sssd] [sss_confdb_create_ldif] (0x4000): Section dn
dn: cn=kcm,cn=config
cn: kcm
responder_idle_timeout: 0
tgt_renewal: true
krb5_renewable_lifetime: 7d
krb5_lifetime: 10h
krb5_renew_interval: 2h
debug_level: 0x0400
debug_backtrace_enabled: false


[sssd] [sss_confdb_create_ldif] (0x0400): Processing config section [pam]
[sssd] [sss_confdb_create_ldif] (0x0400): Skipping section pam
[sssd] [sss_confdb_create_ldif] (0x0400): Processing config section [domain/infinera.com]
[sssd] [sss_confdb_create_ldif] (0x0400): Skipping section domain/infinera.com
[sssd] [sss_confdb_create_ldif] (0x0400): Processing config section [domain/transmode.se]
[sssd] [sss_confdb_create_ldif] (0x0400): Skipping section domain/transmode.se
[sssd] [confdb_init_db] (0x0100): LDIF file to import: 
dn: cn=config
version: 2

dn: cn=kcm,cn=config
cn: kcm
responder_idle_timeout: 0
tgt_renewal: true
krb5_renewable_lifetime: 7d
krb5_lifetime: 10h
krb5_renew_interval: 2h
debug_level: 0x0400
debug_backtrace_enabled: false


[sssd] [get_monitor_config] (0x0010): No services configured!
[sssd] [main] (0x0010): SSSD couldn't load the configuration database.

After running this I see one file in:

ls /var/lib/sss/db
./  ../  config.ldb 

[justin-stephenson]

Does gentoo/openrc execute /usr/sbin/sssd --genconf-section=kcm on startup? What is the order of service startup if gentoo/openrc is not using systemd?

Yes, openrc init scripte has:

start_pre()
{
    "/usr/sbin/sssd" --genconf-section=kcm || return $?
}

Can you ignore a non-zero exit code from this command on startup? That is what we are doing with the systemd sssd-kcm.service unit file:

# grep 'ExecStartPre' /usr/lib/systemd/system/sssd-kcm.service
ExecStartPre=-/usr/sbin/sssd --genconf-section=kcm

Note the - prefix character.

https://www.freedesktop.org/software/systemd/man/systemd.service.html

If the executable path is prefixed with "-", an exit code of the command normally considered a failure (i.e. non-zero exit status or abnormal exit due to signal) is recorded, but has no further effect and is considered equivalent to success.

[joakim-tjernlund]

I edited the openrc script and forced a return 0, that worked, at least kcm started.
But I think this should be considered a workaround and sssd should be fixed to not error here?

[justin-stephenson]

But the genconf command does fail, because no configuration exists. Are you seeing this issue only now because sssd is not being built with implicit files provider (and thus, a valid conifguration) enabled?

This command ExecStartPre was not added for startup reasons, it was added to allow reloading the sssd-kcm configuration without restarting SSSD completely: https://pagure.io/SSSD/sssd/issue/3862

[joakim-tjernlund]

But the genconf command does fail, because no configuration exists. Are you seeing this issue only now because sssd is not being built with implicit files provider (and thus, a valid conifguration) enabled?

But config does exist, just not cached.
I am seeing this because we recently started to use KCM and KCM starts before sssd.
Seems to be that genconf does the job but returns an error anyway?

This command ExecStartPre was not added for startup reasons, it was added to allow reloading the sssd-kcm configuration without restarting SSSD completely: https://pagure.io/SSSD/sssd/issue/3862

You could have just KCM and no sssd, right?

[justin-stephenson]

But the genconf command does fail, because no configuration exists. Are you seeing this issue only now because sssd is not being built with implicit files provider (and thus, a valid conifguration) enabled?

But config does exist, just not cached.
I am seeing this because we recently started to use KCM and KCM starts before sssd.
Seems to be that genconf does the job but returns an error anyway?

If you enable the implicit files provider(enable_files_domain) then there will be no error.

This command ExecStartPre was not added for startup reasons, it was added to allow reloading the sssd-kcm configuration without restarting SSSD completely: https://pagure.io/SSSD/sssd/issue/3862

You could have just KCM and no sssd, right?

Yes, but not if you want to take advantage of some things like KCM renewals which require reading [kcm] options from the sssd config.ldb

[joakim-tjernlund]

But the genconf command does fail, because no configuration exists. Are you seeing this issue only now because sssd is not being built with implicit files provider (and thus, a valid conifguration) enabled?

But config does exist, just not cached.
I am seeing this because we recently started to use KCM and KCM starts before sssd.
Seems to be that genconf does the job but returns an error anyway?

If you enable the implicit files provider(enable_files_domain) then there will be no error.

hmm, now it is getting tricky enable that or disable this.

Either kcm(includes --genconf) should work/start independently of sssd or not. Which?
I got the impression they were independent and therefore above error is a bug that should be fixed?

This command ExecStartPre was not added for startup reasons, it was added to allow reloading the sssd-kcm configuration without restarting SSSD completely: https://pagure.io/SSSD/sssd/issue/3862

You could have just KCM and no sssd, right?

Yes, but not if you want to take advantage of some things like KCM renewals which require reading [kcm] options from the sssd config.ldb

Sure, but sometimes one does not have a choice.

[justin-stephenson]

But the genconf command does fail, because no configuration exists. Are you seeing this issue only now because sssd is not being built with implicit files provider (and thus, a valid conifguration) enabled?

But config does exist, just not cached.
I am seeing this because we recently started to use KCM and KCM starts before sssd.
Seems to be that genconf does the job but returns an error anyway?

If you enable the implicit files provider(enable_files_domain) then there will be no error.

hmm, now it is getting tricky enable that or disable this.

Either kcm(includes --genconf) should work/start independently of sssd or not. Which?
I got the impression they were independent and therefore above error is a bug that should be fixed?

If you have any [kcm] options you are using in sssd.conf, then KCM will always depend on SSSD - it cannot be standalone in this case.

[joakim-tjernlund]

If you have any [kcm] options you are using in sssd.conf, then KCM will always depend on SSSD - it cannot be standalone in this case.

OK, but what about the error reported here?

[joakim-tjernlund]

Meanwhile I created the above PR, please merge.

[pbrezina]

Pushed PR: #5734

• master
  • d41e956 - MONITOR: Return success from genconf with no config