Automount fails due to SSSD config (Groovy Gorilla)

Bug #1897153 reported by Gavin Graham
22
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Release Notes for Ubuntu
Won't Fix
Undecided
Unassigned
sssd (Ubuntu)
Expired
High
Unassigned

Bug Description

Using the same automount config from 20.04, Groovy Gorilla fails to automount mount points with SSD errors such as the following:
-From journalctl -xe:
Sep 25 04:04:43 ROC-Cube systemd[1]: Stopping Automounts filesystems on demand...
░░ Subject: A stop job for unit autofs.service has begun execution
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A stop job for unit autofs.service has begun execution.
░░
░░ The job identifier is 8075.
Sep 25 04:04:43 ROC-Cube automount[1838]: umount_autofs_indirect: ask umount returned busy /mnt/GGData
Sep 25 04:04:44 ROC-Cube systemd[1]: autofs.service: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit autofs.service has successfully entered the 'dead' state.
Sep 25 04:04:44 ROC-Cube systemd[1]: Stopped Automounts filesystems on demand.
░░ Subject: A stop job for unit autofs.service has finished
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A stop job for unit autofs.service has finished.
░░
░░ The job identifier is 8075 and the job result is done.
Sep 25 04:04:44 ROC-Cube systemd[1]: Starting Automounts filesystems on demand...
░░ Subject: A start job for unit autofs.service has begun execution
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit autofs.service has begun execution.
░░
░░ The job identifier is 8075.
Sep 25 04:04:44 ROC-Cube automount[13523]: setautomntent: lookup(sss): setautomntent: No such file or directory
Sep 25 04:04:44 ROC-Cube systemd[1]: tmp-auto8NobgK.mount: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit tmp-auto8NobgK.mount has successfully entered the 'dead' state.
Sep 25 04:04:44 ROC-Cube automount[13523]: setautomntent: lookup(sss): setautomntent: No such file or directory
Sep 25 04:04:44 ROC-Cube systemd[2685]: tmp-autoxIakpM.mount: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit UNIT has successfully entered the 'dead' state.
Sep 25 04:04:44 ROC-Cube systemd[1]: tmp-autoxIakpM.mount: Succeeded.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ The unit tmp-autoxIakpM.mount has successfully entered the 'dead' state.
Sep 25 04:04:44 ROC-Cube systemd[1]: Started Automounts filesystems on demand.
░░ Subject: A start job for unit autofs.service has finished successfully
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit autofs.service has finished successfully.
░░
░░ The job identifier is 8075.

From tail /var/log/syslog:
Sep 25 04:13:38 ROC-Cube automount[13523]: umount_autofs_indirect: ask umount returned busy /mnt/GGData
Sep 25 04:13:40 ROC-Cube systemd[1]: autofs.service: Succeeded.
Sep 25 04:13:40 ROC-Cube systemd[1]: Stopped Automounts filesystems on demand.
Sep 25 04:13:40 ROC-Cube systemd[1]: Starting Automounts filesystems on demand...
Sep 25 04:13:40 ROC-Cube automount[15237]: setautomntent: lookup(sss): setautomntent: No such file or directory
Sep 25 04:13:40 ROC-Cube systemd[2685]: tmp-autonc2nfm.mount: Succeeded.
Sep 25 04:13:40 ROC-Cube automount[15237]: setautomntent: lookup(sss): setautomntent: No such file or directory
Sep 25 04:13:40 ROC-Cube systemd[1]: tmp-autonc2nfm.mount: Succeeded.
Sep 25 04:13:40 ROC-Cube systemd[1]: Started Automounts filesystems on demand.
Sep 25 04:13:40 ROC-Cube systemd[2685]: tmp-autopnDion.mount: Succeeded.

From auto.DataVol1:
root@ROC-Cube:~# cat /etc/auto.DataVol1
#/mnt/GGData -fstype=nfs 10.0.0.13:/GGData
Tracktion -fstype=nfs 10.0.0.13:/GGData/Tracktion
C64 -fstype=nfs 10.0.0.13:/GGData/C64
Development -fstype=nfs 10.0.0.13:/GGData/Development
Retro -fstype=nfs 10.0.0.13:/GGData/Retro
Inkscape -fstype=nfs 10.0.0.13:/GGData/Inkscape

From /etc/auto.master:
/mnt/GGData auto.DataVol1 --ghost

Revision history for this message
Gavin Graham (gavingraham) wrote :

Additional points:
* Able to always reproduce
* Able to manually mount volumes (doing so as temp workaround)

dpkg -l sssd
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-==============================================
ii sssd 2.3.1-2 amd64 System Security Services Daemon -- metapackage

root@ROC-Cube:~# dpkg -l autofs
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-==============-============-==================================
ii autofs 5.1.6-3ubuntu1 amd64 kernel-based automounter for Linux

Revision history for this message
Gavin Graham (gavingraham) wrote :
Download full text (4.5 KiB)

Trying to restart SSSD give the following errors with journlctl -xe:
The job identifier is 11972 and the job result is failed.
Sep 25 04:22:56 ROC-Cube systemd[1]: Dependency failed for SSSD Sudo Service responder socket.
░░ Subject: A start job for unit sssd-sudo.socket has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit sssd-sudo.socket has finished with a failure.
░░
░░ The job identifier is 12071 and the job result is dependency.
Sep 25 04:22:56 ROC-Cube systemd[1]: sssd-sudo.socket: Job sssd-sudo.socket/start failed with result 'dependency'.
Sep 25 04:22:56 ROC-Cube systemd[1]: Dependency failed for SSSD AutoFS Service responder socket.
░░ Subject: A start job for unit sssd-autofs.socket has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit sssd-autofs.socket has finished with a failure.
░░
░░ The job identifier is 11968 and the job result is dependency.
Sep 25 04:22:56 ROC-Cube systemd[1]: sssd-autofs.socket: Job sssd-autofs.socket/start failed with result 'dependency'.
Sep 25 04:22:56 ROC-Cube systemd[1]: Dependency failed for SSSD PAM Service responder socket.
░░ Subject: A start job for unit sssd-pam.socket has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit sssd-pam.socket has finished with a failure.
░░
░░ The job identifier is 12073 and the job result is dependency.
Sep 25 04:22:56 ROC-Cube systemd[1]: Dependency failed for SSSD PAM Service responder private socket.
░░ Subject: A start job for unit sssd-pam-priv.socket has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit sssd-pam-priv.socket has finished with a failure.
░░
░░ The job identifier is 12074 and the job result is dependency.
Sep 25 04:22:56 ROC-Cube systemd[1]: sssd-pam-priv.socket: Job sssd-pam-priv.socket/start failed with result 'dependency'.
Sep 25 04:22:56 ROC-Cube systemd[1]: sssd-pam.socket: Job sssd-pam.socket/start failed with result 'dependency'.
Sep 25 04:22:56 ROC-Cube systemd[1]: Dependency failed for SSSD SSH Service responder socket.
░░ Subject: A start job for unit sssd-ssh.socket has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit sssd-ssh.socket has finished with a failure.
░░
░░ The job identifier is 12070 and the job result is dependency.
Sep 25 04:22:56 ROC-Cube systemd[1]: sssd-ssh.socket: Job sssd-ssh.socket/start failed with result 'dependency'.
Sep 25 04:22:56 ROC-Cube systemd[1]: Dependency failed for SSSD PAC Service responder socket.
░░ Subject: A start job for unit sssd-pac.socket has failed
░░ Defined-By: systemd
░░ Support: http://www.ubuntu.com/support
░░
░░ A start job for unit sssd-pac.socket has finished with a failure.
░░
░░ The job identifier is 12075 and the job result is dependency.
Sep 25 04:22:56 ROC-Cube systemd[1]: sssd-pac.socket: Job sssd-pac.socket/start failed with result 'dependency'.
Sep 25 04:22:56 ROC-Cube systemd[1]: Dependency failed for SSSD NSS Service responder socket.
░░ Subject: A start job for unit sssd-nss.socket has failed
░░ Defined-By: systemd
░░ S...

Read more...

summary: - Automount fails due to SSSD
+ Automount fails due to SSSD config (Groovy Gorilla)
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Are you using a "services=" line in /etc/sssd/sssd.conf, to have sssd itself start services? It might be conflicting with the individual systemd services that are trying to start. Not saying it's the cause of your problem, but might be the cause of some log noise that is getting in the way of troubleshooting this more accurately.

Revision history for this message
Gavin Graham (gavingraham) wrote :

I never looked at SSD closely prior to upgrading from 20.04 to 20.10 so I don't know what was there before as it 'just worked'.
Presently though, the only thing under /etc/sssd is an empty conf.d (/etc/sssd/conf.d) directory.
I did reinstall the SSSD packages after upgrade to 20.10 however the /etc/sssd directory didn't change from being empty.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

You don't have /etc/sssd/sssd.conf? Do you have "sss" entries in /etc/nsswitch.conf?

Revision history for this message
Gavin Graham (gavingraham) wrote :

Nope, there's no files under /etc/sssd and I didn't touch this directory when upgrading to the Groovy daily image. When I have a moment, I'll install 20.04 in a VM for a comparison of what should be in /etc/sssd

But as far as /etc/nsswitch.conf goes:
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd: files systemd sss
group: files systemd sss
shadow: files sss
gshadow: files

hosts: files mdns4_minimal [NOTFOUND=return] dns mymachines
networks: files

protocols: db files
services: db files sss
ethers: db files
rpc: db files

netgroup: nis sss
sudoers: files sss
automount: sss

Revision history for this message
Gavin Graham (gavingraham) wrote :

I installed 20.04 fresh in a Gnome Boxes VM and installed autofs (sudo apt-get install autofs).
SSSD was not installed as a dependancy.

Then, I installed SSSD (sudo apt-get install sssd) just to see what /etc/sssd looked like and it's actually the same. there's no config file under /etc/sssd and and empty /etc/sssd/conf.d directory

I executed a systemctl start sssd and it threw the same errors.
I didn't have autofs configured and did not try to start autofs.

Revision history for this message
Gavin Graham (gavingraham) wrote :

After doing a fresh install of 20.04 in a VM and then installing autofs, I've concluded that SSSD isn't needed for my setup.
This does leave the question why SSSD was installed and if it was installed upon upgrade to Groovy.

Either way, it seems that when SSSD is installed (either on 20.04 or 20.10), SSSD doesn't come with a working config under /etc/sssd

On my install of Groovy, I removed SSSD and now my automounts are working correctly.

Should SSSD have a default working config under /etc/sssd when its packages are installed?

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Right, I was going to say it looked like your setup wasn't using sssd, hence my question about /etc/nsswitch.conf.

sssd needs to be configured after installation, at most it adds "sss" to /etc/nsswitch.conf, but the actual sssd.conf needs to be populated by hand, or by another tool such as realm from the realmd package. I think the sssd package never installed a default sssd.conf.

All that being said, sssd *can* do something with autofs, but it needs to be configured. I haven't used that feature yet, though. But looks like it gets in the way if not done properly.

Revision history for this message
Gavin Graham (gavingraham) wrote :

Understood.

I guess the last thing I can do here is take the 20.04 VM I've made and upgrade it to Groovy to see if SSSD is installed as a dependancy of something else.

I'll do that over the next day or two.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

oh it's known that the desktop metapackage(s) depend on it now

Revision history for this message
Robie Basak (racb) wrote :

We could also investigate if there is something to be done regarding the interaction of an unconfigured sssd and an existing autofs setup. But if we proceed here on that basis then I don't think this needs priority and so it probably won't get looked at. If you learn anything new that makes this bug appear more serious, please let us know and we can look again.

Changed in sssd (Ubuntu):
importance: Undecided → Low
Revision history for this message
Gavin Graham (gavingraham) wrote :

I wouldn't suggest that SSSD has anything done particularly for AutoFS but I would make a case for the package maintainers having a default /etc/sssd config file(s) that if nothing else has options commented/hashed out and ready ti be uncommented and used. This would be much like how *insert your favourite packge here* have a long list of commented options.

Grnted, this isn't a serious issue, rather, a small quality of life improvement. :)

Oh, one last point. If SSSD comes unconfigured and there unused 'out of the box', should another (meta)package have SSSD dependancy in the first place? (Ref: Timo comment #11)

Your thoughts?

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in sssd (Ubuntu):
status: New → Confirmed
Revision history for this message
Vladimir Yerilov (openmindead) wrote :
Download full text (3.9 KiB)

This bug "affects" me too. In a way that sssd fails to start. Also any attempt to run something like "systemctl enable foo.service" is now being rejected after entering correct password in pkexec popup window, so I have to use "sudo systemctl enable foo.service". Log show sssd.service and its "sub-services" fail to activate. All these is happening after the update from Focal to Groovy.
From var/log/dist-upgrade:
```
new important dependency: sssd:amd64
  Installing sssd as Recommends of ubuntu-desktop-minimal
    MarkInstall sssd:amd64 < none -> 2.3.1-2 @un uN Ib > FU=0
    Installing python3-sss as Depends of sssd
      MarkInstall python3-sss:amd64 < none -> 2.3.1-2 @un uN > FU=0
    Installing sssd-ad as Depends of sssd
      MarkInstall sssd-ad:amd64 < none -> 2.3.1-2 @un uN Ib > FU=0
      Installing libsss-idmap0 as Depends of sssd-ad
        MarkInstall libsss-idmap0:amd64 < none -> 2.3.1-2 @un uN > FU=0
      Installing sssd-ad-common as Depends of sssd-ad
        MarkInstall sssd-ad-common:amd64 < none -> 2.3.1-2 @un uN Ib > FU=0
        Installing sssd-common as Depends of sssd-ad-common
          MarkInstall sssd-common:amd64 < none -> 2.3.1-2 @un uN Ib > FU=0
          Installing libdhash1 as Depends of sssd-common
            MarkInstall libdhash1:amd64 < none -> 0.6.1-2 @un uN > FU=0
          Installing libini-config5 as Depends of sssd-common
            MarkInstall libini-config5:amd64 < none -> 0.6.1-2 @un uN Ib > FU=0
            Installing libbasicobjects0 as Depends of libini-config5
              MarkInstall libbasicobjects0:amd64 < none -> 0.6.1-2 @un uN > FU=0
            Installing libcollection4 as Depends of libini-config5
              MarkInstall libcollection4:amd64 < none -> 0.6.1-2 @un uN > FU=0
            Installing libpath-utils1 as Depends of libini-config5
              MarkInstall libpath-utils1:amd64 < none -> 0.6.1-2 @un uN > FU=0
            Installing libref-array1 as Depends of libini-config5
              MarkInstall libref-array1:amd64 < none -> 0.6.1-2 @un uN > FU=0
          Installing libsss-certmap0 as Depends of sssd-common
            MarkInstall libsss-certmap0:amd64 < none -> 2.3.1-2 @un uN > FU=0
          Installing libsss-nss-idmap0 as Depends of sssd-common
            MarkInstall libsss-nss-idmap0:amd64 < none -> 2.3.1-2 @un uN > FU=0
          Installing libnss-sss as Recommends of sssd-common
            MarkInstall libnss-sss:amd64 < none -> 2.3.1-2 @un uN > FU=0
          Installing libpam-sss as Recommends of sssd-common
            MarkInstall libpam-sss:amd64 < none -> 2.3.1-2 @un uN Ib > FU=0
            Installing libpam-pwquality as Depends of libpam-sss
              MarkInstall libpam-pwquality:amd64 < none -> 1.4.2-1build1 @un uN > FU=0
          Installing libsss-sudo as Recommends of sssd-common
            MarkInstall libsss-sudo:amd64 < none -> 2.3.1-2 @un uN > FU=0
      Installing sssd-krb5-common as Depends of sssd-ad
        MarkInstall sssd-krb5-common:amd64 < none -> 2.3.1-2 @un uN > FU=0
    Installing sssd-ipa as Depends of sssd
      MarkInstall sssd-ipa:amd64 < none -> 2.3.1-2 @un uN Ib > FU=0
      Installing libipa-hbac0 as Depends of sssd-ipa
        MarkI...

Read more...

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Hi @openmindead, what is your goal with sssd? Or you didn't have it installed in focal, and it got installed after upgrading to groovy?

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Do you still have the upgrade logs from focal to groovy?

Revision history for this message
Vladimir Yerilov (openmindead) wrote :

Hi, I had no intention to use sssd, it was pulled and installed during the update. I am sure I had no sssd installed on focal as I am browsing now through the image of my root partition created before the update was started.
Yes, I still have update logs.

Revision history for this message
Andreas Hasenack (ahasenack) wrote : Re: [Bug 1897153] Re: Automount fails due to SSSD config (Groovy Gorilla)
Download full text (5.6 KiB)

Could you please attach them? I'd like to know what pulled sssd in

On Tue, Sep 29, 2020, 23:55 Vladimir Yerilov <email address hidden>
wrote:

> Hi, I had no intention to use sssd, it was pulled and installed during the
> update. I am sure I had no sssd installed on focal as I am browsing now
> through the image of my root partition created before the update was
> started.
> Yes, I still have update logs.
>
> --
> You received this bug notification because you are subscribed to sssd in
> Ubuntu.
> https://bugs.launchpad.net/bugs/1897153
>
> Title:
> Automount fails due to SSSD config (Groovy Gorilla)
>
> Status in sssd package in Ubuntu:
> Confirmed
>
> Bug description:
> Using the same automount config from 20.04, Groovy Gorilla fails to
> automount mount points with SSD errors such as the following:
> -From journalctl -xe:
> Sep 25 04:04:43 ROC-Cube systemd[1]: Stopping Automounts filesystems on
> demand...
> ░░ Subject: A stop job for unit autofs.service has begun execution
> ░░ Defined-By: systemd
> ░░ Support: http://www.ubuntu.com/support
> ░░
> ░░ A stop job for unit autofs.service has begun execution.
> ░░
> ░░ The job identifier is 8075.
> Sep 25 04:04:43 ROC-Cube automount[1838]: umount_autofs_indirect: ask
> umount returned busy /mnt/GGData
> Sep 25 04:04:44 ROC-Cube systemd[1]: autofs.service: Succeeded.
> ░░ Subject: Unit succeeded
> ░░ Defined-By: systemd
> ░░ Support: http://www.ubuntu.com/support
> ░░
> ░░ The unit autofs.service has successfully entered the 'dead' state.
> Sep 25 04:04:44 ROC-Cube systemd[1]: Stopped Automounts filesystems on
> demand.
> ░░ Subject: A stop job for unit autofs.service has finished
> ░░ Defined-By: systemd
> ░░ Support: http://www.ubuntu.com/support
> ░░
> ░░ A stop job for unit autofs.service has finished.
> ░░
> ░░ The job identifier is 8075 and the job result is done.
> Sep 25 04:04:44 ROC-Cube systemd[1]: Starting Automounts filesystems on
> demand...
> ░░ Subject: A start job for unit autofs.service has begun execution
> ░░ Defined-By: systemd
> ░░ Support: http://www.ubuntu.com/support
> ░░
> ░░ A start job for unit autofs.service has begun execution.
> ░░
> ░░ The job identifier is 8075.
> Sep 25 04:04:44 ROC-Cube automount[13523]: setautomntent: lookup(sss):
> setautomntent: No such file or directory
> Sep 25 04:04:44 ROC-Cube systemd[1]: tmp-auto8NobgK.mount: Succeeded.
> ░░ Subject: Unit succeeded
> ░░ Defined-By: systemd
> ░░ Support: http://www.ubuntu.com/support
> ░░
> ░░ The unit tmp-auto8NobgK.mount has successfully entered the 'dead'
> state.
> Sep 25 04:04:44 ROC-Cube automount[13523]: setautomntent: lookup(sss):
> setautomntent: No such file or directory
> Sep 25 04:04:44 ROC-Cube systemd[2685]: tmp-autoxIakpM.mount: Succeeded.
> ░░ Subject: Unit succeeded
> ░░ Defined-By: systemd
> ░░ Support: http://www.ubuntu.com/support
> ░░
> ░░ The unit UNIT has successfully entered the 'dead' state.
> Sep 25 04:04:44 ROC-Cube systemd[1]: tmp-autoxIakpM.mount: Succeeded.
> ░░ Subject: Unit succeeded
> ░░ Defined-By: systemd
> ░░ Support: http://www.ubuntu.com/support
> ░░
>...

Read more...

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

ubuntu-desktop Recommends: sssd, that's what's pulling it in.

Revision history for this message
Timo Aaltonen (tjaalton) wrote :

And it's libnss-sss that adds "automount: sss" to nsswitch.conf

Does it work if you comment that out? This is yet another case of not having an 'update-nsswitch' tool to add entries when needed, the current packaging assumes that installing sssd means it's also configured..

Revision history for this message
Gavin Graham (gavingraham) wrote :
Download full text (3.3 KiB)

Same here aas in comment #15. I didn't have SSSD installed prior to the upgrade and it was "ubuntu-desktop-minimal" that pulled SSSD in. Not only did it break my automount but also login and sudo would take about a 4 seconds delay to succeed - as I guess it was trying to auth via SSS.

Grepped from the update log:
apt.log: Installing sssd as Recommends of ubuntu-desktop-minimal
apt.log: MarkInstall sssd:amd64 < none -> 2.3.1-2 @un uN Ib > FU=0
apt.log: Installing python3-sss as Depends of sssd
apt.log: MarkInstall python3-sss:amd64 < none -> 2.3.1-2 @un uN > FU=0
apt.log: Installing sssd-ad as Depends of sssd
apt.log: MarkInstall sssd-ad:amd64 < none -> 2.3.1-2 @un uN Ib > FU=0
apt.log: Installing libsss-idmap0 as Depends of sssd-ad
apt.log: MarkInstall libsss-idmap0:amd64 < none -> 2.3.1-2 @un uN > FU=0
apt.log: Installing sssd-ad-common as Depends of sssd-ad
apt.log: MarkInstall sssd-ad-common:amd64 < none -> 2.3.1-2 @un uN Ib > FU=0
apt.log: Installing sssd-common as Depends of sssd-ad-common
apt.log: MarkInstall sssd-common:amd64 < none -> 2.3.1-2 @un uN Ib > FU=0
apt.log: Installing libc-ares2 as Depends of sssd-common
apt.log: Installing libdhash1 as Depends of sssd-common
apt.log: Installing libini-config5 as Depends of sssd-common
apt.log: Installing libsss-certmap0 as Depends of sssd-common
apt.log: MarkInstall libsss-certmap0:amd64 < none -> 2.3.1-2 @un uN > FU=0
apt.log: Installing libsss-nss-idmap0 as Depends of sssd-common
apt.log: MarkInstall libsss-nss-idmap0:amd64 < none -> 2.3.1-2 @un uN > FU=0
apt.log: Installing libnss-sss as Recommends of sssd-common
apt.log: MarkInstall libnss-sss:amd64 < none -> 2.3.1-2 @un uN > FU=0
apt.log: Installing libpam-sss as Recommends of sssd-common
apt.log: MarkInstall libpam-sss:amd64 < none -> 2.3.1-2 @un uN Ib > FU=0
apt.log: Installing libpam-pwquality as Depends of libpam-sss
apt.log: Installing libsss-sudo as Recommends of sssd-common
apt.log: MarkInstall libsss-sudo:amd64 < none -> 2.3.1-2 @un uN > FU=0
apt.log: Installing sssd-krb5-common as Depends of sssd-ad
apt.log: MarkInstall sssd-krb5-common:amd64 < none -> 2.3.1-2 @un uN > FU=0
apt.log: Installing sssd-ipa as Depends of sssd
apt.log: MarkInstall sssd-ipa:amd64 < none -> 2.3.1-2 @un uN Ib > FU=0
apt.log: Installing libipa-hbac0 as Depends of sssd-ipa
apt.log: Installing sssd-krb5 as Depends of sssd
apt.log: MarkInstall sssd-krb5:amd64 < none -> 2.3.1-2 @un uN > FU=0
apt.log: Installing sssd-ldap as Depends of sssd
apt.log: MarkInstall sssd-ldap:amd64 < none -> 2.3.1-2 @un uN IPb > FU=0
apt.log: Installing ldap-utils as Recommends of sssd-ldap
apt.log: Installing sssd-proxy as Depends of sssd
apt.log: MarkInstall sssd-proxy:amd64 < none -> 2.3.1-2 @un uN > FU=0
apt.log: new important dependency: sssd-tools:amd64
apt.log: Installing sssd-tools as Recommends of ubuntu-desktop-minimal
apt.log: MarkInstall sssd-tools:amd64 < none -> 2.3.1-2 @un uN IPb > FU=0
apt.log: Installing...

Read more...

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

The sudo delay is likely due to dns, I see that in other boxes and ubuntu releases too. But let's see.

Changed in sssd (Ubuntu):
importance: Low → High
Revision history for this message
Gavin Graham (gavingraham) wrote :

Hi,
Well this explains why this is starting to happen: https://code.launchpad.net/~jibel/ubiquity/+git/ubiquity-1/+merge/390221

They're adding Active Directory to the new user creation in the installer.

There's also a design doc that explicitly mentions SSSD: https://docs.google.com/document/d/1_KEGJa2-ka1oNCzMvLlQg9rNW9JESzHAcgqrjP3DkW4/edit?ts=5f561950#

SHame is going to break other set-ups along the way.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

I understand sssd is failing to start because there is no config, but I'm trying to understand the bad interaction of automounts with sssd, which would be via /etc/nsswitch.conf.

(Brainstorming below, pardon me if this is all obvious to you)

autofs will consult /etc/nsswitch.conf when a map file has no path, i.e., is not really a file.

Something like this in /etc/auto.master:

/mnt auto.mnt

Since it's "auto.mnt" and not, say, "/etc/auto.mnt", /etc/nsswitch.conf is consulted.

That is exactly the case that was reported in this bug. Recaping:
"""
From /etc/auto.master:
/mnt/GGData auto.DataVol1 --ghost
"""

I'm not sure what is the fallback when NSS returns "sorry, no such thing here". Does autofs assumes a file, with a certain path? Let's find out.

...

Ok, it fails miserably. But if I remove "automount: sss" from /etc/nsswitch.conf, and leave the map without an absolute path, then autofs works.

I see two options here:

a) /etc/nsswitch.conf change

a) Add files:
automount: sss files

Also files could be first. Some experimentation and thought required here. We can also play with flags, like:
automount: sss [NOTFOUND=continue] files

The nsswitch.conf(5) manpage documents these. A quick check in our default nsswitch.conf file shows we (debian/ubuntu) do not use these flags. I seem to remember that Redhat/Fedora used to play a lot with the flags.

b) use a path in auto.master. In other words, change your /etc/auto.master entry to:

/mnt/GGData /etc/auto.DataVol1 --ghost

Or wherever auto.DataVol1 exists.

I have a feeling your setup was relying on this fallback to assuming the location of the auto.DataVol1 file.

strace shows autofs assumes /etc in this case, as the path for the file:
4263 connect(9, {sa_family=AF_UNIX, sun_path="/var/lib/sss/pipes/autofs"}, 110) = -1 ENOENT (No such file or directory)
4263 close(9) = 0
4263 write(2, "setautomntent: lookup(sss): setautomntent: No such file or directory", 68) = 68
4263 write(2, "\n", 1) = 1
4263 write(2, "lookup_nss_read_map: reading map files auto.mnt", 47) = 47
4263 write(2, "\n", 1) = 1
4263 stat("/etc/auto.mnt", {st_mode=S_IFREG|0644, st_size=330, ...}) = 0

So, here is my take: I believe your configuration needs to be fixed, because using a map file without a path in /etc/auto.master is documented as doing an nsswitch lookup, which is what broke when libnss-sss was installed (due to the entry it adds to /etc/nsswitch.fong).

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Vladimir, from comment #15, just having sssd failing to start is not enough for this bug. Are you also having autofs issues, and if yes, what does your /etc/auto.master look like? Do you also have a map file without a full path?

Revision history for this message
Gavin Graham (gavingraham) wrote :

Andreas,

As per comment #25, I've added the absolute path to auto.DataVol1 in /etc/auto.master as I can confirm it working.

With you comment on having:
automount: sss [NOTFOUND=continue] files
as part of /etc/nsswitch.conf, I suggest that to not break people's existing configs, that this may be a default for the the package developers for all the relevant switch options.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

According to the nsswitch.conf manpage, [NOTFOUND=continue] is already an assumed default, same for "UNAVAIL" and "TRYAGAIN", so it's just a question of whether we should add "files" to that line to cope with this situation or not.

Alternatively, we could also add conditions to the sssd service unit, so it won't start if there is no config.

Something like this in [Unit] of
ConditionFileNotEmpty=/etc/sssd/sssd.conf

And also perhaps
ConditionPathExistsGlob=/etc/sssd/conf.d/*.conf

Revision history for this message
Vladimir Yerilov (openmindead) wrote :

Hi Andreas,
I'm not using autofs, frankly, I chimed in here just to add that sssd package had been explicitly pulled and installed during the update to groovy. And that it failed to start for reasons unknown, too.
I didn't feel like tinkering with the problem, and given that I don't need sssd in the first place, I simply wiped it entirely and I'm fine now.

Revision history for this message
Gavin Graham (gavingraham) wrote :

Hi,

Sorry for the delay in getting back to you.
As mentioned, adding the absolut path to my auto.DataVol1 file has fixed the issue for me.
I think it would be preferably to add files to nsswitch.conf rather than looking for conf entries in /etc/sssd.
For me, the only thing inside /etc/sssd is a /etc/sssd/conf.d directory. Both /etc/sssd & /etc/sssd/conf.d have no configuration files.
I susptect that if I were to set-up the new Active Directory login, that /etc/sssd would be populated with the appropriate .conf files however I still suggest just adding a fallback to msswitch would be less invasive.

G.

Revision history for this message
Pelle Rivberg (rivpelle) wrote :

Ahoy!

Another 20.10 Groovy user here who had to update from 20.04.1LTS to 20.10 because my soundcard stopped working. Well, the sound card works now, but I get those same exact SSSD errors and I think the whole thing was installed upon update -- at least I didn't get those errors on my 20.04.1LTS.

The only contents of my /etc/sssd is a 'conf.d' subdirectory ( ' /etc/sssd/conf.d/ ' ), which is empty.

Please let me know if there's a workaround or a solution, thanks.

Revision history for this message
Pelle Rivberg (rivpelle) wrote :

BTW, this bug is also plaguing 20.04.1LTS users, as this was the original thread I stumbled upon (and commented into) at first:

https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1889196

Revision history for this message
Pelle Rivberg (rivpelle) wrote :

Having the very same issue in 20.10 Groovy Gorilla, after updating from 20.04.1LTS to this one (getting the same error messages on boot-up and so on.)

Inside my /etc/sssd , there is only a sub-directory /etc/sssd/conf.d/ , which is empty.

It seems that I can remove 'sssd' and its associated components with a simple apt purge/remove -command, but I'd like to know if that is compromising system security to do so. Then again, it's not working as it is ...

Revision history for this message
Sam Van den Eynde (samvde) wrote :

On my (upgraded from LTS) Groovy install:

systemctl status sssd.service
● sssd.service - System Security Services Daemon
     Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Wed 2020-12-30 01:42:46 CET; 9h ago
    Process: 14142 ExecStart=/usr/sbin/sssd -i ${DEBUG_LOGGER} (code=exited, status=4)
   Main PID: 14142 (code=exited, status=4)

dec 30 01:42:46 lenny systemd[1]: sssd.service: Scheduled restart job, restart counter is at 5.
dec 30 01:42:46 lenny systemd[1]: Stopped System Security Services Daemon.
dec 30 01:42:46 lenny systemd[1]: sssd.service: Start request repeated too quickly.
dec 30 01:42:46 lenny systemd[1]: sssd.service: Failed with result 'exit-code'.
dec 30 01:42:46 lenny systemd[1]: Failed to start System Security Services Daemon.

grep -i fail /var/log/boot.log
[FAILED] Failed to start System Security Services Daemon.
[DEPEND] Dependency failed for SSSD SSH Service responder socket.
[DEPEND] Dependency failed for SSSD NSS Service responder socket.
[DEPEND] Dependency failed for SSSD Sudo Service responder socket.
[DEPEND] Dependency failed for SSSD PAM Service responder private socket.
[DEPEND] Dependency failed for SSSD PAM Service responder socket.
[DEPEND] Dependency failed for SSSD PAC Service responder socket.
[DEPEND] Dependency failed for SSSD AutoFS Service responder socket.

Reason for faillure:

tail /var/log/sssd/sssd.log
(2020-12-30 1:42:45:946831): [sssd] [get_monitor_config] (0x0010): No domains configured.
(2020-12-30 1:42:45:946854): [sssd] [main] (0x0020): SSSD couldn't load the configuration database.
(2020-12-30 1:42:46:222311): [sssd] [confdb_expand_app_domains] (0x0010): No domains configured, fatal error!
(2020-12-30 1:42:46:222352): [sssd] [get_monitor_config] (0x0010): Failed to expand application domains
(2020-12-30 1:42:46:222381): [sssd] [get_monitor_config] (0x0010): No domains configured.
(2020-12-30 1:42:46:222403): [sssd] [main] (0x0020): SSSD couldn't load the configuration database.
(2020-12-30 1:42:46:446863): [sssd] [confdb_expand_app_domains] (0x0010): No domains configured, fatal error!
(2020-12-30 1:42:46:446891): [sssd] [get_monitor_config] (0x0010): Failed to expand application domains
(2020-12-30 1:42:46:446938): [sssd] [get_monitor_config] (0x0010): No domains configured.
(2020-12-30 1:42:46:446963): [sssd] [main] (0x0020): SSSD couldn't load the configuration database.

I did not (consciously) install sssd and as others have mentioned /etc/sssd is empty other than the conf.d directory. It leaves systemd in a degraded state.

Revision history for this message
Lucas Kanashiro (lucaskanashiro) wrote :

Thanks for all the reports and letting us know about this issue. However, there are some updates on the sssd package in Groovy since the last comment, I do not know if they could fix this issue for you but could you please give it a try? Also, since Groovy will become EOL soon, could you check if this same behavior is reproducible when upgrading to Hirsute (21.04)?

Revision history for this message
Sergio Durigan Junior (sergiodj) wrote :

Groovy has now EOL'ed; we're waiting on the reporter to check whether the issue persists on Hirsute/Impish.

Changed in sssd (Ubuntu):
status: Confirmed → Incomplete
Changed in ubuntu-release-notes:
status: New → Won't Fix
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for sssd (Ubuntu) because there has been no activity for 60 days.]

Changed in sssd (Ubuntu):
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.