Public bug reported:
After a Systemd reload & any service restart, docker top no longer show process
of containers:
To reproduce this issue, do the following step:
# docker run -d --name test busybox sleep 1d
# docker top test
UID PID PPIDC
I've done the following thing to be sure the patch fix the issue:
* backported trusty version (2.4.31-1+nmu2ubuntu5) on precise. Run this
version, problem still occur
* backported trusty + patch (e.g. the 2.4.31-1+nmu2ubuntu5 + the debdiff
attached) on precise: Run this version, slapd start
Public bug reported:
We have setup a LDAP master-master replication using delta-sync. On the
2-node cluster, one server fail to restart with a segfault immediately
after the startup.
Every time we restart the server, it fail with:
/# slapd -u openldap -g openldap -d stats -f
I've attached the debdiff patch for trusty.
I'm building a backport for precise to test if slapd can start with this
patch applied (the server on which the issue occure is running precise).
** Patch added: lp1287730.debdiff
*** This bug is a duplicate of bug 1103260 ***
https://bugs.launchpad.net/bugs/1103260
Yes, the root cause is the same (nova-dhcpbridge init which sent already
expired lease). The fix proposed in bug #1103260 should fix this issue.
** This bug has been marked a duplicate of bug 1103260
Public bug reported:
TL; DR;
nova-dhcpbridge init generated leases file with instance updated_at
instead of fixed_ips updated_at, causing every leases to be expired for
several month. So everytime dnsmasq is restarted will sent DHCPNAK the
first time a client ask for renew its lease.
Long
I see two way for fixing the issue. The first one don't change the
db/api, but it's the a very nice fix. The second one seems to be the
correct way to fix this issue.
patch1.diff : always use time.time() + lease_time to set expiry in
nova/network/linux_net.py
patch2.diff : add updated
** Patch added: add updated (models.FixedIp.updated_at) in data returned by
db.api.network_get_associated_fixed_ips, and use this time when generating the
leases.
https://bugs.launchpad.net/ubuntu/+source/nova/+bug/1104915/+attachment/3499727/+files/patch2.diff
--
You received this bug
Public bug reported:
Software version:
* Description:Ubuntu 12.04.1 LTS
* arch : x86_64
* ntp 1:4.2.6.p3+dfsg-1ubuntu3.1
* libc6 2.15-0ubuntu10.2
We hit a strang behavious on some machine, where ntp refuse to quit if
stopped right after startup:
When running the following command:
** Attachment added: gdb info stack during deadlock (with packaged ntpd)
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1063806/+attachment/3386609/+files/gdb-stack.txt
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in
** Attachment added: script used to show the problem on my workstation
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1063806/+attachment/3386619/+files/ntpd_loop.py
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to ntp in
I confirm the version in proposed fix the issue:
* before installing proposed version, on fully updated precises : I still
reproduce the bug
* after installing slapd from proposed : I can't reproduce the bug.
Also on this machine, LDAP is used for local authentication, which still
work after
I have found an upstream ticket which seems to be exactly our issue:
ITS#7107 [1].
It's fixed on upstream, but was fixed after the release of 2.4.28. It's
a one line fix, see git commit [2].
I don't have tested if it effectivelly fix our issue, but description
seem very close to our problem.
in a loop id pierref, you
- may sometime have fewer group that you would normally have. And few
- seconds later, everything go back to normal.
+ * Any client connecting in LDAPv3 and using v3 specific feature may fail
+ * This include libnss-ldap (so id user may not return all group). Thus you
may
debdiff for precise sru.
** Patch added: lp1023025.debdiff
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+attachment/3228396/+files/lp1023025.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in
debdiff for quantal.
** Patch added: lp-1023025-quantal.debdiff
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+attachment/3228408/+files/lp-1023025-quantal.debdiff
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
Great. Thanks for your quick reactivity.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in Ubuntu.
https://bugs.launchpad.net/bugs/1023025
Title:
[SRU] search fail with get_ctrls : controls require LDAPv3
To manage
I can reproduce this issue with a simple ldapsearch:
ldapsearch -h ldap-1 -b ou=people,o=company -x
(((objectClass=posixAccount)(uid=*))(uid=pierref)) -M -v
Note: I think the exact query filter doesn't matter, only the -M switch
is important.
The result when it fail is:
ldap_initialize( ldap
Public bug reported:
On precise, the slapd daemon return error code 2 - controls require
LDAPv3 to client search. I don't see any reason why this would occure,
because if you run the same command few seconds later, it (may) work.
For example, using nss_ldap, when running in a loop id pierref
** Attachment added: Log on one of slapd server when bug occure
https://bugs.launchpad.net/bugs/1023025/+attachment/3218612/+files/syslog
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in Ubuntu.
** Attachment added: Configuration of slapd on master
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+attachment/3218625/+files/slapd-1.conf
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in Ubuntu.
** Attachment added: Configuration of slapd on slave
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1023025/+attachment/3218626/+files/slapd-2.conf
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in Ubuntu.
Thanks for the patch, with this patch I can't reproduce the bug.
I toke the patch, applied it on fresh apt-get source. builded it with a
pbuilder, installed the result. With that I was unable to reproduce the problem.
Got back to karmic release of openssh and I can reproduce the bug.
So the
Public bug reported:
When you send two SIGHUP to sshd (to reload it configuration), sshd
simply die.
How to reproduce:
1)start an sshd server
if you do killall -s SIGHUP sshd. The server restart successfully.
2) To kill sshd with SIGHUP, run killall -s SIGHUP sshd killall -s SIGHUP
sshd
Forget to tell the version affected:
This was tester on jaunty (with the killall -s SIGHUP).
The server is on hardy.
So hardy and jaunty are affected.
--
sshd stop on two SIGHUP
https://bugs.launchpad.net/bugs/497781
You received this bug notification because you are a member of Ubuntu
Server
+1
Also work for me.
Thanks
--
[SRU] fail2ban fails to start after reboot
https://bugs.launchpad.net/bugs/222804
You received this bug notification because you are a member of Ubuntu
Server Team, which is a direct subscriber.
--
Ubuntu-server-bugs mailing list
26 matches
Mail list logo
