This bug was fixed in the package sssd - 2.2.0-4ubuntu1.1
---
sssd (2.2.0-4ubuntu1.1) eoan; urgency=medium
* d/p/monitor-propagate-error.patch,
d/p/monitor-resolve-symlinks.patch: correctly monitor the
/etc/resolv.conf symlink when its target changes from a non-existent
This bug was fixed in the package sssd - 1.16.1-1ubuntu1.6
---
sssd (1.16.1-1ubuntu1.6) bionic; urgency=medium
* d/p/monitor-propagate-error.patch,
d/p/monitor-resolve-symlinks.patch: correctly monitor the
/etc/resolv.conf symlink when its target changes from a non-existent
bionic verification
With package from proposed:
*** 1.16.1-1ubuntu1.6 500
500 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 Packages
a) inotify test
Since I have the proposed package, logs show sssd is monitoring the symlink's
target:
(Tue Jun 2 14:39:32 2020) [sssd] [_s
** Description changed:
[Impact]
sssd can switch to an offline mode of operation when it cannot reach the
authentication or id backend. It uses several methods to assess the situation,
and one of them is monitoring the /etc/resolv.conf file for changes.
In ubuntu that file is a symlink
eoan verification
With package from proposed:
*** 2.2.0-4ubuntu1.1 500
500 http://archive.ubuntu.com/ubuntu eoan-proposed/main amd64 Packages
a) inotify test
Since I have the proposed package, logs show sssd is monitoring the symlink's
target:
(Tue Jun 2 13:37:27 2020) [sssd] [_snotify
Hello Marian, or anyone else affected,
Accepted sssd into eoan-proposed. The package will build now and be
available at https://launchpad.net/ubuntu/+source/sssd/2.2.0-4ubuntu1.1
in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ub
> AFAICT, this will only happen if /etc/resolv.conf is a broken symlink.
Correct. I would have expected the default inotify case to handle that,
though, as it will see that the contents of resolv.conf (or the symlink
target) changed, and in fact it notices that, but doesn't seem to switch
back to
** Description changed:
[Impact]
sssd can switch to an offline mode of operation when it cannot reach the
authentication or id backend. It uses several methods to assess the situation,
and one of them is monitoring the /etc/resolv.conf file for changes.
In ubuntu that file is a symlink
> b) change the fallback polling code to keep trying, instead of giving
up right away
AFAICT, this will only happen if /etc/resolv.conf is a broken symlink.
What happens if the symlink exists but doesn't provide something valid,
sssd goes into offline, and then the symlink is changed to something
** Description changed:
[Impact]
sssd can switch to an offline mode of operation when it cannot reach the
authentication or id backend. It uses several methods to assess the situation,
and one of them is monitoring the /etc/resolv.conf file for changes.
In ubuntu that file is a symlink
** Merge proposal linked:
https://code.launchpad.net/~ahasenack/ubuntu/+source/sssd/+git/sssd/+merge/384137
** Merge proposal linked:
https://code.launchpad.net/~ahasenack/ubuntu/+source/sssd/+git/sssd/+merge/384138
--
You received this bug notification because you are a member of Ubuntu
** Changed in: sssd (Ubuntu Eoan)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sssd offline on boot, stays offline forever
To manage notifications a
** Description changed:
[Impact]
sssd can switch to an offline mode of operation when it cannot reach the
authentication or id backend. It uses several methods to assess the situation,
and one of them is monitoring the /etc/resolv.conf file for changes.
In ubuntu that file is a symlink
** Description changed:
[Impact]
sssd can switch to an offline mode of operation when it cannot reach the
authentication or id backend. It uses several methods to assess the situation,
and one of them is monitoring the /etc/resolv.conf file for changes.
In ubuntu that file is a symlink
** Description changed:
[Impact]
sssd can switch to an offline mode of operation when it cannot reach the
authentication or id backend. It uses several methods to assess the situation,
and one of them is monitoring the /etc/resolv.conf file for changes.
In ubuntu that file is a symlink
** Description changed:
[Impact]
sssd can switch to an offline mode of operation when it cannot reach the
authentication or id backend. It uses several methods to assess the situation,
and one of them is monitoring the /etc/resolv.conf file for changes.
In ubuntu that file is a symlink
** Description changed:
[Impact]
sssd can switch to an offline mode of operation when it cannot reach the
authentication or id backend. It uses several methods to assess the situation,
and one of them is monitoring the /etc/resolv.conf file for changes.
In ubuntu that file is a symlink
** Description changed:
[Impact]
sssd can switch to an offline mode of operation when it cannot reach the
authentication or id backend. It uses several methods to assess the situation,
and one of them is monitoring the /etc/resolv.conf file for changes.
In ubuntu that file is a symlink
** Description changed:
[Impact]
sssd can switch to an offline mode of operation when it cannot reach the
authentication or id backend. It uses several methods to assess the situation,
and one of them is monitoring the /etc/resolv.conf file for changes.
In ubuntu that file is a symlink
** Description changed:
+ [Impact]
+ sssd can switch to an offline mode of operation when it cannot reach the
authentication or id backend. It uses several methods to assess the situation,
and one of them is monitoring the /etc/resolv.conf file for changes.
+
+ In ubuntu that file is a symlink
** Changed in: sssd (Ubuntu Eoan)
Assignee: (unassigned) => Andreas Hasenack (ahasenack)
** Changed in: sssd (Ubuntu Eoan)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.n
Just tested and eoan is affected, focal is clear.
** Also affects: sssd (Ubuntu Eoan)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sssd o
Ok, I have a simple way to reproduce this, and was able to test the
upstream patch. I'll polish it up and put it up for review, then prepare
the SRU paperwork.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/
It has been a constant problem for me in 18.04 but seems to work fine in
20.04 on the couple of computers I have tried it on.
However I have had reliability issues with it in 20.04 on one computer
with multiple ethernet adapters with only one plugged in and bridging
set up (for VMs). That may be j
** Changed in: sssd (Ubuntu Bionic)
Assignee: (unassigned) => Andreas Hasenack (ahasenack)
** Changed in: sssd (Ubuntu Bionic)
Status: Confirmed => In Progress
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.l
This is still on my list, I'm just very busy with focal fossa right now,
but the feature freeze is past, and now I can concentrate on only fixing
bugs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/172
Same here - it is a nightmare:
(Wed Mar 4 16:19:36 2020) [sssd[be[LDAP]]] [resolv_gethostbyname_done]
(0x0040): querying hosts database failed [5]: Input/output error
(Wed Mar 4 16:19:36 2020) [sssd[be[LDAP]]] [fo_resolve_service_done] (0x0020):
Failed to resolve server 'ldap': Could not c
I'll get to it. Being able to test the fix would help a lot, since I
never got it reproduced locally.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sssd offline on boot, stays offline
Hi all.
@Andreas Hasenack any progress on this :) ?
Anything we can do to help.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sssd offline on boot, stays offline forever
To manage no
** Tags added: server-next
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sssd offline on boot, stays offline forever
To manage notifications about this bug go to:
https://bugs.launch
I am trying to seed SSSD cache. The setup is working fine, I can do a
successful offline authentication but once I am connected to my company
network using VPN, SSSD cache is never refreshed unless I restart SSSD
or replace /etc/resolv.conf symlink (I am using systemd-resolved) by a
regular /etc/re
I agree. Do you have a way to reproduce this somewhat reliably?
** Changed in: sssd (Ubuntu Bionic)
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sss
The code in the PR above has now been pushed can we get a new build of
SSSD including it ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sssd offline on boot, stays offline forever
T
A PR which might address this was posted to the sssd mailing list:
https://github.com/SSSD/sssd/pull/864
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sssd offline on boot, stays offl
I can confirm the same issue with Ubuntu 18.04 (used the DVD). SSSD
cannot resolve the the backend and then says it's offline. Restarting
SSSD after a reboot always resolves the issue.
I've found two workarounds in 18.04:
1) Use your own resolv.conf and not rely on systemd-resolved.service.
"unl
I hit this bug too with Ubuntu 18.04. On boot sssd fails to find AD
servers from DNS and then continues to query 127.0.0.1 port 53, which
will never answer. The log looks like this:
(Wed Oct 10 13:04:13 2018) [sssd[be[ad.helsinki.fi]]] [resolv_getsrv_send]
(0x0100): Trying to resolve SRV record o
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: sssd (Ubuntu Bionic)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
Sorry, "fix released" is for the current development of Ubuntu which is
18.10. I'll add a task for bionic, and remove the artful one.
** Also affects: sssd (Ubuntu Bionic)
Importance: Undecided
Status: New
** Changed in: sssd (Ubuntu Artful)
Status: Triaged => Won't Fix
--
You
We are seeing this too, on Bionic servers installed from netboot / PXE.
Bionic is (still) missing from the Affected
Status says "Fix Released" but where is that? I don't think it's true.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
This also mostly applies to us:
* Bionic, installed via network installer.
* We did not configure network explicitly, AFAICT, this means networkd is used.
However, we run with DHCP.
* sssd.conf uses FQDNs for the kerberos and ldap servers (I guess you meant
that)?
* We also provide backup serv
I also have observed this problem on bionic for several different
computers. The workaround always solves the problem; without the
workaround I cannot log in. What the computers had in common:
* Using bionic (either the version from the DVD or with network updates)
* Using networkd rather than Net
After setting try_inotify to false, I see that the message that an
inotify was set up does not show up anymore, but no message that polling
is used instead is shown in the logs. If I understand the code
correctly, that's just right - a message will only be shown if
try_inotify is true and it actual
Interesting, I setup a watch on a directory to see what happens when a
symlink is changed:
https://pastebin.ubuntu.com/p/wKpMVY4dVz/
The watch on the "old" symlink definitely is lost via that operation, as
far as I can see.
--
You received this bug notification because you are a member of Ubunt
The sssd.conf manpage from sssd 1.13.4 and 1.16.1 (xenial and bionic)
says that without inotify sssd will fall back to polling resolv.conf
every 5s:
try_inotify (boolean)
SSSD monitors the state of resolv.conf to identify when it needs to update
its internal DNS resolver. By default, we will
@renbag: It might be that in terms of timing, the DHCP server is also involved,
since it defines the time network-online.target takes to start. Our setup is
relatively slow, since we have a DHCP server under high load (several 1
leases) and are using a dhcrelay in between.
Potentially, you
@renbag: Do you see "sssd[be[896]: Backend is offline" in "systemctl status
sssd"?
Is your backend server given as hostname / fqdn in sssd.conf?
@ahasenack: try_inotify=false did not change the issue at all. With strace, I
can still see 127.0.0.1 being queried. IMHO this can only be an ugly r
Since my last comment on this bug report (#16), I upgraded my
workstation from artful to bionic. The machine also has an NVME SSD, but
I do not see this sssd offline bug anymore.
However, I had intermittent problems in browsing the shares inside my AD domain
and, when I read here about possible r
Another issue appears to be...
When starting sssd in highest debug level, and then changing resolv.conf once
by doing:
$ touch foo
$ mv foo /run/systemd/resolve/stub-resolv.conf
(that's where the link target is pointing to), I see the expected:
(Tue Jun 12 00:16:57 2018) [sssd] [resolv_conf_inoti
I'll test tomorrow if try_inotify=false in the [sssd] section also works
around this issue, unless someone beats me to it...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sssd offline
Thanks for searching out this info!
I grepped through all logs for "inot" and found no match (only the initial
inotify setup). So it seems sssd was not notified via inotify of the change.
That matches the behaviour that "strace" showed that "127.0.0.1" instead of
"127.0.0.53" was queried.
So
The inotify callback would log this:
DEBUG(SSSDBG_TRACE_INTERNAL,
"Received inotify notification for %s\n", filename);
That is level 8 debugging:
./src/util/debug.h:#define SSSDBG_TRACE_INTERNAL 0x2000 /* level 8 */
--
You received this bug notification because you are a member
I can confirm that adding the described override, all works fine.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sssd offline on boot, stays offline forever
To manage notifications ab
Needless to say, resolv.conf is:
nameserver 127.0.0.53
search OUR.INSTITUTION
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sssd offline on boot, stays offline forever
To manage noti
Is this an inotify race due to the symlink-magic of systemd-resolved?
sssd.log:(Mon Jun 11 15:36:23 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
# ls -la /etc/resolv.c
That's interesting.
strace'ing the sssd_be process, it seems that it's trying to contact 127.0.0.1
as DNS server, and fails.
systemd-resolved is running on 127.0.0.53 and works just fine.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubun
Argh! My fault, with the typo fixed, I see the following:
Jun 11 15:36:27 exp006 sssd[be[918]: Backend is offline
[...]
(Mon Jun 11 15:36:31 2018) [sssd] [message_type] (0x0200): netlink Message
type: 24
(Mon Jun 11 15:36:31 2018) [sssd] [route_msg_debug_print] (0x1000): route idx 2
flags 0 fami
I tried wiht 0x7770 now in all sections, but I don't get more info.
Now, sssd.log shows:
(Mon Jun 11 15:10:34:313118 2018) [sssd] [sss_ini_call_validators] (0x0020):
[rule/allowed_sssd_options]: Attribute 'debug_devel' is not allowed in section
'sssd'. Check for typos.
for each section :-(.
So
I've now had a machine with actual failure and debug_level=9 in sections sssd,
pam and nss.
No more information was produced, just tons of
org.freedesktop.sssd.Error.DataProvider.Offline .
Seems that official manual is outdated, will try with bitmasks next.
--
You received this bug notificat
@ahasenack: Even in case things "work", I observe the following:
Jun 11 14:41:15 cip000 systemd[1]: Starting System Security Services Daemon...
Jun 11 14:41:24 cip000 sssd[920]: Starting up
Jun 11 14:41:25 cip000 sssd[be[998]: Starting up
Jun 11 14:41:28 cip000 sssd[1021]: Starting up
Jun 11 14:41
Maybe start with 6. From
https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html:
"""
To enable debugging persistently across SSSD service restarts, put the
directive debug_level=N, where N typically stands for a number between 1 and 10
into the particular section. Levels up to 3 should log
@jakub-hrozek: When activating debug_level on some machines, which level
is high enough?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sssd offline on boot, stays offline forever
To
Could somebody please add Bionic back?
We observe this on Bionic, it's pretty random, mostly machines with fast root
devices (e.g. NVMEs) are affected. Backend is offline on boot and stays
offline.
Since it's so random and I don't want to enable debug information on all
machines we have, I can
Are the sssd logs captured with a high enough debug_level in the [sssd]
section of sssd.conf? Normally sssd should detect notifications from
libnetlink and reset the offline status.. It would be nice to see those
and correlate with system logs..
--
You received this bug notification because you a
The workaround is the systemd unit file written in the Bug Description.
The 'cache credentials' config option does not have any effect on the bug and
for the tests I have disabled it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
ht
The workaround you speak of, is that the sssd option to cache
credentials, or the systemd unit file change to require network-
online.target?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Titl
/var/log/sssd/* attachment.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sssd offline on boot, stays offline forever
To manage notifications about this bug go to:
https://bugs.launc
** Attachment added: "var_log_sssd__artful.tgz"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1723350/+attachment/5136655/+files/var_log_sssd__artful.tgz
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.
@Andreas: thank you for your suggestions. I removed the workaround from
my artful machine and did what you asked, then, after some minutes, I
reactivated the workaround and did the same. All the logs are attached
for comparison (the real username and domain were redacted).
** Attachment added: "sy
@renbag could you please:
- add debug_level = 4 to [sssd] and your [domain/] sections
- reboot
- post the output of these commands right after:
systemd-analyze blame
systemd-analyze critical-chain
- login as a kerberos/ldap user, which has been failing
- check the new logs in /var/log/sssd/* tr
The artful machine is a workstation and has only a wired network interface
managed by network-manager that gets configured by a DHCP server on our LAN.
The files you requested are not present or have little or no information:
/etc/network/interfaces
---
I'll mark this as fix released for bionic then, and open up an artful
task.
** Also affects: sssd (Ubuntu Artful)
Importance: Undecided
Status: New
** Changed in: sssd (Ubuntu)
Status: Incomplete => Fix Released
** Summary changed:
- sssd offline on boot, stays offline forever
@renbag, can you share your network configuration on this artful
machine? These files:
/etc/network/interfaces
/etc/network/interfaces.d/*
/etc/netplan/*.yaml
And is this a desktop or a server?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
I confirmed the bug in artful, but now, with the same sssd.conf in
bionic, I do not see the bug anymore.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sssd offline on boot, stays offl
Reading what I wrote in comment #4, seems like I'm contradicting myself.
First I say I can reproduce the problem, but later I say that after I
bring the network back up it starts working again on its own. That's
exactly what I'm seeing now, i.e., no bug. Tried xenial, artful and
bionic. Are you guy
I also tried again in bionic, including rebooting the sssd client while
the krb5 server was offline, and it automatically switched back to an
online status after i restored the network on my krb5 server. I then
tried this again on xenial, and there it also worked.
let me try artful now.
--
You r
I tried the steps in #4. As expected, login failed while the network was
offline. It worked again immediately after enabling the network. So to
me it seems the problem really does not occur in bionic anymore.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
The test in comment #4 is more thorough, as it checks that sssd can
detect that the network is up again on its own. Can you try that on
bionic please?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723
@Simon: Interesting – I can't reproduce the problem in 18.04 anymore. I
tested a VM and a laptop using ethernet and wifi, and sssd was online on
boot without any workarounds.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs
Also affects Ubuntu Bionic (18.04)
A nicer workaround, for those using NetworkManager & systemd would be to tell
sssd to try going online when an interface comes up.
Create /etc/NetworkManager/dispatcher.d/sssd_notify with the contents:
#!/bin/bash
case "$2" in
up|vpn-up) systemctl kill --sig
** Changed in: sssd (Ubuntu)
Status: Confirmed => Triaged
** Changed in: sssd (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sssd of
I can confirm this is happening after a reboot, and that a simple USR2
signal fixes it, but I wonder why sssd doesn't get itself back into
online mode on its own in this case.
For example, I tried the following:
- login via kerberos using pam_sss while it was online
- got my ticket
- kdestroy, log
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: sssd (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1723350
Title:
sssd
I confirm the bug and that the workaround solves the problem.
If the sssd configuration doesn't include:
cache_credentials = true
it is not even possible to do an Active Directory login.
** Attachment added: "sssd.conf"
https://bugs.launchpad.net/ubuntu/+source/sssd/+bug/1723350/+attachment/4
83 matches
Mail list logo