[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
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 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:
Confirmed
Status in openldap source package in Bionic:
Triaged
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
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 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:
Confirmed
Status in openldap source package in Bionic:
Triaged
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
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 openldap package in Ubuntu:
Confirmed
Status in openldap source package in Bionic:
Triaged
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
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:
Confirmed
Status in openldap source package in Bionic:
Triaged
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
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
Status in openldap package in Ubuntu:
Confirmed
Status in openldap source package in Bionic:
Triaged
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
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:
Confirmed
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
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
Status in openldap package in Ubuntu:
Confirmed
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
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 since I learnt to make a good ldapsearch and opened my eyes to read gdb
output, I can fully reproducible the issue .
Thanks.
I'll test the patched version on my test machine.
--
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:
Confirmed
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
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 ldapsearch ldaps://front -x
[...]
(gdb) break write
Function "write" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (write) pending.
(gdb) run
Starting program: /usr/bin/ldapsearch ldaps://front -x
conti [Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, __GI___libc_write (fd=3, buf=0x5578b2f0, nbytes=14) at
../sysdeps/unix/sysv/linux/write.c:27
27 ../sysdeps/unix/sysv/linux/write.c: No such file or directory.
(gdb) continue
Continuing.
Breakpoint 1, __GI___libc_write (fd=1, buf=0x5578b2f0, nbytes=16) at
../sysdeps/unix/sysv/linux/write.c:27
27 in ../sysdeps/unix/sysv/linux/write.c
Another information (maybe not important, or not related to this case):
since monday, I started to migrate LDAP DB backend from BDB to LMDB.
So I must wait next slapd hang to be sure DB change have no impact on this
issue.
(in the past there were sometimes 2 or 3 weeks elapsed between two slap hang).
note: I reverted DB backend on my test machine but without reproducing the
issue too
--
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:
Confirmed
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
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 Ubuntu.
https://bugs.launchpad.net/bugs/1926265
Title:
slapd enter in infinite loop on sched_yield syscall
Status in openldap package in Ubuntu:
Confirmed
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
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 infinite loop on sched_yield syscall
Status in openldap package in Ubuntu:
New
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
** 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 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:
New
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
** 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_yield syscall
Status in openldap package in Ubuntu:
New
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
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 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:
Incomplete
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
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/+attachment/5495540/+files/2021070_backtrace_front02_..txt
--
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:
Incomplete
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
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 syscall
Status in openldap package in Ubuntu:
Incomplete
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] Re: slapd enter in infinite loop on sched_yield syscall
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". During the last 40 minutes before (forced) kill,
slapd send no more logs to syslog. You can see below an extract but it doesn't
help:
Apr 27 04:50:01 front01 slapd[1023]: conn=10282468 fd=732 TLS established
tls_ssf=128 ssf=128
Apr 27 04:50:01 front01 slapd[1023]: conn=10282453 op=13 SRCH
base="cn=Write,cn=Waiters,cn=Monitor" scope=0 deref=2 filter="(objectClass=*)"
Apr 27 04:50:01 front01 slapd[1023]: conn=10282453 op=13 SRCH
attr=monitorCounter
Apr 27 05:31:59 front01 slapd[1023]: daemon: shutdown requested and initiated.
Apr 27 05:31:59 front01 slapd[1023]: conn=10281700 fd=16 closed (slapd shutdown)
[...777 more . ]
Apr 27 05:31:59 front01 slapd[1023]: conn=10276270 fd=854 closed (slapd
shutdown)
Apr 27 05:31:59 front01 slapd[1023]: daemon: shutdown requested and initiated.
Apr 27 05:32:18 front01 slapd[122011]: @(#) $OpenLDAP: slapd (Ubuntu) (Feb 18
2021 14:22:42) $#012#011Debian OpenLDAP Maintainers
Apr 27 05:32:18 front01 slapd[122012]: bdb_db_open: database "dc=fti,dc=net":
unclean shutdown detected; attempting recovery.
Apr 27 05:32:26 front01 slapd[122012]: slapd starting
>- If you can, please install the debug symbols for openldap/slapd and run "gdb
>-p
> $PROCESS_PID" (where "$PROCESS_PID" is slapd's PID), then run a "bt" command
> and attach
> the output to this bug.
Ok I install the debugging package "slapd-dbgsym" to provide a backtrace next
time.
>- More information about what is going on in the system when the problem
>happens. For
> example, I've read that this might happen when the system load is high; do
> you notice that
> as well?
The servers hosting slapd are constantly under load, but issue occur even when
overall CPU usage is about 5% ..
Maybe it can help you: the problem didn't occur on old Trusty machines (same
config, same load).
--
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:
Incomplete
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1926265] [NEW] slapd enter in infinite loop on sched_yield syscall
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
** Affects: openldap (Ubuntu)
Importance: Undecided
Status: 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_yield syscall
Status in openldap package in Ubuntu:
New
Bug description:
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 maybe this issue affects only Ubuntu package.
It occurs randomly, so I have no steps to reproduce.
OS : Bionic
Openldap version:
libldap-2.4-2:amd642.4.45+dfsg-1ubuntu1.10
libldap-common 2.4.45+dfsg-1ubuntu1.10
slapd 2.4.45+dfsg-1ubuntu1.10
Modules loaded:
olcModuleLoad: {0}back_bdb
olcModuleLoad: {1}syncprov
olcModuleLoad: {2}back_monitor
olcModuleLoad: {3}memberof.la
olcModuleLoad: {4}refint.la
olcModuleLoad: {5}rwm
olcModuleload: {6}back_ldap
Backend is BDB. slapd run in (single) master - (multi) slave mode.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1926265/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1817955] Re: Getting new "DN is out of the realm subtree" error on adding principal
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" error on adding principal Status in krb5 package in Ubuntu: Fix Released Status in krb5 source package in Trusty: Triaged Bug description: Recently applied security update to 14.04.5 LTS kerberos (1.12+dfsg- 2ubuntu5.4), and started getting errors when adding new principals to LDAP. Obfuscated example: kadmin.local -q "ank -x dn=\"uid=testuser,ou=People,dc=example,dc=com\" -pw \"dummypass\" testuser" now gives: Authenticating as principal root/ad...@test.example.com with password. NOTICE: no policy specified for testu...@test.example.com; assigning "default" add_principal: DN is out of the realm subtree while creating "testu...@test.example.com". This worked up through 1.12+dfsg-2ubuntu5.3, and I think it now fails due to changes in src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c in response to CVE-2018-5729 or CVE-2018-5730. I'm going to attempt a downgrade to 1.12+dfsg-2ubuntu5.3 to check. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1817955/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1817955] Re: Getting new "DN is out of the realm subtree" error on adding principal
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 view -r TEST.EXAMPLE.COM Realm Name: TEST.EXAMPLE.COM Subtree: dc=example,dc=com Subtree: ou=People,dc=example,dc=com SearchScope: SUB Still get the error "DN is out of the realm subtree" when adding a principal in "ou=People,dc=example,dc=com" -- 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" error on adding principal Status in krb5 package in Ubuntu: New Bug description: Recently applied security update to 14.04.5 LTS kerberos (1.12+dfsg- 2ubuntu5.4), and started getting errors when adding new principals to LDAP. Obfuscated example: kadmin.local -q "ank -x dn=\"uid=testuser,ou=People,dc=example,dc=com\" -pw \"dummypass\" testuser" now gives: Authenticating as principal root/ad...@test.example.com with password. NOTICE: no policy specified for testu...@test.example.com; assigning "default" add_principal: DN is out of the realm subtree while creating "testu...@test.example.com". This worked up through 1.12+dfsg-2ubuntu5.3, and I think it now fails due to changes in src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c in response to CVE-2018-5729 or CVE-2018-5730. I'm going to attempt a downgrade to 1.12+dfsg-2ubuntu5.3 to check. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1817955/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1817955] Re: Getting new "DN is out of the realm subtree" error on adding principal
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: # kdb5_ldap_util -D "cn=admin,dc=example,dc=com" -H ldap://ldapserver.example.com view -r TEST.EXAMPLE.COM Realm Name: TEST.EXAMPLE.COM Subtree: dc=example,dc=com SearchScope: SUB So I should add a principal anywhere in "dc=example,dc=com" , e.g. "ou=People,dc=example,dc=com" . -- 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" error on adding principal Status in krb5 package in Ubuntu: New Bug description: Recently applied security update to 14.04.5 LTS kerberos (1.12+dfsg- 2ubuntu5.4), and started getting errors when adding new principals to LDAP. Obfuscated example: kadmin.local -q "ank -x dn=\"uid=testuser,ou=People,dc=example,dc=com\" -pw \"dummypass\" testuser" now gives: Authenticating as principal root/ad...@test.example.com with password. NOTICE: no policy specified for testu...@test.example.com; assigning "default" add_principal: DN is out of the realm subtree while creating "testu...@test.example.com". This worked up through 1.12+dfsg-2ubuntu5.3, and I think it now fails due to changes in src/plugins/kdb/ldap/libkdb_ldap/ldap_principal2.c in response to CVE-2018-5729 or CVE-2018-5730. I'm going to attempt a downgrade to 1.12+dfsg-2ubuntu5.3 to check. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/krb5/+bug/1817955/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791245] Re: bonding 802.3ad with systemd-networkd: duplicate MAC address on 2 different hosts
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-networkd: duplicate MAC address on 2 different hosts Status in systemd package in Ubuntu: New Bug description: 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.netdev -- [NetDev] Name=bond0 Kind=bond [Bond] Mode=802.3ad TransmitHashPolicy=layer3+4 MIIMonitorSec=100ms LACPTransmitRate=fast - vlan3147.netdev -- [NetDev] Name=vlan3147 Kind=vlan [VLAN] Id=3147 - bond0.network -- [Match] Name=bond0 [Network] VLAN=vlan3147 BindCarrier=enp1s0f1 enp1s0f0 LinkLocalAddressing=no - enp1s0f0.network -- [Match] Name=enp1s0f0 [Network] Bond=bond0 - enp1s0f1.network -- [Match] Name=enp1s0f1 [Network] Bond=bond0 - vlan3147.network -- [Match] Name=vlan3147 [Address] Address=**masked ip***/25 [Route] Destination=10.0.0.0/8 Gateway=**masked ip*** [Route] Destination=**masked ip***/16 Gateway=**masked ip*** And in /etc/modprobe.d/bonding.conf options bonding max_bonds=0 . the two different physicals hosts have the same MAC address on bonding: on host A: 32: bond0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 16:d6:b0:24:16:3b brd ff:ff:ff:ff:ff:ff on host B: 32: bond0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 16:d6:b0:24:16:3b brd ff:ff:ff:ff:ff:ff So strange... how the MAC is generated ? There is no relevant rules in /etc/udev/rules.d/70-persistent-net.rules to explain it, and issue occurs only with systemd-network, *NOT* with legacy configuration /etc/network/interfaces. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1791245/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791245] Re: bonding 802.3ad with systemd-networkd: duplicate MAC address on 2 different hosts
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.net/bugs/1791245 Title: bonding 802.3ad with systemd-networkd: duplicate MAC address on 2 different hosts Status in systemd package in Ubuntu: New Bug description: 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.netdev -- [NetDev] Name=bond0 Kind=bond [Bond] Mode=802.3ad TransmitHashPolicy=layer3+4 MIIMonitorSec=100ms LACPTransmitRate=fast - vlan3147.netdev -- [NetDev] Name=vlan3147 Kind=vlan [VLAN] Id=3147 - bond0.network -- [Match] Name=bond0 [Network] VLAN=vlan3147 BindCarrier=enp1s0f1 enp1s0f0 LinkLocalAddressing=no - enp1s0f0.network -- [Match] Name=enp1s0f0 [Network] Bond=bond0 - enp1s0f1.network -- [Match] Name=enp1s0f1 [Network] Bond=bond0 - vlan3147.network -- [Match] Name=vlan3147 [Address] Address=**masked ip***/25 [Route] Destination=10.0.0.0/8 Gateway=**masked ip*** [Route] Destination=**masked ip***/16 Gateway=**masked ip*** And in /etc/modprobe.d/bonding.conf options bonding max_bonds=0 . the two different physicals hosts have the same MAC address on bonding: on host A: 32: bond0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 16:d6:b0:24:16:3b brd ff:ff:ff:ff:ff:ff on host B: 32: bond0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 16:d6:b0:24:16:3b brd ff:ff:ff:ff:ff:ff So strange... how the MAC is generated ? There is no relevant rules in /etc/udev/rules.d/70-persistent-net.rules to explain it, and issue occurs only with systemd-network, *NOT* with legacy configuration /etc/network/interfaces. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1791245/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1791245] [NEW] bonding 802.3ad with systemd-networkd: duplicate MAC address on 2 different hosts
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.netdev -- [NetDev] Name=bond0 Kind=bond [Bond] Mode=802.3ad TransmitHashPolicy=layer3+4 MIIMonitorSec=100ms LACPTransmitRate=fast - vlan3147.netdev -- [NetDev] Name=vlan3147 Kind=vlan [VLAN] Id=3147 - bond0.network -- [Match] Name=bond0 [Network] VLAN=vlan3147 BindCarrier=enp1s0f1 enp1s0f0 LinkLocalAddressing=no - enp1s0f0.network -- [Match] Name=enp1s0f0 [Network] Bond=bond0 - enp1s0f1.network -- [Match] Name=enp1s0f1 [Network] Bond=bond0 - vlan3147.network -- [Match] Name=vlan3147 [Address] Address=**masked ip***/25 [Route] Destination=10.0.0.0/8 Gateway=**masked ip*** [Route] Destination=**masked ip***/16 Gateway=**masked ip*** And in /etc/modprobe.d/bonding.conf options bonding max_bonds=0 . the two different physicals hosts have the same MAC address on bonding: on host A: 32: bond0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 16:d6:b0:24:16:3b brd ff:ff:ff:ff:ff:ff on host B: 32: bond0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 16:d6:b0:24:16:3b brd ff:ff:ff:ff:ff:ff So strange... how the MAC is generated ? There is no relevant rules in /etc/udev/rules.d/70-persistent-net.rules to explain it, and issue occurs only with systemd-network, *NOT* with legacy configuration /etc/network/interfaces. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Summary changed: - bonding 802.3ad systemd-networkd: bond IF 802.3ad duplicate MAC address on 2 different hostsa duplicate MAC address on 2 different hosts + bonding 802.3ad systemd-networkd: bond IF 802.3ad duplicate MAC address on 2 different hosts ** Summary changed: - bonding 802.3ad systemd-networkd: bond IF 802.3ad duplicate MAC address on 2 different hosts + bonding 802.3ad systemd-networkd: duplicate MAC address on 2 different hosts ** Summary changed: - bonding 802.3ad systemd-networkd: duplicate MAC address on 2 different hosts + bonding 802.3ad with systemd-networkd: duplicate MAC address on 2 different hosts ** Package changed: ifenslave (Ubuntu) => systemd (Ubuntu) -- 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-networkd: duplicate MAC address on 2 different hosts Status in systemd package in Ubuntu: New Bug description: 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.netdev -- [NetDev] Name=bond0 Kind=bond [Bond] Mode=802.3ad TransmitHashPolicy=layer3+4 MIIMonitorSec=100ms LACPTransmitRate=fast - vlan3147.netdev -- [NetDev] Name=vlan3147 Kind=vlan [VLAN] Id=3147 - bond0.network -- [Match] Name=bond0 [Network] VLAN=vlan3147 BindCarrier=enp1s0f1 enp1s0f0 LinkLocalAddressing=no - enp1s0f0.network -- [Match] Name=enp1s0f0 [Network] Bond=bond0 - enp1s0f1.network -- [Match] Name=enp1s0f1 [Network] Bond=bond0 - vlan3147.network -- [Match] Name=vlan3147 [Address] Address=**masked ip***/25 [Route] Destination=10.0.0.0/8 Gateway=**masked ip*** [Route] Destination=**masked ip***/16 Gateway=**masked ip*** And in /etc/modprobe.d/bonding.conf options bonding max_bonds=0 . the two different physicals hosts have the same MAC address on bonding: on host A: 32: bond0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 16:d6:b0:24:16:3b brd ff:ff:ff:ff:ff:ff on host B: 32: bond0: mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000 link/ether 16:d6:b0:24:16:3b brd ff:ff:ff:ff:ff:ff So strange... how the MAC is generated ? There is no relevant rules in /etc/udev/rules.d/70-persistent-net.rules to explain it, and issue occurs only with systemd-network, *NOT* with legacy configuration /etc/network/interfaces. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1791245/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1449637] Re: no libxalan package version available with libxerces-c-dev
** 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-dev Status in xalan package in Ubuntu: New Bug description: 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 libxalan version neeeded is 1.11 but is only available on Trusty : libxalan-c-dev 1.11-3 XSLT processor library for C++ [development] libxalan-c111 1.11-3 XSLT processor library for C++ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xalan/+bug/1449637/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1449637] [NEW] no libxalan package version available with libxerces-c-dev
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 libxalan version neeeded is 1.11 but is only available on Trusty : libxalan-c-dev 1.11-3 XSLT processor library for C++ [development] libxalan-c111 1.11-3 XSLT processor library for C++ ** Affects: xalan (Ubuntu) Importance: Undecided Status: New -- 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-dev Status in xalan package in Ubuntu: New Bug description: 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 libxalan version neeeded is 1.11 but is only available on Trusty : libxalan-c-dev 1.11-3 XSLT processor library for C++ [development] libxalan-c111 1.11-3 XSLT processor library for C++ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/xalan/+bug/1449637/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
