Probably the reason is https://github.com/SSSD/sssd/blob/712377ea5c5b70a71e4fdb1b1c40ad059157778c/src/util/util.c#L669 :
```
const char * const * get_known_services(void)
{
    static const char *svc[] = {"nss", "pam", "sudo", "autofs",
                                "ssh", "pac", "ifp", NULL };

    return svc;
}
```
  --  `get_known_services()` doesn't list `kcm` so `monitor` refuses to register it:
https://github.com/SSSD/sssd/blob/712377ea5c5b70a71e4fdb1b1c40ad059157778c/src/monitor/monitor.c#L211


 Christian, is there "Invalid service ..." line in sssd.log?

(In reply to Alexey Tikhonov from comment #1)
> ```
> const char * const * get_known_services(void)
> {
>     static const char *svc[] = {"nss", "pam", "sudo", "autofs",
>                                 "ssh", "pac", "ifp", NULL };
> 
>     return svc;
> }
> ```

Might be worth a test built, to verify if sssd then starts
as parent of sssd_kcm.


>   --  `get_known_services()` doesn't list `kcm` so `monitor` refuses to
> register it:
> https://github.com/SSSD/sssd/blob/712377ea5c5b70a71e4fdb1b1c40ad059157778c/
> src/monitor/monitor.c#L211
> 
> 
>  Christian, is there "Invalid service ..." line in sssd.log?

Not seeing that on customers logs, and also not in a KVM-guest
with rhel8.6GA and sssd_kcm running.
  DEBUG(SSSDBG_FATAL_FAILURE, "Invalid service %s\n", svc_name);
should log it without increased debug level, I think.

Tried to use rpmbuild to rebuild sssd packages on both rhel8/rhel9.
On both package cifs-utils-devel is build dependency, which only exists on
rhel7.  Adding the rhel7 cifs-utils-devel, both rebuilds fail in the
"testing" phase of the build.

(In reply to Christian Horn from comment #2)
> (In reply to Alexey Tikhonov from comment #1)
> > ```
> > const char * const * get_known_services(void)
> > {
> >     static const char *svc[] = {"nss", "pam", "sudo", "autofs",
> >                                 "ssh", "pac", "ifp", NULL };
> > 
> >     return svc;
> > }
> > ```
> 
> Might be worth a test built, to verify if sssd then starts
> as parent of sssd_kcm.

Not sure what you mean with "sssd then starts as parent of sssd_kcm."

If you use sssd_kcm as socket activated service (a default) then changing this list is source code won't affect this.
But idea is that 'monitor' (main 'sssd' process) should register socket activated services (and thus be able to communicate with) as well.

> >   --  `get_known_services()` doesn't list `kcm` so `monitor` refuses to
> > register it:
> > https://github.com/SSSD/sssd/blob/712377ea5c5b70a71e4fdb1b1c40ad059157778c/
> > src/monitor/monitor.c#L211
> > 
> > 
> >  Christian, is there "Invalid service ..." line in sssd.log?
> 
> Not seeing that on customers logs, and also not in a KVM-guest
> with rhel8.6GA and sssd_kcm running.
>   DEBUG(SSSDBG_FATAL_FAILURE, "Invalid service %s\n", svc_name);
> should log it without increased debug level, I think.

Then it's more complicated. Probably sssd_kcm doesn't register with monitor, I need to check.

(In reply to Alexey Tikhonov from comment #4)
> 
> Then it's more complicated. Probably sssd_kcm doesn't register with monitor,
> I need to check.

Indeed:
```
$ grep -rn sss_monitor_service_init *
providers/data_provider_be.c:704:    ret = sss_monitor_service_init(be_ctx, be_ctx->ev, be_ctx->sbus_name,
responder/pam/pamsrv.c:410:    ret = sss_monitor_service_init(rctx, rctx->ev, SSS_BUS_PAM,
responder/autofs/autofssrv.c:154:    ret = sss_monitor_service_init(rctx, rctx->ev, SSS_BUS_AUTOFS,
responder/ssh/sshsrv.c:136:    ret = sss_monitor_service_init(rctx, rctx->ev, SSS_BUS_SSH,
responder/sudo/sudosrv.c:112:    ret = sss_monitor_service_init(rctx, rctx->ev, SSS_BUS_SUDO,
responder/pac/pacsrv.c:146:    ret = sss_monitor_service_init(rctx, rctx->ev, SSS_BUS_PAC,
responder/ifp/ifpsrv.c:280:    ret = sss_monitor_service_init(rctx, rctx->ev, SSS_BUS_IFP,
responder/nss/nsssrv.c:631:    ret = sss_monitor_service_init(rctx, rctx->ev, SSS_BUS_NSS,
```

But there might be a reason why it doesn't.

(In reply to Alexey Tikhonov from comment #5)
> 
> But there might be a reason why it doesn't.

Right, this is on purpose: 'monitor' (main `sssd` process) and KCM service (`sssd_kcm`) are totally independent.
On a default RHEL9 (and RHEL8 starting 8.8) install `sssd_kcm` runs (as socket activated serivce) and `sssd` doesn't (if no domains configured explicitly).
So I guess we need to add it's own `/etc/logrotate.d/sssd_kcm` (or list in `/etc/logrotate.d/sssd`?) and make it handle HUP on its own (if it doesn't yet).

(In reply to Alexey Tikhonov from comment #4)
> (In reply to Christian Horn from comment #2)
> > (In reply to Alexey Tikhonov from comment #1)
> > > ```
> > > const char * const * get_known_services(void)
> > > {
> > >     static const char *svc[] = {"nss", "pam", "sudo", "autofs",
> > >                                 "ssh", "pac", "ifp", NULL };
> > > 
> > >     return svc;
> > > }
> > > ```
> > 
> > Might be worth a test built, to verify if sssd then starts
> > as parent of sssd_kcm.
> 
> Not sure what you mean with "sssd then starts as parent of sssd_kcm."

[root@rhel8u6a sa]# ps axf|grep [s]ssd
    752 ?        Ss     0:00 /usr/sbin/sssd -i --logger=files
    770 ?        S      0:00  \_ /usr/libexec/sssd/sssd_be --domain implicit_files --uid 0 --gid 0 --logger=files
    798 ?        S      0:01  \_ /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
 878497 ?        Ss     0:00 /usr/libexec/sssd/sssd_kcm --uid 0 --gid 0 --logger=files
[root@rhel8u6a sa]# 

sssd_kcm is separate, that I meant.
It is not receiving a 'kill -HUP' at the moment.

> If you use sssd_kcm as socket activated service (a default) then changing
> this list is source code won't affect this.

Ok.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.