Hi Sergio,
Sorry I don't understand why the bug's importance has decreased to "medium".
Du to client side behavior, issue is totally unpredictable, and slapd no longer
respond to requests.
Morever, the hot fix is not suited for production machines, and can introduce
regression.
Thanks.
--
You r
Hi Sergio,
Thanks I appreciate your answer.
Yes I can use the package provided in your PPA, even if it's not very
convenient to install and update it on Production machines. About that, will
you maintain these packages with further security updates ?
--
You received this bug notification becaus
Seems the patch is so hard to backport (?)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield syscall
Status in op
OK perfect )
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield syscall
Status in openldap package in Ubuntu:
Co
Hi Bryce, when will the fix be officially released ?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield syscall
St
Thanks for all )
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield syscall
Status in openldap package in Ubuntu:
OK the patch fix the issue for me too in my test env.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield syscall
S
My bad..
You're right, in my test, the second write() is performed on stdout cause my
ldapsearch command is wrong. I missed the '-H' arg to properly set the LDAP
URI (but you too :-p ).
Consequently, the connection was in LDAP not LDAPS, and "ldaps://..." was the
requested attributs :-s
So sin
Stephane,
I can't reproduce the hang on my test machine with gdb. (Despite your
investigation seems right for me). CPU usage stay low, as usual on this machine
(same slapd config than the production servers, but only 1 CPU is available).
To prove I made the right steps :-) :
$ gdb --args ldaps
Thank you for the patch and your investigations. In the next few days,
I cannot install the patched package on my production machines. I'll let
you know when I can.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in
Hi, yes it can occur on any machine (slave or master) with the same
configuration / OS.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infin
** Attachment removed: "slapd backtrace during sched_yield loop"
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+attachment/5495540/+files/2021070_backtrace_front02_..txt
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is
** Changed in: openldap (Ubuntu)
Status: Incomplete => New
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yiel
issue occured today to.
This time, I join a *full* backtrace .
** Attachment added: "2021010_backtrace_front01_FULL.txt"
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+attachment/5496108/+files/2021010_backtrace_front01_FULL.txt
--
You received this bug notification because
Nice day, 2 slapd malfunction in the same time, maybe du to network
connectivity issue.
I have the backtrace for one of them.
Please the the attachment.
Thanks.
** Attachment added: "slapd backtrace during sched_yield loop"
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+att
I plan to migrate BDB backend to MDB. Maybe it could help ?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield sysc
Thanks for your support.
> - Your full openldap configuration (please remove any confidential bits, of
> course).
There is lots of ldif files with many private datas. Do you need a particular
configuration ?
> - Any log messages from slapd or related services.
olcLogLevel is "sync stats". Durin
Public bug reported:
On a production server, sometimes slapd become unbresponsive, some threads
loops in sched_yield syscall and consumme all CPU.
To recover, slapd needs to restart.
No related information is reported in log file.
All same issues in OpenLDAP upstream project are old and fixed.
So
Is the fix released in Trustu ESM repository ? I don't see it.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to krb5 in Ubuntu.
https://bugs.launchpad.net/bugs/1817955
Title:
Getting new "DN is out of the realm subtree" erro
Even explicitly added subtree doesn't work:
# kdb5_ldap_util -D "cn=admin,dc=example,dc=com" -H
ldap://ldapserver.example.com modify -r TEST.EXAMPLE.COM -subtrees
'dc=example,dc=com:ou=People,dc=example,dc=com"
# kdb5_ldap_util -D "cn=admin,dc=example,dc=com" -H
ldap://ldapserver.example.com vie
Same error after upgrading krb5 packages from 1.12+dfsg-2ubuntu5.3 to
1.12+dfsg-2ubuntu5.4.
Adding a principal in a subtree outside the realm container fails.
Realm container DN is
"cn=TEST.EXAMPLE.COM,cn=krbContainer,dc=example,dc=com"
But realm has subtree "dc=example,dc=com", with scope = SUB
Problem solved: root cause wa the same id on the 2 machines in /etc
/machine-id
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1791245
Title:
bonding 802.3ad with systemd-
A workaround is to set manually a different MAC address in bond0.netdev:
[NetDev]
Name=bond0
Kind=bond
MACAddress=16:d6:b0:24:16:3c
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.ne
Public bug reported:
The problem seems to incriminate systemd-networkd (v229-4ubuntu21.1), not the
network/bonding configuration.
When a full bonding configuration is made with systemd in /etc/systemd/network,
on 2 two differents physical hosts, same hardware and in same VLAN:
- bond0.netde
** Package changed: openssh (Ubuntu) => xalan (Ubuntu)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1449637
Title:
no libxalan package version available with libxerces-c
Public bug reported:
On LTS Precise, there is no possibility to install/upgradeto libxerces v3
(libxerces-c-dev package) and keep libxalan librairies.
Precise distrib has only libxalan v1.10 packages (libxalan110,
libxalan110-dev), which works with libxerces-c2-dev but not libxerces-c-dev.
The l
26 matches
Mail list logo
