[SSSD-users] Re: sssd 1.16.1 wont start, Centos 7.4
On 4 April 2018 at 09:46, Lachlan Musicman wrote: > On 3 April 2018 at 20:15, Jakub Hrozek wrote: > >> >> > fails with the same errors as reported initially. So running manually >> in interactive mode works, but starting via systemctl doesn’t >> >> One difference I can think of between running the deamon on the >> foreground versus running as a service is SELinux context. Did you check if >> maybe there are some AVC denials if you run sssd as a service? >> > > > I'll check the denials - I'm not fully up to speed on AVC denials and > selinux, but some googling suggested this command > > # ausearch -m avc -c sssd > > I noticed about an hour ago that the SSSD 1.16 COPR had been updated earlier this AM. I resync'd our repos and have updated to 1.16.1_2 and everything is working fine now. Cheers L. ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: sssd 1.16.1 wont start, Centos 7.4
On 3 April 2018 at 20:15, Jakub Hrozek wrote: > > > > On 3 Apr 2018, at 02:24, Lachlan Musicman wrote: > > > > On 3 April 2018 at 08:23, Lachlan Musicman wrote: > > On 29 March 2018 at 20:23, Valentin Fischer > wrote: > > Permission issue. > > > > Reinstall sssd-common > > https://lists.fedorahosted.org/archives/list/sssd-users@list > s.fedorahosted.org/message/IMP4NFXOW6RPKB2GIU4WXKLY54CTJG6A/ > > > > > > fails with the same errors as reported initially. So running manually in > interactive mode works, but starting via systemctl doesn’t > > One difference I can think of between running the deamon on the foreground > versus running as a service is SELinux context. Did you check if maybe > there are some AVC denials if you run sssd as a service? > I'll check the denials - I'm not fully up to speed on AVC denials and selinux, but some googling suggested this command # ausearch -m avc -c sssd Here's the sssd config [domain/unixdev.mycompany.com] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = unixdev.mycompany.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = vmts-linuxclient1.unixdev.mycompany.com chpass_provider = ipa ipa_server = _srv_, vmdv-linuxidm1.unixdev.mycompany.com ldap_tls_cacert = /etc/ipa/ca.crt selinux_provider = none krb5_auth_timeout = 15 debug_level = 7 [domain/unixdev.mycompany.com/mycompany.com] use_fully_qualified_names = False [sssd] config_file_version = 2 services = nss, sudo, pam, ssh domains = unixdev.mycompany.com debug_level = 7 domain_resolution_order = unix.mycompany.com,mycompany.com full_name_format = %1$s [nss] homedir_substring = /home memcache_timeout = 800 debug_level = 7 enum_cache_timeout = 240 entry_cache_nowait_percentage = 75 [pam] pam_id_timeout = 15 debug_level = 7 [ssh] debug_level = 7 ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: sssd 1.16.1 wont start, Centos 7.4
On 3 April 2018 at 20:15, Jakub Hrozek wrote: > On 29 March 2018 at 20:23, Valentin Fischer wrote: > > Permission issue. > > > > Reinstall sssd-common > > > > I tried this on two different machines an it didn't work on either. Am > getting identical output.> > > > > I found this old thread > > > > https://lists.fedorahosted.org/archives/list/sssd-users@ > lists.fedorahosted.org/message/IMP4NFXOW6RPKB2GIU4WXKLY54CTJG6A/ > > > > I tried running > > > > sssd -i -d9 > > > > and it works fine, the /var/lib/sss/pipes have returned (I deleted them, > reinstalled sssd-common, they weren't replaced), and I can login > successfully. > > > > So it's just running > > > > systemctl start sssd > > or > > systemctl restart sssd > > > > fails with the same errors as reported initially. So running manually in > interactive mode works, but starting via systemctl doesn’t > > One difference I can think of between running the deamon on the foreground > versus running as a service is SELinux context. Did you check if maybe > there are some AVC denials if you run sssd as a service? > > I checked that too. SELinux is disabled and has been since installation. Cheers L. ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
[SSSD-users] Re: sssd 1.16.1 wont start, Centos 7.4
> On 3 Apr 2018, at 02:24, Lachlan Musicman wrote: > > On 3 April 2018 at 08:23, Lachlan Musicman wrote: > On 29 March 2018 at 20:23, Valentin Fischer wrote: > Permission issue. > > Reinstall sssd-common > > > > I tried this on two different machines an it didn't work on either. Am > getting identical output. > > > I found this old thread > > https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/message/IMP4NFXOW6RPKB2GIU4WXKLY54CTJG6A/ > > I tried running > > sssd -i -d9 > > and it works fine, the /var/lib/sss/pipes have returned (I deleted them, > reinstalled sssd-common, they weren't replaced), and I can login successfully. > > So it's just running > > systemctl start sssd > or > systemctl restart sssd > > fails with the same errors as reported initially. So running manually in > interactive mode works, but starting via systemctl doesn’t One difference I can think of between running the deamon on the foreground versus running as a service is SELinux context. Did you check if maybe there are some AVC denials if you run sssd as a service? > . > > I can't apply the update to production in that state, but if you want any > more logs or testing done, let me know. > > Here are the permissions on the file system (I've not changed them by hand), > but they look the same as a working 1.16.0_4 sssd installation. > > [root@vmts-linuxclient1 sssd]# ls -la /var/lib/sss/pipes/ > total 8 > drwxr-xr-x. 3 sssd sssd 71 Apr 3 10:11 . > drwxr-xr-x. 10 root root 4096 Mar 29 03:01 .. > srw-rw-rw- 1 root root0 Apr 3 10:11 nss > srw-rw-rw- 1 root root0 Apr 3 10:11 pac > srw-rw-rw- 1 root root0 Apr 3 10:11 pam > drwxr-x---. 2 sssd root 4096 Apr 3 10:11 private > srw-rw-rw- 1 root root0 Apr 3 10:11 ssh > srw-rw-rw- 1 root root0 Apr 3 10:11 sudo > [root@vmts-linuxclient1 sssd]# ls -la /var/lib/sss/pipes/private/ > total 4 > drwxr-x---. 2 sssd root 4096 Apr 3 10:11 . > drwxr-xr-x. 3 sssd sssd 71 Apr 3 10:11 .. > srw--- 1 root root0 Apr 3 10:11 pam > lrwxrwxrwx 1 root root 63 Apr 3 10:11 sbus-dp_mycompany.com -> > /var/lib/sss/pipes/private/sbus-dp_mycompany.com.3913 > srw--- 1 root root0 Apr 3 10:11 sbus-dp_mycompany.com.3913 > srw--- 1 root root0 Apr 3 10:11 sbus-monitor > > > Cheers > L. > > > > > > On Thu 29. Mar 2018 at 00:20, Lachlan Musicman wrote: > Using the newly minted SSSD 1.16.1 from COPR, the sssd service doesn't > restart. > > ( https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-16/) > > The journalctl -xe shows: > > -- Unit sssd.service has begun starting up. > Mar 29 09:05:55 linuxclient1.unixdev.company.com sssd[1477]: Starting up > Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: sssd.service: > main process exited, code=exited, status=3/NOTIMPLEMENTED > Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: Failed to start > System Security Services Daemon. > -- Subject: Unit sssd.service has failed > -- Defined-By: systemd > -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel > > > The /var/log/sssd/sssd.log shows > > > (Thu Mar 29 09:03:44 2018) [sssd] [server_setup] (0x0400): CONFDB: > /var/lib/sss/db/config.ldb > (Thu Mar 29 09:03:44 2018) [sssd] [_snotify_create] (0x0400): Added a watch > for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using > function resolv_conf_inotify_cb after delay 1.0 > (Thu Mar 29 09:03:44 2018) [sssd] [sss_names_init_from_args] (0x0100): Using > re > [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P.+$))|(^(?P[^@\\]+)$))]. > (Thu Mar 29 09:03:44 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq > format [%1$s]. > (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): DB > File for unixdev.company.com: /var/lib/sss/db/cache_unixdev.company.com.ldb > (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): > Timestamp file for unixdev.company.com: > /var/lib/sss/db/timestamps_unixdev.company.com.ldb > (Thu Mar 29 09:03:44 2018) [sssd] [ldb] (0x0400): asq: Unable to register > control with rootdse! > (Thu Mar 29 09:03:44 2018) [sssd] [sbus_new_server] (0x0020): > dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied, > message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor": > Permission denied) > (Thu Mar 29 09:05:55 2018) [sssd] [server_setup] (0x0400): CONFDB: > /var/lib/sss/db/config.ldb > (Thu Mar 29 09:05:55 2018) [sssd] [_snotify_create] (0x0400): Added a watch > for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 using > function resolv_conf_inotify_cb after delay 1.0 > (Thu Mar 29 09:05:55 2018) [sssd] [sss_names_init_from_args] (0x0100): Using > re > [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P.+$))|(^(?P[^@\\]+)$))]. > (Thu Mar 29 09:05:55 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq > format [%1$s]. > (Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0
[SSSD-users] Re: sssd 1.16.1 wont start, Centos 7.4
On 3 April 2018 at 08:23, Lachlan Musicman wrote: > On 29 March 2018 at 20:23, Valentin Fischer > wrote: > >> Permission issue. >> >> Reinstall sssd-common >> >> > > I tried this on two different machines an it didn't work on either. Am > getting identical output. > I found this old thread https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.org/message/IMP4NFXOW6RPKB2GIU4WXKLY54CTJG6A/ I tried running sssd -i -d9 and it works fine, the /var/lib/sss/pipes have returned (I deleted them, reinstalled sssd-common, they weren't replaced), and I can login successfully. So it's just running systemctl start sssd or systemctl restart sssd fails with the same errors as reported initially. So running manually in interactive mode works, but starting via systemctl doesn't. I can't apply the update to production in that state, but if you want any more logs or testing done, let me know. Here are the permissions on the file system (I've not changed them by hand), but they look the same as a working 1.16.0_4 sssd installation. [root@vmts-linuxclient1 sssd]# ls -la /var/lib/sss/pipes/ total 8 drwxr-xr-x. 3 sssd sssd 71 Apr 3 10:11 . drwxr-xr-x. 10 root root 4096 Mar 29 03:01 .. srw-rw-rw- 1 root root0 Apr 3 10:11 nss srw-rw-rw- 1 root root0 Apr 3 10:11 pac srw-rw-rw- 1 root root0 Apr 3 10:11 pam drwxr-x---. 2 sssd root 4096 Apr 3 10:11 private srw-rw-rw- 1 root root0 Apr 3 10:11 ssh srw-rw-rw- 1 root root0 Apr 3 10:11 sudo [root@vmts-linuxclient1 sssd]# ls -la /var/lib/sss/pipes/private/ total 4 drwxr-x---. 2 sssd root 4096 Apr 3 10:11 . drwxr-xr-x. 3 sssd sssd 71 Apr 3 10:11 .. srw--- 1 root root0 Apr 3 10:11 pam lrwxrwxrwx 1 root root 63 Apr 3 10:11 sbus-dp_mycompany.com -> /var/lib/sss/pipes/private/sbus-dp_mycompany.com.3913 srw--- 1 root root0 Apr 3 10:11 sbus-dp_mycompany.com.3913 srw--- 1 root root0 Apr 3 10:11 sbus-monitor Cheers L. > > >> On Thu 29. Mar 2018 at 00:20, Lachlan Musicman wrote: >> >>> Using the newly minted SSSD 1.16.1 from COPR, the sssd service doesn't >>> restart. >>> >>> ( https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-16/) >>> >>> The journalctl -xe shows: >>> >>> -- Unit sssd.service has begun starting up. >>> Mar 29 09:05:55 linuxclient1.unixdev.company.com sssd[1477]: Starting up >>> Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: >>> sssd.service: main process exited, code=exited, status=3/NOTIMPLEMENTED >>> Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: Failed to >>> start System Security Services Daemon. >>> -- Subject: Unit sssd.service has failed >>> -- Defined-By: systemd >>> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel >>> >>> >>> The /var/log/sssd/sssd.log shows >>> >>> >>> (Thu Mar 29 09:03:44 2018) [sssd] [server_setup] (0x0400): CONFDB: >>> /var/lib/sss/db/config.ldb >>> (Thu Mar 29 09:03:44 2018) [sssd] [_snotify_create] (0x0400): Added a >>> watch for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 >>> using function resolv_conf_inotify_cb after delay 1.0 >>> (Thu Mar 29 09:03:44 2018) [sssd] [sss_names_init_from_args] (0x0100): >>> Using re [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P< >>> domain>.+$))|(^(?P[^@\\]+)$))]. >>> (Thu Mar 29 09:03:44 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq >>> format [%1$s]. >>> (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): >>> DB File for unixdev.company.com: /var/lib/sss/db/cache_unixdev. >>> company.com.ldb >>> (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): >>> Timestamp file for unixdev.company.com: /var/lib/sss/db/timestamps_uni >>> xdev.company.com.ldb >>> (Thu Mar 29 09:03:44 2018) [sssd] [ldb] (0x0400): asq: Unable to >>> register control with rootdse! >>> (Thu Mar 29 09:03:44 2018) [sssd] [sbus_new_server] (0x0020): >>> dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied, >>> message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor": >>> Permission denied) >>> (Thu Mar 29 09:05:55 2018) [sssd] [server_setup] (0x0400): CONFDB: >>> /var/lib/sss/db/config.ldb >>> (Thu Mar 29 09:05:55 2018) [sssd] [_snotify_create] (0x0400): Added a >>> watch for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 >>> using function resolv_conf_inotify_cb after delay 1.0 >>> (Thu Mar 29 09:05:55 2018) [sssd] [sss_names_init_from_args] (0x0100): >>> Using re [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P< >>> domain>.+$))|(^(?P[^@\\]+)$))]. >>> (Thu Mar 29 09:05:55 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq >>> format [%1$s]. >>> (Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0200): >>> DB File for unixdev.company.com: /var/lib/sss/db/cache_unixdev. >>> company.com.ldb >>> (Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0200): >>> Timestamp file for unixdev.company.com: /var/lib/sss/db/timestamps_uni >>> xdev.company.com.ldb >>> (T
[SSSD-users] Re: sssd 1.16.1 wont start, Centos 7.4
On 29 March 2018 at 20:23, Valentin Fischer wrote: > Permission issue. > > Reinstall sssd-common > > I tried this on two different machines an it didn't work on either. Am getting identical output. > On Thu 29. Mar 2018 at 00:20, Lachlan Musicman wrote: > >> Using the newly minted SSSD 1.16.1 from COPR, the sssd service doesn't >> restart. >> >> ( https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-16/) >> >> The journalctl -xe shows: >> >> -- Unit sssd.service has begun starting up. >> Mar 29 09:05:55 linuxclient1.unixdev.company.com sssd[1477]: Starting up >> Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: >> sssd.service: main process exited, code=exited, status=3/NOTIMPLEMENTED >> Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: Failed to >> start System Security Services Daemon. >> -- Subject: Unit sssd.service has failed >> -- Defined-By: systemd >> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel >> >> >> The /var/log/sssd/sssd.log shows >> >> >> (Thu Mar 29 09:03:44 2018) [sssd] [server_setup] (0x0400): CONFDB: >> /var/lib/sss/db/config.ldb >> (Thu Mar 29 09:03:44 2018) [sssd] [_snotify_create] (0x0400): Added a >> watch for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 >> using function resolv_conf_inotify_cb after delay 1.0 >> (Thu Mar 29 09:03:44 2018) [sssd] [sss_names_init_from_args] (0x0100): >> Using re [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(? >> P.+$))|(^(?P[^@\\]+)$))]. >> (Thu Mar 29 09:03:44 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq >> format [%1$s]. >> (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): >> DB File for unixdev.company.com: /var/lib/sss/db/cache_unixdev. >> company.com.ldb >> (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): >> Timestamp file for unixdev.company.com: /var/lib/sss/db/timestamps_ >> unixdev.company.com.ldb >> (Thu Mar 29 09:03:44 2018) [sssd] [ldb] (0x0400): asq: Unable to register >> control with rootdse! >> (Thu Mar 29 09:03:44 2018) [sssd] [sbus_new_server] (0x0020): >> dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied, >> message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor": >> Permission denied) >> (Thu Mar 29 09:05:55 2018) [sssd] [server_setup] (0x0400): CONFDB: >> /var/lib/sss/db/config.ldb >> (Thu Mar 29 09:05:55 2018) [sssd] [_snotify_create] (0x0400): Added a >> watch for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 >> using function resolv_conf_inotify_cb after delay 1.0 >> (Thu Mar 29 09:05:55 2018) [sssd] [sss_names_init_from_args] (0x0100): >> Using re [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(? >> P.+$))|(^(?P[^@\\]+)$))]. >> (Thu Mar 29 09:05:55 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq >> format [%1$s]. >> (Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0200): >> DB File for unixdev.company.com: /var/lib/sss/db/cache_unixdev. >> company.com.ldb >> (Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0200): >> Timestamp file for unixdev.company.com: /var/lib/sss/db/timestamps_ >> unixdev.company.com.ldb >> (Thu Mar 29 09:05:55 2018) [sssd] [ldb] (0x0400): asq: Unable to register >> control with rootdse! >> (Thu Mar 29 09:05:55 2018) [sssd] [sbus_new_server] (0x0020): >> dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied, >> message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor": >> Permission denied) >> >> >> /var/lib/sss/pipes/private shows >> >> drwxr-x---. 2 sssd root 4096 Mar 29 08:50 . >> drwxr-xr-x. 3 sssd sssd 71 Mar 29 03:01 .. >> srw--- 1 root root0 Mar 19 09:21 pam >> lrwxrwxrwx 1 root root 62 Mar 19 09:20 sbus-dp_unixdev.company.com -> >> /var/lib/sss/pipes/private/sbus-dp_unixdev.company.com.758 >> srw--- 1 root root0 Sep 18 2017 sbus-dp_unixdev.company.com.732 >> srw--- 1 root root0 Dec 28 09:47 sbus-dp_unixdev.company.com.746 >> >> >> It looks like there's some clean up that's not happening? I don't >> actually know what sbus_dp files do, but the top result (pointing to .758) >> doesn't exist... >> >> How do I fix this? >> >> Cheers >> L. >> >> >> -- >> "The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic >> civics is the insistence that we cannot ignore the truth, nor should we >> panic about it. It is a shared consciousness that our institutions have >> failed and our ecosystem is collapsing, yet we are still here — and we are >> creative agents who can shape our destinies. Apocalyptic civics is the >> conviction that the only way out is through, and the only way through is >> together. " >> >> *Greg Bloom* @greggish https://twitter.com/greggish/ >> status/873177525903609857 >> ___ >> sssd-users mailing list -- sssd-users@lists.fedorahosted.org >> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org >> > > ___ > sssd
[SSSD-users] Re: sssd 1.16.1 wont start, Centos 7.4
Permission issue. Reinstall sssd-common On Thu 29. Mar 2018 at 00:20, Lachlan Musicman wrote: > Using the newly minted SSSD 1.16.1 from COPR, the sssd service doesn't > restart. > > ( https://copr.fedorainfracloud.org/coprs/g/sssd/sssd-1-16/) > > The journalctl -xe shows: > > -- Unit sssd.service has begun starting up. > Mar 29 09:05:55 linuxclient1.unixdev.company.com sssd[1477]: Starting up > Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: > sssd.service: main process exited, code=exited, status=3/NOTIMPLEMENTED > Mar 29 09:05:55 linuxclient1.unixdev.company.com systemd[1]: Failed to > start System Security Services Daemon. > -- Subject: Unit sssd.service has failed > -- Defined-By: systemd > -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel > > > The /var/log/sssd/sssd.log shows > > > (Thu Mar 29 09:03:44 2018) [sssd] [server_setup] (0x0400): CONFDB: > /var/lib/sss/db/config.ldb > (Thu Mar 29 09:03:44 2018) [sssd] [_snotify_create] (0x0400): Added a > watch for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 > using function resolv_conf_inotify_cb after delay 1.0 > (Thu Mar 29 09:03:44 2018) [sssd] [sss_names_init_from_args] (0x0100): > Using re > [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P.+$))|(^(?P[^@\\]+)$))]. > (Thu Mar 29 09:03:44 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq > format [%1$s]. > (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): > DB File for unixdev.company.com: > /var/lib/sss/db/cache_unixdev.company.com.ldb > (Thu Mar 29 09:03:44 2018) [sssd] [sysdb_domain_init_internal] (0x0200): > Timestamp file for unixdev.company.com: > /var/lib/sss/db/timestamps_unixdev.company.com.ldb > (Thu Mar 29 09:03:44 2018) [sssd] [ldb] (0x0400): asq: Unable to register > control with rootdse! > (Thu Mar 29 09:03:44 2018) [sssd] [sbus_new_server] (0x0020): > dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied, > message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor": > Permission denied) > (Thu Mar 29 09:05:55 2018) [sssd] [server_setup] (0x0400): CONFDB: > /var/lib/sss/db/config.ldb > (Thu Mar 29 09:05:55 2018) [sssd] [_snotify_create] (0x0400): Added a > watch for /etc/resolv.conf with inotify flags 0x8D88 internal flags 0x1 > using function resolv_conf_inotify_cb after delay 1.0 > (Thu Mar 29 09:05:55 2018) [sssd] [sss_names_init_from_args] (0x0100): > Using re > [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P.+$))|(^(?P[^@\\]+)$))]. > (Thu Mar 29 09:05:55 2018) [sssd] [sss_fqnames_init] (0x0100): Using fq > format [%1$s]. > (Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0200): > DB File for unixdev.company.com: > /var/lib/sss/db/cache_unixdev.company.com.ldb > (Thu Mar 29 09:05:55 2018) [sssd] [sysdb_domain_init_internal] (0x0200): > Timestamp file for unixdev.company.com: > /var/lib/sss/db/timestamps_unixdev.company.com.ldb > (Thu Mar 29 09:05:55 2018) [sssd] [ldb] (0x0400): asq: Unable to register > control with rootdse! > (Thu Mar 29 09:05:55 2018) [sssd] [sbus_new_server] (0x0020): > dbus_server_listen failed! (name=org.freedesktop.DBus.Error.AccessDenied, > message=Failed to bind socket "/var/lib/sss/pipes/private/sbus-monitor": > Permission denied) > > > /var/lib/sss/pipes/private shows > > drwxr-x---. 2 sssd root 4096 Mar 29 08:50 . > drwxr-xr-x. 3 sssd sssd 71 Mar 29 03:01 .. > srw--- 1 root root0 Mar 19 09:21 pam > lrwxrwxrwx 1 root root 62 Mar 19 09:20 sbus-dp_unixdev.company.com -> > /var/lib/sss/pipes/private/sbus-dp_unixdev.company.com.758 > srw--- 1 root root0 Sep 18 2017 sbus-dp_unixdev.company.com.732 > srw--- 1 root root0 Dec 28 09:47 sbus-dp_unixdev.company.com.746 > > > It looks like there's some clean up that's not happening? I don't actually > know what sbus_dp files do, but the top result (pointing to .758) doesn't > exist... > > How do I fix this? > > Cheers > L. > > > -- > "The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic > civics is the insistence that we cannot ignore the truth, nor should we > panic about it. It is a shared consciousness that our institutions have > failed and our ecosystem is collapsing, yet we are still here — and we are > creative agents who can shape our destinies. Apocalyptic civics is the > conviction that the only way out is through, and the only way through is > together. " > > *Greg Bloom* @greggish > https://twitter.com/greggish/status/873177525903609857 > ___ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > ___ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
