[Touch-packages] [Bug 1872106] Re: isc-dhcp-server crashing constantly [Ubuntu 20.04]

[Jorge Niedbalski]

Hello Karsten,

Can you check comments https://bugs.launchpad.net/dhcp/+bug/1872118/comments/62
 and https://bugs.launchpad.net/dhcp/+bug/1872118/comments/63 and validate the 
versions?

* Also, could be possible to upload the crash report here? and the
output of dpkg -l

Thanks,

Jorge

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872106

Title:
  isc-dhcp-server crashing constantly [Ubuntu 20.04]

Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in isc-dhcp source package in Focal:
  Confirmed

Bug description:
  isc-dhcp-server crashing constantly (sometimes within seconds or minutes, 
sometimes within hours) with the following error messages:
  Apr 10 17:45:25 xxx dhcpd[140823]: Server starting service.
  Apr 10 17:45:25 xxx sh[140823]: ../../../../lib/isc/unix/socket.c:3361: 
INSIST(!sock->pending_send) failed, back trace
  Apr 10 17:45:25 xxx sh[140823]: #0 0x7f3362f59a4a in ??
  Apr 10 17:45:25 xxx sh[140823]: #1 0x7f3362f59980 in ??
  Apr 10 17:45:25 xxx sh[140823]: #2 0x7f3362f957e1 in ??
  Apr 10 17:45:25 xxx sh[140823]: #3 0x7f3362d3c609 in ??
  Apr 10 17:45:25 xxx sh[140823]: #4 0x7f3362e78103 in ??
  Apr 10 17:45:25 xxx systemd[1]: isc-dhcp-server.service: Main process exited, 
code=killed, status=6/ABRT
  Apr 10 17:45:25 xxx systemd[1]: isc-dhcp-server.service: Failed with result 
'signal'.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1872106/+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 1872118] Re: [SRU] DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

** No longer affects: isc-dhcp (Ubuntu)

** No longer affects: isc-dhcp (Ubuntu Focal)

** No longer affects: isc-dhcp (Ubuntu Groovy)

** Changed in: bind9-libs (Ubuntu Groovy)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  [SRU] DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  Fix Released
Status in bind9-libs source package in Focal:
  Fix Committed
Status in bind9-libs source package in Groovy:
  Fix Released

Bug description:
  [Description]

  isc-dhcp-server uses libisc-export (coming from bind9-libs package) for 
handling the socket event(s) when configured in peer mode (master/secondary). 
It's possible that a sequence of messages dispatched by the master that 
requires acknowledgment from its peers holds a socket
  in a pending to send state, a timer or a subsequent write request can be 
scheduled into this socket and the !sock->pending_send assertion
  will be raised when trying to write again at the time data hasn't been 
flushed entirely and the pending_send flag hasn't been reset to 0 state.

  If this race condition happens, the following stacktrace will be
  hit:

  (gdb) info threads
    Id Target Id Frame
  * 1 Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
    2 Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait 
(futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52
    3 Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, 
processes_to_wake=1, futex_word=) at 
../sysdeps/nptl/futex-internal.h:364
    4 Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable 
(private=, expected=0, futex_word=0x7fb4de6cd0d0) at 
../sysdeps/nptl/futex-internal.h:183

  (gdb) frame 2
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  (gdb) bt
  #1 0x7fb4deaa7859 in __GI_abort () at abort.c:79
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  #4 process_fd (writeable=, readable=, fd=11, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054
  #5 process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211
  #6 watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397
  #7 0x7fb4dea68609 in start_thread (arg=) at 
pthread_create.c:477
  #8 0x7fb4deba4103 in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

  (gdb) frame 3
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  4041 in ../../../../lib/isc/unix/socket.c
  (gdb) p sock->pending_send
  $2 = 1

  [TEST CASE]

  1) Install isc-dhcp-server in 2 focal machine(s).
  2) Configure peer/cluster mode as follows:
     Primary configuration: https://pastebin.ubuntu.com/p/XYj648MghK/
     Secondary configuration: https://pastebin.ubuntu.com/p/PYkcshZCWK/
  2) Run dhcpd as follows in both machine(s)

  # dhcpd -f -d -4 -cf /etc/dhcp/dhcpd.conf --no-pid ens4

  3) Leave the cluster running for a long (2h) period until the
  crash/race condition is reproduced.

  [REGRESSION POTENTIAL]

  * The fix will prevent the assertion to happen in the dispatch_send
  path, later versions of isch-dhcp upstream lack this logic and entirely 
removed the existence of this flag. Therefore, removing the need for this
  assertion at process_fd shouldn't be problematic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1872118] Re: [SRU] DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

** Patch added: "lp-1872118-focal.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1872118/+attachment/5400761/+files/lp-1872118-focal.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  [SRU] DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  In Progress
Status in isc-dhcp package in Ubuntu:
  In Progress
Status in bind9-libs source package in Focal:
  In Progress
Status in isc-dhcp source package in Focal:
  In Progress
Status in bind9-libs source package in Groovy:
  In Progress
Status in isc-dhcp source package in Groovy:
  In Progress

Bug description:
  [Description]

  isc-dhcp-server uses libisc-export (coming from bind9-libs package) for 
handling the socket event(s) when configured in peer mode (master/secondary). 
It's possible that a sequence of messages dispatched by the master that 
requires acknowledgment from its peers holds a socket
  in a pending to send state, a timer or a subsequent write request can be 
scheduled into this socket and the !sock->pending_send assertion
  will be raised when trying to write again at the time data hasn't been 
flushed entirely and the pending_send flag hasn't been reset to 0 state.

  If this race condition happens, the following stacktrace will be
  hit:

  (gdb) info threads
    Id Target Id Frame
  * 1 Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
    2 Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait 
(futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52
    3 Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, 
processes_to_wake=1, futex_word=) at 
../sysdeps/nptl/futex-internal.h:364
    4 Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable 
(private=, expected=0, futex_word=0x7fb4de6cd0d0) at 
../sysdeps/nptl/futex-internal.h:183

  (gdb) frame 2
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  (gdb) bt
  #1 0x7fb4deaa7859 in __GI_abort () at abort.c:79
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  #4 process_fd (writeable=, readable=, fd=11, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054
  #5 process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211
  #6 watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397
  #7 0x7fb4dea68609 in start_thread (arg=) at 
pthread_create.c:477
  #8 0x7fb4deba4103 in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

  (gdb) frame 3
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  4041 in ../../../../lib/isc/unix/socket.c
  (gdb) p sock->pending_send
  $2 = 1

  [TEST CASE]

  1) Install isc-dhcp-server in 2 focal machine(s).
  2) Configure peer/cluster mode as follows:
     Primary configuration: https://pastebin.ubuntu.com/p/XYj648MghK/
     Secondary configuration: https://pastebin.ubuntu.com/p/PYkcshZCWK/
  2) Run dhcpd as follows in both machine(s)

  # dhcpd -f -d -4 -cf /etc/dhcp/dhcpd.conf --no-pid ens4

  3) Leave the cluster running for a long (2h) period until the
  crash/race condition is reproduced.

  [REGRESSION POTENTIAL]

  * The fix will prevent the assertion to happen in the dispatch_send
  path, later versions of isch-dhcp upstream lack this logic and entirely 
removed the existence of this flag. Therefore, removing the need for this
  assertion at process_fd shouldn't be problematic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1872118] Re: [SRU] DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

** Patch added: "lp-1872118-groovy.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1872118/+attachment/5400760/+files/lp-1872118-groovy.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  [SRU] DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  In Progress
Status in isc-dhcp package in Ubuntu:
  In Progress
Status in bind9-libs source package in Focal:
  In Progress
Status in isc-dhcp source package in Focal:
  In Progress
Status in bind9-libs source package in Groovy:
  In Progress
Status in isc-dhcp source package in Groovy:
  In Progress

Bug description:
  [Description]

  isc-dhcp-server uses libisc-export (coming from bind9-libs package) for 
handling the socket event(s) when configured in peer mode (master/secondary). 
It's possible that a sequence of messages dispatched by the master that 
requires acknowledgment from its peers holds a socket
  in a pending to send state, a timer or a subsequent write request can be 
scheduled into this socket and the !sock->pending_send assertion
  will be raised when trying to write again at the time data hasn't been 
flushed entirely and the pending_send flag hasn't been reset to 0 state.

  If this race condition happens, the following stacktrace will be
  hit:

  (gdb) info threads
    Id Target Id Frame
  * 1 Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
    2 Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait 
(futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52
    3 Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, 
processes_to_wake=1, futex_word=) at 
../sysdeps/nptl/futex-internal.h:364
    4 Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable 
(private=, expected=0, futex_word=0x7fb4de6cd0d0) at 
../sysdeps/nptl/futex-internal.h:183

  (gdb) frame 2
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  (gdb) bt
  #1 0x7fb4deaa7859 in __GI_abort () at abort.c:79
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  #4 process_fd (writeable=, readable=, fd=11, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054
  #5 process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211
  #6 watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397
  #7 0x7fb4dea68609 in start_thread (arg=) at 
pthread_create.c:477
  #8 0x7fb4deba4103 in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

  (gdb) frame 3
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  4041 in ../../../../lib/isc/unix/socket.c
  (gdb) p sock->pending_send
  $2 = 1

  [TEST CASE]

  1) Install isc-dhcp-server in 2 focal machine(s).
  2) Configure peer/cluster mode as follows:
     Primary configuration: https://pastebin.ubuntu.com/p/XYj648MghK/
     Secondary configuration: https://pastebin.ubuntu.com/p/PYkcshZCWK/
  2) Run dhcpd as follows in both machine(s)

  # dhcpd -f -d -4 -cf /etc/dhcp/dhcpd.conf --no-pid ens4

  3) Leave the cluster running for a long (2h) period until the
  crash/race condition is reproduced.

  [REGRESSION POTENTIAL]

  * The fix will prevent the assertion to happen in the dispatch_send
  path, later versions of isch-dhcp upstream lack this logic and entirely 
removed the existence of this flag. Therefore, removing the need for this
  assertion at process_fd shouldn't be problematic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1872118] Re: [SRU] DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

Uploaded debdiff(s) for groovy and focal. This will require a follow up
rebuild change for isc-dhcp, once the library change lands.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  [SRU] DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  In Progress
Status in isc-dhcp package in Ubuntu:
  In Progress
Status in bind9-libs source package in Focal:
  In Progress
Status in isc-dhcp source package in Focal:
  In Progress
Status in bind9-libs source package in Groovy:
  In Progress
Status in isc-dhcp source package in Groovy:
  In Progress

Bug description:
  [Description]

  isc-dhcp-server uses libisc-export (coming from bind9-libs package) for 
handling the socket event(s) when configured in peer mode (master/secondary). 
It's possible that a sequence of messages dispatched by the master that 
requires acknowledgment from its peers holds a socket
  in a pending to send state, a timer or a subsequent write request can be 
scheduled into this socket and the !sock->pending_send assertion
  will be raised when trying to write again at the time data hasn't been 
flushed entirely and the pending_send flag hasn't been reset to 0 state.

  If this race condition happens, the following stacktrace will be
  hit:

  (gdb) info threads
    Id Target Id Frame
  * 1 Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
    2 Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait 
(futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52
    3 Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, 
processes_to_wake=1, futex_word=) at 
../sysdeps/nptl/futex-internal.h:364
    4 Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable 
(private=, expected=0, futex_word=0x7fb4de6cd0d0) at 
../sysdeps/nptl/futex-internal.h:183

  (gdb) frame 2
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  (gdb) bt
  #1 0x7fb4deaa7859 in __GI_abort () at abort.c:79
  #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
  cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  #4 process_fd (writeable=, readable=, fd=11, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054
  #5 process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211
  #6 watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397
  #7 0x7fb4dea68609 in start_thread (arg=) at 
pthread_create.c:477
  #8 0x7fb4deba4103 in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

  (gdb) frame 3
  #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
  4041 in ../../../../lib/isc/unix/socket.c
  (gdb) p sock->pending_send
  $2 = 1

  [TEST CASE]

  1) Install isc-dhcp-server in 2 focal machine(s).
  2) Configure peer/cluster mode as follows:
     Primary configuration: https://pastebin.ubuntu.com/p/XYj648MghK/
     Secondary configuration: https://pastebin.ubuntu.com/p/PYkcshZCWK/
  2) Run dhcpd as follows in both machine(s)

  # dhcpd -f -d -4 -cf /etc/dhcp/dhcpd.conf --no-pid ens4

  3) Leave the cluster running for a long (2h) period until the
  crash/race condition is reproduced.

  [REGRESSION POTENTIAL]

  * The fix will prevent the assertion to happen in the dispatch_send
  path, later versions of isch-dhcp upstream lack this logic and entirely 
removed the existence of this flag. Therefore, removing the need for this
  assertion at process_fd shouldn't be problematic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1872118] Re: [SRU] DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

** Description changed:

+ [Description]
  
- I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All 
worked perfectly until recently, when they started stopping with code=killed, 
status=6/ABRT.
- This is being fixed by 
+ isc-dhcp-server uses libisc-export (coming from bin9-libs package) for 
handling the socket event(s) when configured in peer mode (master/secondary). 
It's possible that a sequence of messages dispatched by the master that 
requires acknowledgment from its peers holds a socket
+ in a pending to send state, a timer or a subsequent write request can be 
scheduled into this socket and the !sock->pending_send assertion
+ will be raised when trying to write again at the time data hasn't been 
flushed entirely and the pending_send flag hasn't been reset to 0 state.
  
- https://bugs.launchpad.net/bugs/1870729
+ If this race condition happens, the following stacktrace will be
+ hit:
  
- However now one stops after a few hours with the following errors. One
- can stay on line but not both.
+ (gdb) info threads
+   Id Target Id Frame
+ * 1 Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
+   2 Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait 
(futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52
+   3 Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, 
processes_to_wake=1, futex_word=) at 
../sysdeps/nptl/futex-internal.h:364
+   4 Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable 
(private=, expected=0, futex_word=0x7fb4de6cd0d0) at 
../sysdeps/nptl/futex-internal.h:183
+ 
+ (gdb) frame 2
+ #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
+ cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
+ (gdb) bt
+ #1 0x7fb4deaa7859 in __GI_abort () at abort.c:79
+ #2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
+ cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
+ #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
+ #4 process_fd (writeable=, readable=, fd=11, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054
+ #5 process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211
+ #6 watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397
+ #7 0x7fb4dea68609 in start_thread (arg=) at 
pthread_create.c:477
+ #8 0x7fb4deba4103 in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95
+ 
+ (gdb) frame 3
+ #3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
+ 4041 in ../../../../lib/isc/unix/socket.c
+ (gdb) p sock->pending_send
+ $2 = 1
+ 
+ [TEST CASE]
+ 
+ 1) Install isc-dhcp-server in 2 focal machine(s).
+ 2) Configure peer/cluster mode as follows:
+Primary configuration: https://pastebin.ubuntu.com/p/XYj648MghK/
+Secondary configuration: https://pastebin.ubuntu.com/p/PYkcshZCWK/
+ 2) Run dhcpd as follows in both machine(s)
+ 
+ # dhcpd -f -d -4 -cf /etc/dhcp/dhcpd.conf --no-pid ens4
+ 
+ 3) Leave the cluster running for a long (2h) period until the crash/race
+ condition is reproduced.
  
  
+ [REGRESSION POTENTIAL]
  
- Syslog shows 
- Apr 10 17:20:15 dhcp-primary sh[6828]: 
../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, 
back trace
- Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ??
- Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ??
- Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ??
- Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ??
- Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ??
- 
- 
- nothing in kern.log
- 
- 
- apport.log shows
- ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, 
signal 6, core limit 0, dump mode 2
- ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid 
with dump mode of 2
- ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: 
/usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf")
- ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no 
DBUS_SESSION_BUS_ADDRESS in environment
- ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report 
/var/crash/_usr_sbin_dhcpd.0.crash
- 
- 
- /var/crash/_usr_sbin_dhcpd.0.crash shows
- 
- ProblemType: Crash
- Architecture: amd64
- CrashCounter: 1
- Date: Fri Apr 10 17:20:15 2020
- DistroRelease: Ubuntu 20.04
- ExecutablePath: /usr/sbin/dhcpd
- ExecutableTimestamp: 1586210315
- ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf 

[Touch-packages] [Bug 1872118] Re: [SRU] DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

** Summary changed:

- DHCP Cluster crashes after a few hours
+ [SRU] DHCP Cluster crashes after a few hours

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  [SRU] DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  In Progress
Status in isc-dhcp package in Ubuntu:
  In Progress
Status in bind9-libs source package in Focal:
  In Progress
Status in isc-dhcp source package in Focal:
  In Progress
Status in bind9-libs source package in Groovy:
  In Progress
Status in isc-dhcp source package in Groovy:
  In Progress

Bug description:
  
  I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All 
worked perfectly until recently, when they started stopping with code=killed, 
status=6/ABRT.
  This is being fixed by 

  https://bugs.launchpad.net/bugs/1870729

  However now one stops after a few hours with the following errors. One
  can stay on line but not both.


  
  Syslog shows 
  Apr 10 17:20:15 dhcp-primary sh[6828]: 
../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, 
back trace
  Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ??

  
  nothing in kern.log

  
  apport.log shows
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, 
signal 6, core limit 0, dump mode 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid 
with dump mode of 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: 
/usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf")
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no 
DBUS_SESSION_BUS_ADDRESS in environment
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report 
/var/crash/_usr_sbin_dhcpd.0.crash


  /var/crash/_usr_sbin_dhcpd.0.crash shows

  ProblemType: Crash
  Architecture: amd64
  CrashCounter: 1
  Date: Fri Apr 10 17:20:15 2020
  DistroRelease: Ubuntu 20.04
  ExecutablePath: /usr/sbin/dhcpd
  ExecutableTimestamp: 1586210315
  ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf
  ProcEnviron: Error: [Errno 13] Permission denied: 'environ'
  ProcMaps: Error: [Errno 13] Permission denied: 'maps'
  ProcStatus:
   Name:  dhcpd
   Umask: 0022
   State: D (disk sleep)
   Tgid:  6828
   Ngid:  0
   Pid:   6828
   PPid:  1
   TracerPid: 0
   Uid:   113 113 113 113
   Gid:   118 118 118 118
   FDSize:128
   Groups:
   NStgid:6828
   NSpid: 6828
   NSpgid:6828
   NSsid: 6828
   VmPeak:  236244 kB
   VmSize:  170764 kB
   VmLck:0 kB
   VmPin:0 kB
   VmHWM:12064 kB
   VmRSS:12064 kB
   RssAnon:   5940 kB
   RssFile:   6124 kB
   RssShmem: 0 kB
   VmData:   30792 kB
   VmStk:  132 kB
   VmExe:  592 kB
   VmLib: 5424 kB
   VmPTE:   76 kB
   VmSwap:   0 kB
   HugetlbPages: 0 kB
   CoreDumping:   1
   THP_enabled:   1
   Threads:   4
   SigQ:  0/7609
   SigPnd:
   ShdPnd:
   SigBlk:
   SigIgn:1000
   SigCgt:00018000
   CapInh:
   CapPrm:
   CapEff:
   CapBnd:003f
   CapAmb:
   NoNewPrivs:0
   Seccomp:   0
   Speculation_Store_Bypass:  thread vulnerable
   Cpus_allowed:  3
   Cpus_allowed_list: 0-1
   Mems_allowed:  
,,,,,,,,,,,,,,,,,,,,,,,,,,,,
  ,,,0001
   Mems_allowed_list: 0
   voluntary_ctxt_switches:   111
   nonvoluntary_ctxt_switches:144
  Signal: 6
  Uname: Linux 5.4.0-21-generic x86_64
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1872118] Re: DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

** Changed in: bind9-libs (Ubuntu Focal)
   Status: New => In Progress

** Changed in: bind9-libs (Ubuntu Groovy)
   Status: New => In Progress

** Changed in: isc-dhcp (Ubuntu Focal)
   Status: New => In Progress

** Changed in: isc-dhcp (Ubuntu Groovy)
   Status: Confirmed => In Progress

** Changed in: bind9-libs (Ubuntu Focal)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

** Changed in: bind9-libs (Ubuntu Groovy)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

** Changed in: isc-dhcp (Ubuntu Focal)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

** Changed in: isc-dhcp (Ubuntu Groovy)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  In Progress
Status in isc-dhcp package in Ubuntu:
  In Progress
Status in bind9-libs source package in Focal:
  In Progress
Status in isc-dhcp source package in Focal:
  In Progress
Status in bind9-libs source package in Groovy:
  In Progress
Status in isc-dhcp source package in Groovy:
  In Progress

Bug description:
  
  I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All 
worked perfectly until recently, when they started stopping with code=killed, 
status=6/ABRT.
  This is being fixed by 

  https://bugs.launchpad.net/bugs/1870729

  However now one stops after a few hours with the following errors. One
  can stay on line but not both.


  
  Syslog shows 
  Apr 10 17:20:15 dhcp-primary sh[6828]: 
../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, 
back trace
  Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ??

  
  nothing in kern.log

  
  apport.log shows
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, 
signal 6, core limit 0, dump mode 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid 
with dump mode of 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: 
/usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf")
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no 
DBUS_SESSION_BUS_ADDRESS in environment
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report 
/var/crash/_usr_sbin_dhcpd.0.crash


  /var/crash/_usr_sbin_dhcpd.0.crash shows

  ProblemType: Crash
  Architecture: amd64
  CrashCounter: 1
  Date: Fri Apr 10 17:20:15 2020
  DistroRelease: Ubuntu 20.04
  ExecutablePath: /usr/sbin/dhcpd
  ExecutableTimestamp: 1586210315
  ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf
  ProcEnviron: Error: [Errno 13] Permission denied: 'environ'
  ProcMaps: Error: [Errno 13] Permission denied: 'maps'
  ProcStatus:
   Name:  dhcpd
   Umask: 0022
   State: D (disk sleep)
   Tgid:  6828
   Ngid:  0
   Pid:   6828
   PPid:  1
   TracerPid: 0
   Uid:   113 113 113 113
   Gid:   118 118 118 118
   FDSize:128
   Groups:
   NStgid:6828
   NSpid: 6828
   NSpgid:6828
   NSsid: 6828
   VmPeak:  236244 kB
   VmSize:  170764 kB
   VmLck:0 kB
   VmPin:0 kB
   VmHWM:12064 kB
   VmRSS:12064 kB
   RssAnon:   5940 kB
   RssFile:   6124 kB
   RssShmem: 0 kB
   VmData:   30792 kB
   VmStk:  132 kB
   VmExe:  592 kB
   VmLib: 5424 kB
   VmPTE:   76 kB
   VmSwap:   0 kB
   HugetlbPages: 0 kB
   CoreDumping:   1
   THP_enabled:   1
   Threads:   4
   SigQ:  0/7609
   SigPnd:
   ShdPnd:
   SigBlk:
   SigIgn:1000
   SigCgt:00018000
   CapInh:
   CapPrm:
   CapEff:
   CapBnd:003f
   CapAmb:
   NoNewPrivs:0
   Seccomp:   0
   Speculation_Store_Bypass:  thread vulnerable
   Cpus_allowed:  3
   Cpus_allowed_list: 0-1
   Mems_allowed:  
,,,,,,,,,,,,,,,,,,,,,,,,,,,,
  ,,,0001
   Mems_allowed_list: 0

[Touch-packages] [Bug 1872118] Re: DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

Hello @Andrew, @rlaager,


Any crashes to report before I propose this patch? my env is running this patch 
for close to 3 days without any failures.


Thanks,

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in bind9-libs source package in Focal:
  New
Status in isc-dhcp source package in Focal:
  New
Status in bind9-libs source package in Groovy:
  New
Status in isc-dhcp source package in Groovy:
  Confirmed

Bug description:
  
  I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All 
worked perfectly until recently, when they started stopping with code=killed, 
status=6/ABRT.
  This is being fixed by 

  https://bugs.launchpad.net/bugs/1870729

  However now one stops after a few hours with the following errors. One
  can stay on line but not both.


  
  Syslog shows 
  Apr 10 17:20:15 dhcp-primary sh[6828]: 
../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, 
back trace
  Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ??

  
  nothing in kern.log

  
  apport.log shows
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, 
signal 6, core limit 0, dump mode 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid 
with dump mode of 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: 
/usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf")
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no 
DBUS_SESSION_BUS_ADDRESS in environment
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report 
/var/crash/_usr_sbin_dhcpd.0.crash


  /var/crash/_usr_sbin_dhcpd.0.crash shows

  ProblemType: Crash
  Architecture: amd64
  CrashCounter: 1
  Date: Fri Apr 10 17:20:15 2020
  DistroRelease: Ubuntu 20.04
  ExecutablePath: /usr/sbin/dhcpd
  ExecutableTimestamp: 1586210315
  ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf
  ProcEnviron: Error: [Errno 13] Permission denied: 'environ'
  ProcMaps: Error: [Errno 13] Permission denied: 'maps'
  ProcStatus:
   Name:  dhcpd
   Umask: 0022
   State: D (disk sleep)
   Tgid:  6828
   Ngid:  0
   Pid:   6828
   PPid:  1
   TracerPid: 0
   Uid:   113 113 113 113
   Gid:   118 118 118 118
   FDSize:128
   Groups:
   NStgid:6828
   NSpid: 6828
   NSpgid:6828
   NSsid: 6828
   VmPeak:  236244 kB
   VmSize:  170764 kB
   VmLck:0 kB
   VmPin:0 kB
   VmHWM:12064 kB
   VmRSS:12064 kB
   RssAnon:   5940 kB
   RssFile:   6124 kB
   RssShmem: 0 kB
   VmData:   30792 kB
   VmStk:  132 kB
   VmExe:  592 kB
   VmLib: 5424 kB
   VmPTE:   76 kB
   VmSwap:   0 kB
   HugetlbPages: 0 kB
   CoreDumping:   1
   THP_enabled:   1
   Threads:   4
   SigQ:  0/7609
   SigPnd:
   ShdPnd:
   SigBlk:
   SigIgn:1000
   SigCgt:00018000
   CapInh:
   CapPrm:
   CapEff:
   CapBnd:003f
   CapAmb:
   NoNewPrivs:0
   Seccomp:   0
   Speculation_Store_Bypass:  thread vulnerable
   Cpus_allowed:  3
   Cpus_allowed_list: 0-1
   Mems_allowed:  
,,,,,,,,,,,,,,,,,,,,,,,,,,,,
  ,,,0001
   Mems_allowed_list: 0
   voluntary_ctxt_switches:   111
   nonvoluntary_ctxt_switches:144
  Signal: 6
  Uname: Linux 5.4.0-21-generic x86_64
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1872118] Re: DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

Hello Andrew,

I just reviewed the core file that you provided. Thread 1 is the thread that 
panics
on assertion because sock.pending_send is already set. This is the condition I 
prevented
in the PPA, so *shouldn't* be hitting the frame 3

In my test systems I don't hit this condition, dispatch_send isn't called if 
pending_send
is set.

(gdb) thread 1
[Switching to thread 1 (Thread 0x7f39a41f5700 (LWP 18780))]
#1  0x7f39a4dd1859 in __GI_abort () at abort.c:79
79  in abort.c
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x7f39a4dd1859 in __GI_abort () at abort.c:79
#2  0x7f39a4faf985 in isc_assertion_failed (file=, 
line=, type=, cond=) at 
../../../lib/isc/assertions.c:52
#3  0x7f39a4feb7e1 in dispatch_send (sock=0x7f39a4a03730) at 
../../../../lib/isc/unix/socket.c:3380
#4  process_fd (writeable=, readable=, fd=0, 
manager=0x7f39a49fa010) at ../../../../lib/isc/unix/socket.c:4054
#5  process_fds (writefds=, readfds=0x16, maxfd=-1533038191, 
manager=0x7f39a49fa010) at ../../../../lib/isc/unix/socket.c:4211
#6  watcher (uap=0x7f39a49fa010) at ../../../../lib/isc/unix/socket.c:4397
[...]
(gdb) frame 3
#3  0x7f39a4feb7e1 in dispatch_send (sock=0x7f39a4a03730) at 
../../../../lib/isc/unix/socket.c:3380
3380../../../../lib/isc/unix/socket.c: No such file or directory.
(gdb) info locals
iev = 0x0
ev = 
sender = 0x2
iev = 
ev = 
sender = 

(gdb) p sock
$1 = (isc__socket_t *) 0x7f39a4a03730
(gdb) p sock.pending_send
$2 = 1

Can you check your library links, etc?

ubuntu@dhcpd1:~$ ldd /usr/sbin/dhcpd | grep export
libirs-export.so.161 => /lib/x86_64-linux-gnu/libirs-export.so.161 
(0x7f5cb62e5000)
libdns-export.so.1109 => /lib/x86_64-linux-gnu/libdns-export.so.1109 
(0x7f5cb60b)
libisc-export.so.1105 => /lib/x86_64-linux-gnu/libisc-export.so.1105 
(0x7f5cb6039000)
libisccfg-export.so.163 => 
/lib/x86_64-linux-gnu/libisccfg-export.so.163 (0x7f5cb5df5000)
ubuntu@dhcpd1:~$ dpkg -S /lib/x86_64-linux-gnu/libisc-export.so.1105
libisc-export1105:amd64: /lib/x86_64-linux-gnu/libisc-export.so.1105
ubuntu@dhcpd1:~$ apt-cache policy libisc-export1105  | grep -i ppa
  Installed: 1:9.11.16+dfsg-3~ppa1
  Candidate: 1:9.11.16+dfsg-3~ppa1
 *** 1:9.11.16+dfsg-3~ppa1 500
500 http://ppa.launchpad.net/niedbalski/1872188-dbg/ubuntu focal/main 
amd64 Packages

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in bind9-libs source package in Focal:
  New
Status in isc-dhcp source package in Focal:
  New
Status in bind9-libs source package in Groovy:
  New
Status in isc-dhcp source package in Groovy:
  Confirmed

Bug description:
  
  I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All 
worked perfectly until recently, when they started stopping with code=killed, 
status=6/ABRT.
  This is being fixed by 

  https://bugs.launchpad.net/bugs/1870729

  However now one stops after a few hours with the following errors. One
  can stay on line but not both.


  
  Syslog shows 
  Apr 10 17:20:15 dhcp-primary sh[6828]: 
../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, 
back trace
  Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ??

  
  nothing in kern.log

  
  apport.log shows
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, 
signal 6, core limit 0, dump mode 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid 
with dump mode of 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: 
/usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf")
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no 
DBUS_SESSION_BUS_ADDRESS in environment
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report 
/var/crash/_usr_sbin_dhcpd.0.crash


  /var/crash/_usr_sbin_dhcpd.0.crash shows

  ProblemType: Crash
  Architecture: amd64
  CrashCounter: 1
  Date: Fri Apr 10 17:20:15 2020
  DistroRelease: Ubuntu 20.04
  ExecutablePath: /usr/sbin/dhcpd
  ExecutableTimestamp: 1586210315
  ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf
  ProcEnviron: Error: [Errno 13] Permission denied: 'environ'
  ProcMaps: Error: [Errno 13] Permission denied: 'maps'
  ProcStatus:
   Name:  dhcpd
   Umask: 0022
   State: D 

[Touch-packages] [Bug 1872118] Re: DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

OK, I have no crashes to report for the last 24 hours with the PPA
included here.

● isc-dhcp-server.service - ISC DHCP IPv4 server
 Loaded: loaded (/lib/systemd/system/isc-dhcp-server.service; enabled; 
vendor preset: enabled)
 Active: active (running) since Tue 2020-08-04 14:58:11 UTC; 1 day 1h ago
   Docs: man:dhcpd(8)
   Main PID: 1202 (dhcpd)
  Tasks: 5 (limit: 5882)
 Memory: 6.3M
 CGroup: /system.slice/isc-dhcp-server.service
 └─592 dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf

root@dhcpd1:/home/ubuntu# dpkg -l | grep ppa1
ii isc-dhcp-server 4.4.1-2.1ubuntu6~ppa1 amd64 ISC DHCP server for automatic IP 
address assignment
ii libirs-export161 1:9.11.16+dfsg-3~ppa1 amd64 Exported IRS Shared Library
ii libisc-export1105:amd64 1:9.11.16+dfsg-3~ppa1 amd64 Exported ISC Shared 
Library
ii libisccfg-export163 1:9.11.16+dfsg-3~ppa1 amd64 Exported ISC CFG Shared 
Library


Andrew, what's the current version of libisc-export1105:amd64 installed in your 
system? can you provide a dpkg -l output and a systemctl status for the dhcpd 
service? Did you restarted/killed the dhcpd processes after upgrading that 
library?

Thanks in advance.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in bind9-libs source package in Focal:
  New
Status in isc-dhcp source package in Focal:
  New
Status in bind9-libs source package in Groovy:
  New
Status in isc-dhcp source package in Groovy:
  Confirmed

Bug description:
  
  I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All 
worked perfectly until recently, when they started stopping with code=killed, 
status=6/ABRT.
  This is being fixed by 

  https://bugs.launchpad.net/bugs/1870729

  However now one stops after a few hours with the following errors. One
  can stay on line but not both.


  
  Syslog shows 
  Apr 10 17:20:15 dhcp-primary sh[6828]: 
../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, 
back trace
  Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ??

  
  nothing in kern.log

  
  apport.log shows
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, 
signal 6, core limit 0, dump mode 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid 
with dump mode of 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: 
/usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf")
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no 
DBUS_SESSION_BUS_ADDRESS in environment
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report 
/var/crash/_usr_sbin_dhcpd.0.crash


  /var/crash/_usr_sbin_dhcpd.0.crash shows

  ProblemType: Crash
  Architecture: amd64
  CrashCounter: 1
  Date: Fri Apr 10 17:20:15 2020
  DistroRelease: Ubuntu 20.04
  ExecutablePath: /usr/sbin/dhcpd
  ExecutableTimestamp: 1586210315
  ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf
  ProcEnviron: Error: [Errno 13] Permission denied: 'environ'
  ProcMaps: Error: [Errno 13] Permission denied: 'maps'
  ProcStatus:
   Name:  dhcpd
   Umask: 0022
   State: D (disk sleep)
   Tgid:  6828
   Ngid:  0
   Pid:   6828
   PPid:  1
   TracerPid: 0
   Uid:   113 113 113 113
   Gid:   118 118 118 118
   FDSize:128
   Groups:
   NStgid:6828
   NSpid: 6828
   NSpgid:6828
   NSsid: 6828
   VmPeak:  236244 kB
   VmSize:  170764 kB
   VmLck:0 kB
   VmPin:0 kB
   VmHWM:12064 kB
   VmRSS:12064 kB
   RssAnon:   5940 kB
   RssFile:   6124 kB
   RssShmem: 0 kB
   VmData:   30792 kB
   VmStk:  132 kB
   VmExe:  592 kB
   VmLib: 5424 kB
   VmPTE:   76 kB
   VmSwap:   0 kB
   HugetlbPages: 0 kB
   CoreDumping:   1
   THP_enabled:   1
   Threads:   4
   SigQ:  0/7609
   SigPnd:
   ShdPnd:
   SigBlk:
   SigIgn:1000
   SigCgt:00018000
   CapInh:
   CapPrm:
   CapEff:
   CapBnd:003f
   CapAmb:
   NoNewPrivs:0
   Seccomp:   0
   

[Touch-packages] [Bug 1872118] Re: DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

Andrew,

Thank you for your input.

** Do you have any logs or a crash report to take a look after you
upgraded these systems?

On my test lab , I am counting for 3+ hours without a crash.

root@dhcpd1:/home/ubuntu# dpkg -l | grep ppa1
ii  isc-dhcp-server4.4.1-2.1ubuntu6~ppa1 amd64  
  ISC DHCP server for automatic IP address assignment
ii  libirs-export161   1:9.11.16+dfsg-3~ppa1 amd64  
  Exported IRS Shared Library
ii  libisc-export1105:amd641:9.11.16+dfsg-3~ppa1 amd64  
  Exported ISC Shared Library
ii  libisccfg-export1631:9.11.16+dfsg-3~ppa1 amd64  
  Exported ISC CFG Shared Library

---

DHCPACK on 10.19.101.120 to 52:54:00:d1:eb:66 (sleek-kodiak) via ens4
balancing pool 555643e55f40 12  total 221  free 111  backup 110  lts 0  max-own 
(+/-)22
balanced pool 555643e55f40 12  total 221  free 111  backup 110  lts 0  
max-misbal 33
balancing pool 555643e55f40 12  total 221  free 111  backup 110  lts 0  max-own 
(+/-)22
balanced pool 555643e55f40 12  total 221  free 111  backup 110  lts 0  
max-misbal 33


---

balancing pool 5595dff0df10 12  total 221  free 111  backup 110  lts 0  max-own 
(+/-)22
balanced pool 5595dff0df10 12  total 221  free 111  backup 110  lts 0  
max-misbal 33
balancing pool 5595dff0df10 12  total 221  free 111  backup 110  lts 0  max-own 
(+/-)22
balanced pool 5595dff0df10 12  total 221  free 111  backup 110  lts 0  
max-misbal 33

---

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in bind9-libs source package in Focal:
  New
Status in isc-dhcp source package in Focal:
  New
Status in bind9-libs source package in Groovy:
  New
Status in isc-dhcp source package in Groovy:
  Confirmed

Bug description:
  
  I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All 
worked perfectly until recently, when they started stopping with code=killed, 
status=6/ABRT.
  This is being fixed by 

  https://bugs.launchpad.net/bugs/1870729

  However now one stops after a few hours with the following errors. One
  can stay on line but not both.


  
  Syslog shows 
  Apr 10 17:20:15 dhcp-primary sh[6828]: 
../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, 
back trace
  Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ??

  
  nothing in kern.log

  
  apport.log shows
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, 
signal 6, core limit 0, dump mode 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid 
with dump mode of 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: 
/usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf")
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no 
DBUS_SESSION_BUS_ADDRESS in environment
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report 
/var/crash/_usr_sbin_dhcpd.0.crash


  /var/crash/_usr_sbin_dhcpd.0.crash shows

  ProblemType: Crash
  Architecture: amd64
  CrashCounter: 1
  Date: Fri Apr 10 17:20:15 2020
  DistroRelease: Ubuntu 20.04
  ExecutablePath: /usr/sbin/dhcpd
  ExecutableTimestamp: 1586210315
  ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf
  ProcEnviron: Error: [Errno 13] Permission denied: 'environ'
  ProcMaps: Error: [Errno 13] Permission denied: 'maps'
  ProcStatus:
   Name:  dhcpd
   Umask: 0022
   State: D (disk sleep)
   Tgid:  6828
   Ngid:  0
   Pid:   6828
   PPid:  1
   TracerPid: 0
   Uid:   113 113 113 113
   Gid:   118 118 118 118
   FDSize:128
   Groups:
   NStgid:6828
   NSpid: 6828
   NSpgid:6828
   NSsid: 6828
   VmPeak:  236244 kB
   VmSize:  170764 kB
   VmLck:0 kB
   VmPin:0 kB
   VmHWM:12064 kB
   VmRSS:12064 kB
   RssAnon:   5940 kB
   RssFile:   6124 kB
   RssShmem: 0 kB
   VmData:   30792 kB
   VmStk:  132 kB
   VmExe:  592 kB
   VmLib: 5424 kB
   VmPTE:   76 kB
   VmSwap:   0 kB
   HugetlbPages: 0 kB
   CoreDumping:   1
   THP_enabled:   1
   Threads:   4
   SigQ:  0/7609
   SigPnd:
   ShdPnd:
   SigBlk:
   SigIgn:

[Touch-packages] [Bug 1872118] Re: DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

Hello Andrew,

Correct me if I am wrong but it seems your system isn't running with
libisc-export1105:amd64 1:9.11.16+dfsg-3~ppa1 (?)

I am running the following packages from the PPA, please note that 
libisc-export1105 is required (that's
where the fix is located).

root@dhcpd1:/home/ubuntu# dpkg -l | grep ppa1
ii isc-dhcp-server 4.4.1-2.1ubuntu6~ppa1 amd64 ISC DHCP server for automatic IP 
address assignment
ii libirs-export161 1:9.11.16+dfsg-3~ppa1 amd64 Exported IRS Shared Library
ii libisc-export1105:amd64 1:9.11.16+dfsg-3~ppa1 amd64 Exported ISC Shared 
Library
ii libisccfg-export163 1:9.11.16+dfsg-3~ppa1 amd64 Exported ISC CFG Shared 
Library

---

Sent update done message to failover-partner
failover peer failover-partner: peer moves from recover to recover-done
failover peer failover-partner: peer update completed.
failover peer failover-partner: I move from recover to recover-done
failover peer failover-partner: peer moves from recover-done to normal
failover peer failover-partner: I move from recover-done to normal
failover peer failover-partner: Both servers normal
balancing pool 55d0a88a4f10 12 total 221 free 221 backup 0 lts -110 max-own 
(+/-)22
balanced pool 55d0a88a4f10 12 total 221 free 221 backup 0 lts -110 max-misbal 33


---

balanced pool 55eb2fe58f40 12 total 221 free 111 backup 110 lts 0 max-misbal 33
Sending updates to failover-partner.
failover peer failover-partner: peer moves from recover-done to normal
failover peer failover-partner: Both servers normal


---
DHCPDISCOVER from 52:54:00:d1:eb:66 via ens4: load balance to peer 
failover-partner
DHCPREQUEST for 10.19.101.120 (10.19.101.233) from 52:54:00:d1:eb:66 via ens4: 
lease owned by peer

On failover:

peer failover-partner: disconnected
failover peer failover-partner: I move from normal to communications-interrupted
DHCPDISCOVER from 52:54:00:e8:14:0a via ens4
DHCPOFFER on 10.19.101.10 to 52:54:00:e8:14:0a (shapely-peccary) via ens4
DHCPREQUEST for 10.19.101.10 (10.19.101.127) from 52:54:00:e8:14:0a 
(shapely-peccary) via ens4
DHCPACK on 10.19.101.10 to 52:54:00:e8:14:0a (shapely-peccary) via ens4


I'll leave this running until I can reproduce the crash or assume that the fix
works.

Please let me know if you can reproduce with those packages.

Thanks,

Jorge Niedbalski

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in bind9-libs source package in Focal:
  New
Status in isc-dhcp source package in Focal:
  New
Status in bind9-libs source package in Groovy:
  New
Status in isc-dhcp source package in Groovy:
  Confirmed

Bug description:
  
  I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All 
worked perfectly until recently, when they started stopping with code=killed, 
status=6/ABRT.
  This is being fixed by 

  https://bugs.launchpad.net/bugs/1870729

  However now one stops after a few hours with the following errors. One
  can stay on line but not both.


  
  Syslog shows 
  Apr 10 17:20:15 dhcp-primary sh[6828]: 
../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, 
back trace
  Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ??

  
  nothing in kern.log

  
  apport.log shows
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, 
signal 6, core limit 0, dump mode 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid 
with dump mode of 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: 
/usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf")
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no 
DBUS_SESSION_BUS_ADDRESS in environment
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report 
/var/crash/_usr_sbin_dhcpd.0.crash


  /var/crash/_usr_sbin_dhcpd.0.crash shows

  ProblemType: Crash
  Architecture: amd64
  CrashCounter: 1
  Date: Fri Apr 10 17:20:15 2020
  DistroRelease: Ubuntu 20.04
  ExecutablePath: /usr/sbin/dhcpd
  ExecutableTimestamp: 1586210315
  ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf
  ProcEnviron: Error: [Errno 13] Permission denied: 'environ'
  ProcMaps: Error: [Errno 13] Permission denied: 'maps'
  ProcStatus:
   Name:  dhcpd
   Umask: 0022
   State: D (disk sleep)
   Tgid:  6828
   Ngid:  0
   Pid:   6828
   PPid:  1
   TracerPid: 0

[Touch-packages] [Bug 1872118] Re: DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

Hello Andrew,

The fix is on the libisc-export1105 library (check dependencies on: 
https://launchpad.net/~niedbalski/+archive/ubuntu/fix-1872118/+packages), just 
replacing
the dhcpd binary won't be enough.

If you can install isc-dhcp-server and its dependencies from the PPA and
test, would be great.

Thanks for any feedback.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in bind9-libs source package in Focal:
  New
Status in isc-dhcp source package in Focal:
  New
Status in bind9-libs source package in Groovy:
  New
Status in isc-dhcp source package in Groovy:
  Confirmed

Bug description:
  
  I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All 
worked perfectly until recently, when they started stopping with code=killed, 
status=6/ABRT.
  This is being fixed by 

  https://bugs.launchpad.net/bugs/1870729

  However now one stops after a few hours with the following errors. One
  can stay on line but not both.


  
  Syslog shows 
  Apr 10 17:20:15 dhcp-primary sh[6828]: 
../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, 
back trace
  Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ??

  
  nothing in kern.log

  
  apport.log shows
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, 
signal 6, core limit 0, dump mode 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid 
with dump mode of 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: 
/usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf")
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no 
DBUS_SESSION_BUS_ADDRESS in environment
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report 
/var/crash/_usr_sbin_dhcpd.0.crash


  /var/crash/_usr_sbin_dhcpd.0.crash shows

  ProblemType: Crash
  Architecture: amd64
  CrashCounter: 1
  Date: Fri Apr 10 17:20:15 2020
  DistroRelease: Ubuntu 20.04
  ExecutablePath: /usr/sbin/dhcpd
  ExecutableTimestamp: 1586210315
  ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf
  ProcEnviron: Error: [Errno 13] Permission denied: 'environ'
  ProcMaps: Error: [Errno 13] Permission denied: 'maps'
  ProcStatus:
   Name:  dhcpd
   Umask: 0022
   State: D (disk sleep)
   Tgid:  6828
   Ngid:  0
   Pid:   6828
   PPid:  1
   TracerPid: 0
   Uid:   113 113 113 113
   Gid:   118 118 118 118
   FDSize:128
   Groups:
   NStgid:6828
   NSpid: 6828
   NSpgid:6828
   NSsid: 6828
   VmPeak:  236244 kB
   VmSize:  170764 kB
   VmLck:0 kB
   VmPin:0 kB
   VmHWM:12064 kB
   VmRSS:12064 kB
   RssAnon:   5940 kB
   RssFile:   6124 kB
   RssShmem: 0 kB
   VmData:   30792 kB
   VmStk:  132 kB
   VmExe:  592 kB
   VmLib: 5424 kB
   VmPTE:   76 kB
   VmSwap:   0 kB
   HugetlbPages: 0 kB
   CoreDumping:   1
   THP_enabled:   1
   Threads:   4
   SigQ:  0/7609
   SigPnd:
   ShdPnd:
   SigBlk:
   SigIgn:1000
   SigCgt:00018000
   CapInh:
   CapPrm:
   CapEff:
   CapBnd:003f
   CapAmb:
   NoNewPrivs:0
   Seccomp:   0
   Speculation_Store_Bypass:  thread vulnerable
   Cpus_allowed:  3
   Cpus_allowed_list: 0-1
   Mems_allowed:  
,,,,,,,,,,,,,,,,,,,,,,,,,,,,
  ,,,0001
   Mems_allowed_list: 0
   voluntary_ctxt_switches:   111
   nonvoluntary_ctxt_switches:144
  Signal: 6
  Uname: Linux 5.4.0-21-generic x86_64
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1872118] Re: DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

** Follow up from my previous comment, I've built a PPA with a fix similar to 
the one
pointed in 430065.

https://launchpad.net/~niedbalski/+archive/ubuntu/fix-1872118

* I'd appreciate if anyone can test that PPA with focal and report back if the
problem keeps reproducible with that version.

In case it does, please upload the crash file / coredump and the configuration
file used.

Thank you.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in bind9-libs source package in Focal:
  New
Status in isc-dhcp source package in Focal:
  New
Status in bind9-libs source package in Groovy:
  New
Status in isc-dhcp source package in Groovy:
  Confirmed

Bug description:
  
  I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All 
worked perfectly until recently, when they started stopping with code=killed, 
status=6/ABRT.
  This is being fixed by 

  https://bugs.launchpad.net/bugs/1870729

  However now one stops after a few hours with the following errors. One
  can stay on line but not both.


  
  Syslog shows 
  Apr 10 17:20:15 dhcp-primary sh[6828]: 
../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, 
back trace
  Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ??

  
  nothing in kern.log

  
  apport.log shows
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, 
signal 6, core limit 0, dump mode 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid 
with dump mode of 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: 
/usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf")
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no 
DBUS_SESSION_BUS_ADDRESS in environment
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report 
/var/crash/_usr_sbin_dhcpd.0.crash


  /var/crash/_usr_sbin_dhcpd.0.crash shows

  ProblemType: Crash
  Architecture: amd64
  CrashCounter: 1
  Date: Fri Apr 10 17:20:15 2020
  DistroRelease: Ubuntu 20.04
  ExecutablePath: /usr/sbin/dhcpd
  ExecutableTimestamp: 1586210315
  ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf
  ProcEnviron: Error: [Errno 13] Permission denied: 'environ'
  ProcMaps: Error: [Errno 13] Permission denied: 'maps'
  ProcStatus:
   Name:  dhcpd
   Umask: 0022
   State: D (disk sleep)
   Tgid:  6828
   Ngid:  0
   Pid:   6828
   PPid:  1
   TracerPid: 0
   Uid:   113 113 113 113
   Gid:   118 118 118 118
   FDSize:128
   Groups:
   NStgid:6828
   NSpid: 6828
   NSpgid:6828
   NSsid: 6828
   VmPeak:  236244 kB
   VmSize:  170764 kB
   VmLck:0 kB
   VmPin:0 kB
   VmHWM:12064 kB
   VmRSS:12064 kB
   RssAnon:   5940 kB
   RssFile:   6124 kB
   RssShmem: 0 kB
   VmData:   30792 kB
   VmStk:  132 kB
   VmExe:  592 kB
   VmLib: 5424 kB
   VmPTE:   76 kB
   VmSwap:   0 kB
   HugetlbPages: 0 kB
   CoreDumping:   1
   THP_enabled:   1
   Threads:   4
   SigQ:  0/7609
   SigPnd:
   ShdPnd:
   SigBlk:
   SigIgn:1000
   SigCgt:00018000
   CapInh:
   CapPrm:
   CapEff:
   CapBnd:003f
   CapAmb:
   NoNewPrivs:0
   Seccomp:   0
   Speculation_Store_Bypass:  thread vulnerable
   Cpus_allowed:  3
   Cpus_allowed_list: 0-1
   Mems_allowed:  
,,,,,,,,,,,,,,,,,,,,,,,,,,,,
  ,,,0001
   Mems_allowed_list: 0
   voluntary_ctxt_switches:   111
   nonvoluntary_ctxt_switches:144
  Signal: 6
  Uname: Linux 5.4.0-21-generic x86_64
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/dhcp/+bug/1872118/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages

[Touch-packages] [Bug 1872118] Re: DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

Hello,

I checked the backtrace of a crashed dhcpd running on 4.4.1-2.1ubuntu5.

(gdb) info threads
  Id Target Id Frame
* 1 Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
  2 Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait 
(futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52
  3 Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, 
processes_to_wake=1, futex_word=) at 
../sysdeps/nptl/futex-internal.h:364
  4 Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable (private=, expected=0, futex_word=0x7fb4de6cd0d0) at 
../sysdeps/nptl/futex-internal.h:183

(gdb) frame 2
#2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
(gdb) bt
#1 0x7fb4deaa7859 in __GI_abort () at abort.c:79
#2 0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist,
cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
#3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
#4 process_fd (writeable=, readable=, fd=11, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054
#5 process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211
#6 watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397
#7 0x7fb4dea68609 in start_thread (arg=) at 
pthread_create.c:477
#8 0x7fb4deba4103 in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

(gdb) frame 3
#3 0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
4041 in ../../../../lib/isc/unix/socket.c
(gdb) p sock->pending_send
$2 = 1

The code is crashing on this assertion: 
https://gitlab.isc.org/isc-projects/bind9/-/blob/v9_11_3/lib/isc/unix/socket.c#L3364
This was already reported and marked as fixed in debian (?) via [0]

""Now if a wakeup event occurres the socket would be dispatched for
processing regardless which kind of event (timer?) triggered the wakeup.
At least I did not find any sanity checks in process_fds() except
SOCK_DEAD(sock).

This leads to the following situation: The sock is not dead yet but it
is still pending when it is dispatched again.

I would now check sock->pending_send before calling dispatch_send().This
 would at least prevent the assertion failure - well knowing that the
situation described above ( not dead but still pending and alerting ) is
not a very pleasant one - until someone comes up with a better solution.
"""

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430065#20

** Follow up questions:

0) The reproducer doesn't seems consistent and seems to be related to a race
condition associated with a internal timer/futex.
1) Can anyone confirm that a pristine upstream 4.4.1 doesn't reproduces the 
issue?

** Bug watch added: Debian Bug tracker #430065
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430065

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in bind9-libs source package in Focal:
  New
Status in isc-dhcp source package in Focal:
  New
Status in bind9-libs source package in Groovy:
  New
Status in isc-dhcp source package in Groovy:
  Confirmed

Bug description:
  
  I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All 
worked perfectly until recently, when they started stopping with code=killed, 
status=6/ABRT.
  This is being fixed by 

  https://bugs.launchpad.net/bugs/1870729

  However now one stops after a few hours with the following errors. One
  can stay on line but not both.


  
  Syslog shows 
  Apr 10 17:20:15 dhcp-primary sh[6828]: 
../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, 
back trace
  Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ??

  
  nothing in kern.log

  
  apport.log shows
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, 
signal 6, core limit 0, dump mode 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid 
with dump mode of 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: 

[Touch-packages] [Bug 1888926] Re: tls.tlscfgcmd not recognized; rebuild rsyslog against librelp 1.5.0

[Jorge Niedbalski]

Hello,

I checked the backtrace of a crashed dhcpd running on 4.4.1-2.1ubuntu5.

(gdb)  info threads
  Id   Target IdFrame 
* 1Thread 0x7fb4ddecb700 (LWP 3170) __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:50
  2Thread 0x7fb4dd6ca700 (LWP 3171) __lll_lock_wait 
(futex=futex@entry=0x7fb4de6d2028, private=0) at lowlevellock.c:52
  3Thread 0x7fb4de6cc700 (LWP 3169) futex_wake (private=, 
processes_to_wake=1, futex_word=) at 
../sysdeps/nptl/futex-internal.h:364
  4Thread 0x7fb4de74f740 (LWP 3148) futex_wait_cancelable 
(private=, expected=0, futex_word=0x7fb4de6cd0d0) at 
../sysdeps/nptl/futex-internal.h:183


(gdb) frame 2
#2  0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist, 
cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
(gdb) bt
#1  0x7fb4deaa7859 in __GI_abort () at abort.c:79
#2  0x7fb4dec85985 in isc_assertion_failed (file=file@entry=0x7fb4decd8878 
"../../../../lib/isc/unix/socket.c", line=line@entry=3361, 
type=type@entry=isc_assertiontype_insist, 
cond=cond@entry=0x7fb4decda033 "!sock->pending_send") at 
../../../lib/isc/assertions.c:52
#3  0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
#4  process_fd (writeable=, readable=, fd=11, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4054
#5  process_fds (writefds=, readfds=0x7fb4de6d1090, maxfd=13, 
manager=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4211
#6  watcher (uap=0x7fb4de6d0010) at ../../../../lib/isc/unix/socket.c:4397
#7  0x7fb4dea68609 in start_thread (arg=) at 
pthread_create.c:477
#8  0x7fb4deba4103 in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


(gdb) frame 3
#3  0x7fb4decc17e1 in dispatch_send (sock=0x7fb4de6d4990) at 
../../../../lib/isc/unix/socket.c:4041
4041in ../../../../lib/isc/unix/socket.c
(gdb) p sock->pending_send
$2 = 1

The code is crashing on this assertion: 
https://gitlab.isc.org/isc-projects/bind9/-/blob/v9_11_3/lib/isc/unix/socket.c#L3364
This was already reported and marked as fixed in debian (?) via [0]

""Now if a wakeup event occurres the socket would be dispatched for
processing regardless which kind of event (timer?) triggered the wakeup.
At least I did not find any sanity checks in process_fds() except
SOCK_DEAD(sock).

This leads to the following situation: The sock is not dead yet but it
is still pending when it is dispatched again.

I would now check sock->pending_send before calling dispatch_send().This
 would at least prevent the assertion failure - well knowing that the
situation described above ( not dead but still pending and alerting ) is
not a very pleasant one - until someone comes up with a better solution.
"""

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430065#20


** Follow up questions:

0) The reproducer doesn't seems consistent and seems to be related to a race 
condition associated with a internal timer/futex. 
1) Can anyone confirm that a pristine upstream 4.4.1 doesn't reproduces the 
issue?


** Bug watch added: Debian Bug tracker #430065
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=430065

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1888926

Title:
  tls.tlscfgcmd not recognized; rebuild rsyslog against librelp 1.5.0

Status in rsyslog package in Ubuntu:
  Fix Released
Status in rsyslog source package in Focal:
  In Progress
Status in rsyslog source package in Groovy:
  Fix Released

Bug description:
  [Description]

  Problem is according to 
https://launchpad.net/ubuntu/+source/librelp/+publishinghistory,
  librelp-dev 1.5.0 was published into focal at 2020-04-21, but reverse 
dependencies
  (such as rsyslog) weren't rebuilt after this new version was published

  # dpkg -l | grep librelp
  ii librelp-dev:amd64 1.5.0-1ubuntu2 amd64 Reliable Event Logging Protocol 
(RELP) library - development files
  ii librelp0:amd64 1.5.0-1ubuntu2 amd64 Reliable Event Logging Protocol (RELP) 
library

  rsyslogd: error during parsing file /etc/rsyslog.d/FILENAME.conf, on
  or before line 22: imrelp: librelp does not support input parameter
  'tls.tlscfgcmd'; it probably is too old (1.5.0 or higher should be
  fine); ignoring setting now. [v8.2001.0 try
  https://www.rsyslog.com/e/2207 ]

  [Reproducer]

  Setup a focal machine with rsyslog, using the following configuration:

  
  module(load="imrelp" tls.tlslib="openssl")

  input(
  type="imrelp" port="2515"
  tls="on"
  # This should work in rsyslog 8.2006.0:
  #tls.mycert="/etc/rsyslog.tls/fullchain.pem"
  # for now we use the work-around discussed in:
  # https://github.com/rsyslog/rsyslog/issues/4360
  

[Touch-packages] [Bug 1872118] Re: DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

** Also affects: isc-dhcp (Ubuntu Groovy)
   Importance: Undecided
   Status: Confirmed

** Also affects: isc-dhcp (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: bind9-libs (Ubuntu)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in bind9-libs package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  Confirmed
Status in bind9-libs source package in Focal:
  New
Status in isc-dhcp source package in Focal:
  New
Status in bind9-libs source package in Groovy:
  New
Status in isc-dhcp source package in Groovy:
  Confirmed

Bug description:
  
  I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All 
worked perfectly until recently, when they started stopping with code=killed, 
status=6/ABRT.
  This is being fixed by 

  https://bugs.launchpad.net/bugs/1870729

  However now one stops after a few hours with the following errors. One
  can stay on line but not both.


  
  Syslog shows 
  Apr 10 17:20:15 dhcp-primary sh[6828]: 
../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, 
back trace
  Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ??

  
  nothing in kern.log

  
  apport.log shows
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, 
signal 6, core limit 0, dump mode 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid 
with dump mode of 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: 
/usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf")
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no 
DBUS_SESSION_BUS_ADDRESS in environment
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report 
/var/crash/_usr_sbin_dhcpd.0.crash


  /var/crash/_usr_sbin_dhcpd.0.crash shows

  ProblemType: Crash
  Architecture: amd64
  CrashCounter: 1
  Date: Fri Apr 10 17:20:15 2020
  DistroRelease: Ubuntu 20.04
  ExecutablePath: /usr/sbin/dhcpd
  ExecutableTimestamp: 1586210315
  ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf
  ProcEnviron: Error: [Errno 13] Permission denied: 'environ'
  ProcMaps: Error: [Errno 13] Permission denied: 'maps'
  ProcStatus:
   Name:  dhcpd
   Umask: 0022
   State: D (disk sleep)
   Tgid:  6828
   Ngid:  0
   Pid:   6828
   PPid:  1
   TracerPid: 0
   Uid:   113 113 113 113
   Gid:   118 118 118 118
   FDSize:128
   Groups:
   NStgid:6828
   NSpid: 6828
   NSpgid:6828
   NSsid: 6828
   VmPeak:  236244 kB
   VmSize:  170764 kB
   VmLck:0 kB
   VmPin:0 kB
   VmHWM:12064 kB
   VmRSS:12064 kB
   RssAnon:   5940 kB
   RssFile:   6124 kB
   RssShmem: 0 kB
   VmData:   30792 kB
   VmStk:  132 kB
   VmExe:  592 kB
   VmLib: 5424 kB
   VmPTE:   76 kB
   VmSwap:   0 kB
   HugetlbPages: 0 kB
   CoreDumping:   1
   THP_enabled:   1
   Threads:   4
   SigQ:  0/7609
   SigPnd:
   ShdPnd:
   SigBlk:
   SigIgn:1000
   SigCgt:00018000
   CapInh:
   CapPrm:
   CapEff:
   CapBnd:003f
   CapAmb:
   NoNewPrivs:0
   Seccomp:   0
   Speculation_Store_Bypass:  thread vulnerable
   Cpus_allowed:  3
   Cpus_allowed_list: 0-1
   Mems_allowed:  
,,,,,,,,,,,,,,,,,,,,,,,,,,,,
  ,,,0001
   Mems_allowed_list: 0
   voluntary_ctxt_switches:   111
   nonvoluntary_ctxt_switches:144
  Signal: 6
  Uname: Linux 5.4.0-21-generic x86_64
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/dhcp/+bug/1872118/+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 1872118] Re: DHCP Cluster crashes after a few hours

[Jorge Niedbalski]

Hello,

I am trying to setup a reproducer for the mentioned issue. I have 2
machines acting as peers with the following versions:


# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04.1 LTS
Release:20.04
Codename:   focal

# dpkg -l |grep -i isc-dh
ii  isc-dhcp-client4.4.1-2.1ubuntu5  amd64  
  DHCP client for automatically obtaining an IP address
ii  isc-dhcp-common4.4.1-2.1ubuntu5  amd64  
  common manpages relevant to all of the isc-dhcp packages
ii  isc-dhcp-server4.4.1-2.1ubuntu5  amd64  
  ISC DHCP server for automatic IP address assignment

=

Primary configuration:  https://pastebin.ubuntu.com/p/XYj648MghK/
Secondary configuration: https://pastebin.ubuntu.com/p/PYkcshZCWK/

Started with:

# dhcpd -f -d -4 -cf /etc/dhcp/dhcpd.conf --no-pid ens4

---> Raised some DHCP requests to these servers.

balanced pool 560b8c263f40 12  total 221  free 111  backup 110  lts 0  
max-misbal 33
Sending updates to failover-partner.
failover peer failover-partner: peer moves from recover-done to normal
failover peer failover-partner: Both servers normal
DHCPDISCOVER from 52:54:00:2d:53:93 via ens4
DHCPOFFER on 10.19.101.120 to 52:54:00:2d:53:93 (glistening-elephant) via ens4
DHCPREQUEST for 10.19.101.120 (10.19.101.236) from 52:54:00:2d:53:93 
(glistening-elephant) via ens4
DHCPACK on 10.19.101.120 to 52:54:00:2d:53:93 (glistening-elephant) via ens4

DHCPREQUEST for 10.19.101.120 from 52:54:00:2d:53:93 (glistening-elephant) via 
ens4
DHCPACK on 10.19.101.120 to 52:54:00:2d:53:93 (glistening-elephant) via ens4
DHCPREQUEST for 10.19.101.121 from 52:54:00:53:a3:d8 (valiant-motmot) via ens4
DHCPACK on 10.19.101.121 to 52:54:00:53:a3:d8 (valiant-motmot) via ens4


---


failover peer failover-partner: Both servers normal
balancing pool 5606b2c95f10 12  total 221  free 221  backup 0  lts -110  
max-own (+/-)22
balanced pool 5606b2c95f10 12  total 221  free 221  backup 0  lts -110  
max-misbal 33
balancing pool 5606b2c95f10 12  total 221  free 111  backup 110  lts 0  max-own 
(+/-)22
balanced pool 5606b2c95f10 12  total 221  free 111  backup 110  lts 0  
max-misbal 33
DHCPDISCOVER from 52:54:00:2d:53:93 via ens4: load balance to peer 
failover-partner
DHCPREQUEST for 10.19.101.120 (10.19.101.236) from 52:54:00:2d:53:93 via ens4: 
lease owned by peer


So far (after 1.5h) no crash has been reported in any of the servers. 

Questions:

1) Anything missed from the provided configuration?
2) Is this load or concurrency related? meaning a specific amount of leases 
needs to be allocated for this crash to happen? 

I will take a look to an existing crash/coredump.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1872118

Title:
  DHCP Cluster crashes after a few hours

Status in DHCP:
  New
Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  
  I have a pair of DHCP serevrs running in a cluster on ubuntu 20.04, All 
worked perfectly until recently, when they started stopping with code=killed, 
status=6/ABRT.
  This is being fixed by 

  https://bugs.launchpad.net/bugs/1870729

  However now one stops after a few hours with the following errors. One
  can stay on line but not both.


  
  Syslog shows 
  Apr 10 17:20:15 dhcp-primary sh[6828]: 
../../../../lib/isc/unix/socket.c:3361: INSIST(!sock->pending_send) failed, 
back trace
  Apr 10 17:20:15 dhcp-primary sh[6828]: #0 0x7fbe78702a4a in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #1 0x7fbe78702980 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #2 0x7fbe7873e7e1 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #3 0x7fbe784e5609 in ??
  Apr 10 17:20:15 dhcp-primary sh[6828]: #4 0x7fbe78621103 in ??

  
  nothing in kern.log

  
  apport.log shows
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: called for pid 6828, 
signal 6, core limit 0, dump mode 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: not creating core for pid 
with dump mode of 2
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: executable: 
/usr/sbin/dhcpd (command line "dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf")
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: is_closing_session(): no 
DBUS_SESSION_BUS_ADDRESS in environment
  ERROR: apport (pid 6850) Fri Apr 10 17:20:15 2020: wrote report 
/var/crash/_usr_sbin_dhcpd.0.crash


  /var/crash/_usr_sbin_dhcpd.0.crash shows

  ProblemType: Crash
  Architecture: amd64
  CrashCounter: 1
  Date: Fri Apr 10 17:20:15 2020
  DistroRelease: Ubuntu 20.04
  ExecutablePath: /usr/sbin/dhcpd
  ExecutableTimestamp: 1586210315
  ProcCmdline: dhcpd -user dhcpd -group dhcpd -f -4 -pf 
/run/dhcp-server/dhcpd.pid -cf /etc/dhcp/dhcpd.conf
  ProcEnviron: Error: [Errno 13] Permission denied: 'environ'
 

[Touch-packages] [Bug 1888926] Re: tls.tlscfgcmd not recognized; rebuild rsyslog against librelp 1.5.0

[Jorge Niedbalski]

** Patch added: "lp1888926-focal.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1888926/+attachment/5398376/+files/lp1888926-focal.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1888926

Title:
  tls.tlscfgcmd not recognized; rebuild rsyslog against librelp 1.5.0

Status in rsyslog package in Ubuntu:
  Fix Released
Status in rsyslog source package in Focal:
  In Progress
Status in rsyslog source package in Groovy:
  Fix Released

Bug description:
  [Description]

  Problem is according to 
https://launchpad.net/ubuntu/+source/librelp/+publishinghistory,
  librelp-dev 1.5.0 was published into focal at 2020-04-21, but reverse 
dependencies
  (such as rsyslog) weren't rebuilt after this new version was published

  # dpkg -l | grep librelp
  ii librelp-dev:amd64 1.5.0-1ubuntu2 amd64 Reliable Event Logging Protocol 
(RELP) library - development files
  ii librelp0:amd64 1.5.0-1ubuntu2 amd64 Reliable Event Logging Protocol (RELP) 
library

  rsyslogd: error during parsing file /etc/rsyslog.d/FILENAME.conf, on
  or before line 22: imrelp: librelp does not support input parameter
  'tls.tlscfgcmd'; it probably is too old (1.5.0 or higher should be
  fine); ignoring setting now. [v8.2001.0 try
  https://www.rsyslog.com/e/2207 ]

  [Reproducer]

  Setup a focal machine with rsyslog, using the following configuration:

  
  module(load="imrelp" tls.tlslib="openssl")

  input(
  type="imrelp" port="2515"
  tls="on"
  # This should work in rsyslog 8.2006.0:
  #tls.mycert="/etc/rsyslog.tls/fullchain.pem"
  # for now we use the work-around discussed in:
  # https://github.com/rsyslog/rsyslog/issues/4360
  tls.cacert="/etc/rsyslog.tls/chain.pem"
  tls.mycert="/etc/rsyslog.tls/cert.pem"
  tls.myprivkey="/etc/rsyslog.tls/privkey.pem"
  tls.tlscfgcmd="ServerPreference 
CipherString=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
 
Ciphersuites=TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384
 MinProtocol=TLSv1.2"
  )
  

  This error comes from this code in plugins/imrelp/imrelp.c:

  
  #if defined(HAVE_RELPENGINESETTLSCFGCMD)
  inst->tlscfgcmd = 
(uchar*)es_str2cstr(pvals[i].val.d.estr, NULL);
  #else
  parser_errmsg("imrelp: librelp does not support input 
parameter 'tls.tlscfgcmd'; "
  "it probably is too old (1.5.0 or higher 
should be fine); ignoring setting now.");
  #endif
  

  The build log for focal:
  
https://launchpadlibrarian.net/464665610/buildlog_ubuntu-focal-arm64.rsyslog_8.2001.0-1ubuntu1_BUILDING.txt.gz
  says:
  checking for relpSrvSetTlsConfigCmd... no
  checking for relpSrvSetTlsConfigCmd... (cached) no

  The build log for groovy:
  
https://launchpadlibrarian.net/486409321/buildlog_ubuntu-groovy-arm64.rsyslog_8.2006.0-2ubuntu1_BUILDING.txt.gz
  says:
  checking for relpSrvSetTlsConfigCmd... yes
  checking for relpSrvSetTlsConfigCmd... (cached) yes

  If I rebuild the rsyslog package, I get:
  checking for relpSrvSetTlsConfigCmd... yes
  checking for relpSrvSetTlsConfigCmd... (cached) yes

  I suspect that the rsyslog package was built against and older librelp
  version. A simple rebuild of rsyslog should fix this, though a more
  complete fix would be to raise the Build-Depends from librelp-dev (>=
  1.4.0) to librelp-dev (>= 1.5.0).

  [Risk potential]

  * No identified as this is a rebuild that should have been done on all 
  reverse dependencies of librelp-dev when upgraded from 1.4.0 to 1.5.0

  
  [Fix]

  Provide a rebuild SRU for focal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1888926/+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 1888926] Re: tls.tlscfgcmd not recognized; rebuild rsyslog against librelp 1.5.0

[Jorge Niedbalski]

** Tags added: sts-sru-needed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1888926

Title:
  tls.tlscfgcmd not recognized; rebuild rsyslog against librelp 1.5.0

Status in rsyslog package in Ubuntu:
  Fix Released
Status in rsyslog source package in Focal:
  In Progress
Status in rsyslog source package in Groovy:
  Fix Released

Bug description:
  [Description]

  Problem is according to 
https://launchpad.net/ubuntu/+source/librelp/+publishinghistory,
  librelp-dev 1.5.0 was published into focal at 2020-04-21, but reverse 
dependencies
  (such as rsyslog) weren't rebuilt after this new version was published

  # dpkg -l | grep librelp
  ii librelp-dev:amd64 1.5.0-1ubuntu2 amd64 Reliable Event Logging Protocol 
(RELP) library - development files
  ii librelp0:amd64 1.5.0-1ubuntu2 amd64 Reliable Event Logging Protocol (RELP) 
library

  rsyslogd: error during parsing file /etc/rsyslog.d/FILENAME.conf, on
  or before line 22: imrelp: librelp does not support input parameter
  'tls.tlscfgcmd'; it probably is too old (1.5.0 or higher should be
  fine); ignoring setting now. [v8.2001.0 try
  https://www.rsyslog.com/e/2207 ]

  [Reproducer]

  Setup a focal machine with rsyslog, using the following configuration:

  
  module(load="imrelp" tls.tlslib="openssl")

  input(
  type="imrelp" port="2515"
  tls="on"
  # This should work in rsyslog 8.2006.0:
  #tls.mycert="/etc/rsyslog.tls/fullchain.pem"
  # for now we use the work-around discussed in:
  # https://github.com/rsyslog/rsyslog/issues/4360
  tls.cacert="/etc/rsyslog.tls/chain.pem"
  tls.mycert="/etc/rsyslog.tls/cert.pem"
  tls.myprivkey="/etc/rsyslog.tls/privkey.pem"
  tls.tlscfgcmd="ServerPreference 
CipherString=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
 
Ciphersuites=TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384
 MinProtocol=TLSv1.2"
  )
  

  This error comes from this code in plugins/imrelp/imrelp.c:

  
  #if defined(HAVE_RELPENGINESETTLSCFGCMD)
  inst->tlscfgcmd = 
(uchar*)es_str2cstr(pvals[i].val.d.estr, NULL);
  #else
  parser_errmsg("imrelp: librelp does not support input 
parameter 'tls.tlscfgcmd'; "
  "it probably is too old (1.5.0 or higher 
should be fine); ignoring setting now.");
  #endif
  

  The build log for focal:
  
https://launchpadlibrarian.net/464665610/buildlog_ubuntu-focal-arm64.rsyslog_8.2001.0-1ubuntu1_BUILDING.txt.gz
  says:
  checking for relpSrvSetTlsConfigCmd... no
  checking for relpSrvSetTlsConfigCmd... (cached) no

  The build log for groovy:
  
https://launchpadlibrarian.net/486409321/buildlog_ubuntu-groovy-arm64.rsyslog_8.2006.0-2ubuntu1_BUILDING.txt.gz
  says:
  checking for relpSrvSetTlsConfigCmd... yes
  checking for relpSrvSetTlsConfigCmd... (cached) yes

  If I rebuild the rsyslog package, I get:
  checking for relpSrvSetTlsConfigCmd... yes
  checking for relpSrvSetTlsConfigCmd... (cached) yes

  I suspect that the rsyslog package was built against and older librelp
  version. A simple rebuild of rsyslog should fix this, though a more
  complete fix would be to raise the Build-Depends from librelp-dev (>=
  1.4.0) to librelp-dev (>= 1.5.0).

  [Risk potential]

  * No identified as this is a rebuild that should have been done on all 
  reverse dependencies of librelp-dev when upgraded from 1.4.0 to 1.5.0

  
  [Fix]

  Provide a rebuild SRU for focal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1888926/+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 1888926] Re: tls.tlscfgcmd not recognized; rebuild rsyslog against librelp 1.5.0

[Jorge Niedbalski]

gh a more
  complete fix would be to raise the Build-Depends from librelp-dev (>=
  1.4.0) to librelp-dev (>= 1.5.0).
+ 
+ [Risk potential]
+ 
+ * No identified as this is a rebuild that should have been done on all 
+ reverse dependencies of librelp-dev when upgraded from 1.4.0 to 1.5.0
+ 
+ 
+ [Fix]
+ 
+ Provide a rebuild SRU for focal.

** Changed in: rsyslog (Ubuntu Groovy)
   Status: New => Fix Released

** Changed in: rsyslog (Ubuntu Focal)
   Status: New => In Progress

** Changed in: rsyslog (Ubuntu Focal)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

** Changed in: rsyslog (Ubuntu Focal)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1888926

Title:
  tls.tlscfgcmd not recognized; rebuild rsyslog against librelp 1.5.0

Status in rsyslog package in Ubuntu:
  Fix Released
Status in rsyslog source package in Focal:
  In Progress
Status in rsyslog source package in Groovy:
  Fix Released

Bug description:
  [Description]

  Problem is according to 
https://launchpad.net/ubuntu/+source/librelp/+publishinghistory,
  librelp-dev 1.5.0 was published into focal at 2020-04-21, but reverse 
dependencies
  (such as rsyslog) weren't rebuilt after this new version was published

  # dpkg -l | grep librelp
  ii librelp-dev:amd64 1.5.0-1ubuntu2 amd64 Reliable Event Logging Protocol 
(RELP) library - development files
  ii librelp0:amd64 1.5.0-1ubuntu2 amd64 Reliable Event Logging Protocol (RELP) 
library

  rsyslogd: error during parsing file /etc/rsyslog.d/FILENAME.conf, on
  or before line 22: imrelp: librelp does not support input parameter
  'tls.tlscfgcmd'; it probably is too old (1.5.0 or higher should be
  fine); ignoring setting now. [v8.2001.0 try
  https://www.rsyslog.com/e/2207 ]

  [Reproducer]

  Setup a focal machine with rsyslog, using the following configuration:

  
  module(load="imrelp" tls.tlslib="openssl")

  input(
  type="imrelp" port="2515"
  tls="on"
  # This should work in rsyslog 8.2006.0:
  #tls.mycert="/etc/rsyslog.tls/fullchain.pem"
  # for now we use the work-around discussed in:
  # https://github.com/rsyslog/rsyslog/issues/4360
  tls.cacert="/etc/rsyslog.tls/chain.pem"
  tls.mycert="/etc/rsyslog.tls/cert.pem"
  tls.myprivkey="/etc/rsyslog.tls/privkey.pem"
  tls.tlscfgcmd="ServerPreference 
CipherString=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
 
Ciphersuites=TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384
 MinProtocol=TLSv1.2"
  )
  

  This error comes from this code in plugins/imrelp/imrelp.c:

  
  #if defined(HAVE_RELPENGINESETTLSCFGCMD)
  inst->tlscfgcmd = 
(uchar*)es_str2cstr(pvals[i].val.d.estr, NULL);
  #else
  parser_errmsg("imrelp: librelp does not support input 
parameter 'tls.tlscfgcmd'; "
  "it probably is too old (1.5.0 or higher 
should be fine); ignoring setting now.");
  #endif
  

  The build log for focal:
  
https://launchpadlibrarian.net/464665610/buildlog_ubuntu-focal-arm64.rsyslog_8.2001.0-1ubuntu1_BUILDING.txt.gz
  says:
  checking for relpSrvSetTlsConfigCmd... no
  checking for relpSrvSetTlsConfigCmd... (cached) no

  The build log for groovy:
  
https://launchpadlibrarian.net/486409321/buildlog_ubuntu-groovy-arm64.rsyslog_8.2006.0-2ubuntu1_BUILDING.txt.gz
  says:
  checking for relpSrvSetTlsConfigCmd... yes
  checking for relpSrvSetTlsConfigCmd... (cached) yes

  If I rebuild the rsyslog package, I get:
  checking for relpSrvSetTlsConfigCmd... yes
  checking for relpSrvSetTlsConfigCmd... (cached) yes

  I suspect that the rsyslog package was built against and older librelp
  version. A simple rebuild of rsyslog should fix this, though a more
  complete fix would be to raise the Build-Depends from librelp-dev (>=
  1.4.0) to librelp-dev (>= 1.5.0).

  [Risk potential]

  * No identified as this is a rebuild that should have been done on all 
  reverse dependencies of librelp-dev when upgraded from 1.4.0 to 1.5.0

  
  [Fix]

  Provide a rebuild SRU for focal.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1888926/+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 1888926] Re: tls.tlscfgcmd not recognized; rebuild rsyslog against librelp 1.5.0

[Jorge Niedbalski]

** Also affects: rsyslog (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: rsyslog (Ubuntu Focal)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1888926

Title:
  tls.tlscfgcmd not recognized; rebuild rsyslog against librelp 1.5.0

Status in rsyslog package in Ubuntu:
  New
Status in rsyslog source package in Focal:
  New
Status in rsyslog source package in Groovy:
  New

Bug description:
  rsyslogd: error during parsing file /etc/rsyslog.d/FILENAME.conf, on
  or before line 22: imrelp: librelp does not support input parameter
  'tls.tlscfgcmd'; it probably is too old (1.5.0 or higher should be
  fine); ignoring setting now. [v8.2001.0 try
  https://www.rsyslog.com/e/2207 ]

  Here is the config:

  
  module(load="imrelp" tls.tlslib="openssl")

  input(
  type="imrelp" port="2515"
  tls="on"
  # This should work in rsyslog 8.2006.0:
  #tls.mycert="/etc/rsyslog.tls/fullchain.pem"
  # for now we use the work-around discussed in:
  # https://github.com/rsyslog/rsyslog/issues/4360
  tls.cacert="/etc/rsyslog.tls/chain.pem"
  tls.mycert="/etc/rsyslog.tls/cert.pem"
  tls.myprivkey="/etc/rsyslog.tls/privkey.pem"
  tls.tlscfgcmd="ServerPreference 
CipherString=ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
 
Ciphersuites=TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384
 MinProtocol=TLSv1.2"
  )
  

  
  This error comes from this code in plugins/imrelp/imrelp.c:

  
  #if defined(HAVE_RELPENGINESETTLSCFGCMD)
  inst->tlscfgcmd = 
(uchar*)es_str2cstr(pvals[i].val.d.estr, NULL);
  #else
  parser_errmsg("imrelp: librelp does not support input 
parameter 'tls.tlscfgcmd'; "
  "it probably is too old (1.5.0 or higher 
should be fine); ignoring setting now.");
  #endif
  

  The build log for focal:
  
https://launchpadlibrarian.net/464665610/buildlog_ubuntu-focal-arm64.rsyslog_8.2001.0-1ubuntu1_BUILDING.txt.gz
  says:
  checking for relpSrvSetTlsConfigCmd... no
  checking for relpSrvSetTlsConfigCmd... (cached) no

  
  The build log for groovy:
  
https://launchpadlibrarian.net/486409321/buildlog_ubuntu-groovy-arm64.rsyslog_8.2006.0-2ubuntu1_BUILDING.txt.gz
  says:
  checking for relpSrvSetTlsConfigCmd... yes
  checking for relpSrvSetTlsConfigCmd... (cached) yes

  If I rebuild the rsyslog package, I get:
  checking for relpSrvSetTlsConfigCmd... yes
  checking for relpSrvSetTlsConfigCmd... (cached) yes

  I suspect that the rsyslog package was built against and older librelp
  version. A simple rebuild of rsyslog should fix this, though a more
  complete fix would be to raise the Build-Depends from librelp-dev (>=
  1.4.0) to librelp-dev (>= 1.5.0).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1888926/+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 1822416] Re: resolve: do not hit CNAME or DNAME entry in NODATA cache

[Jorge Niedbalski]

** Also affects: systemd (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Focal)
   Importance: Undecided
   Status: Confirmed

** Also affects: systemd (Ubuntu Disco)
   Importance: Undecided
   Status: New

** This bug is no longer a duplicate of bug 1818527
   Stub resolver cache is corrupted

-- 
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/1822416

Title:
  resolve: do not hit CNAME or DNAME entry in NODATA cache

Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Bionic:
  New
Status in systemd source package in Disco:
  New
Status in systemd source package in Eoan:
  New
Status in systemd source package in Focal:
  Confirmed

Bug description:
  The question: DNS A record lookups fail to resolve due to cached CNAME
  NODATA lookups ...

  https://askubuntu.com/questions/1063462/18-04-server-systemd-resolve-
  returns-cached-cname-nodata-for-a-lookup

  Upstream at Github: Systemd issue 998 - Cached cname NODATA returned
  for A lookup ...

  https://github.com/systemd/systemd/issues/9833

  
  Please patch ...

  
https://github.com/systemd/systemd/commit/3740146a4cbd99883af79e375ee4836206dcea4e

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1822416/+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 1815101] Re: [master] Restarting systemd-networkd breaks keepalived clusters

[Jorge Niedbalski]

For reference: https://github.com/systemd/systemd/pull/12511

-- 
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/1815101

Title:
  [master] Restarting systemd-networkd breaks keepalived clusters

Status in netplan:
  Invalid
Status in keepalived package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Triaged

Bug description:
  Configure netplan for interfaces, for example (a working config with
  IP addresses obfuscated)

  network:
  ethernets:
  eth0:
  addresses: [192.168.0.5/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth2:
  addresses:
- 12.13.14.18/29
- 12.13.14.19/29
  gateway4: 12.13.14.17
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth3:
  addresses: [10.22.11.6/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth4:
  addresses: [10.22.14.6/24]
  dhcp4: false
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  eth7:
  addresses: [9.5.17.34/29]
  dhcp4: false
  optional: true
  nameservers:
search: [blah.com, other.blah.com, hq.blah.com, cust.blah.com, 
phone.blah.com]
addresses: [10.22.11.1]
  version: 2

  Configure keepalived (again, a working config with IP addresses
  obfuscated)

  global_defs   # Block id
  {
  notification_email {
  sysadm...@blah.com
  }
  notification_email_from keepali...@system3.hq.blah.com
  smtp_server 10.22.11.7 # IP
  smtp_connect_timeout 30  # integer, seconds
  router_id system3  # string identifying the machine,
   # (doesn't have to be hostname).
  vrrp_mcast_group4 224.0.0.18 # optional, default 224.0.0.18
  vrrp_mcast_group6 ff02::12   # optional, default ff02::12
  enable_traps # enable SNMP traps
  }
  vrrp_sync_group collection {
  group {
  wan
  lan
  phone
  }
  vrrp_instance wan {
  state MASTER
  interface eth2
  virtual_router_id 77
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass BlahBlah
  }
  virtual_ipaddress {
  12.13.14.20
  }
  }
  vrrp_instance lan {
  state MASTER
  interface eth3
  virtual_router_id 78
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass MoreBlah
  }
  virtual_ipaddress {
  10.22.11.13/24
  }
  }
  vrrp_instance phone {
  state MASTER
  interface eth4
  virtual_router_id 79
  priority 150
  advert_int 1
  smtp_alert
  authentication {
  auth_type PASS
  auth_pass MostBlah
  }
  virtual_ipaddress {
  10.22.14.3/24
  }
  }

  At boot the affected interfaces have:
  5: eth4:  mtu 1500 qdisc mq state UP group 
default qlen 1000
  link/ether ab:cd:ef:90:c0:e3 brd ff:ff:ff:ff:ff:ff
  inet 10.22.14.6/24 brd 10.22.14.255 scope global eth4
 valid_lft forever preferred_lft forever
  inet 10.22.14.3/24 scope global secondary eth4
 valid_lft forever preferred_lft forever
  inet6 fe80::ae1f:6bff:fe90:c0e3/64 scope link 
 valid_lft forever preferred_lft forever
  7: eth3:  mtu 1500 qdisc mq state UP group 
default qlen 1000
  link/ether ab:cd:ef:b0:26:29 brd ff:ff:ff:ff:ff:ff
  inet 10.22.11.6/24 brd 10.22.11.255 scope global eth3
 valid_lft forever preferred_lft forever
  inet 10.22.11.13/24 scope global secondary eth3
 valid_lft forever preferred_lft forever
  inet6 fe80::ae1f:6bff:feb0:2629/64 scope link 
 valid_lft forever preferred_lft forever
  9: eth2:  mtu 1500 qdisc mq state UP group 
default qlen 1000
  link/ether ab:cd:ef:b0:26:2b brd ff:ff:ff:ff:ff:ff
  inet 12.13.14.18/29 brd 12.13.14.23 scope global eth2
 valid_lft forever preferred_lft forever
  inet 12.13.14.20/32 scope 

[Touch-packages] [Bug 1835581] Re: networkd-dhcp4 does not set prefsrc for dhcp-provided classless or static routes

[Jorge Niedbalski]

I've also verified that bionic-updates fixes the described issue

root@bionic-test:/home/ubuntu# ip route
default via 172.16.0.1 dev ens3 proto dhcp metric 1024 
172.16.0.0/24 dev ens3 proto kernel scope link src 172.16.0.50 
root@bionic-test:/home/ubuntu# ip r
default via 172.16.0.1 dev ens3 proto dhcp metric 1024 
172.16.0.0/24 dev ens3 proto kernel scope link src 172.16.0.50 
root@bionic-test:/home/ubuntu# ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
link/ether 52:54:00:db:d8:6a brd ff:ff:ff:ff:ff:ff
inet 172.16.0.50/24 brd 172.16.0.255 scope global ens3
   valid_lft forever preferred_lft forever
inet 172.16.0.24/24 brd 172.16.0.255 scope global secondary dynamic ens3
   valid_lft 3468sec preferred_lft 3468sec
inet6 fe80::5054:ff:fedb:d86a/64 scope link 
   valid_lft forever preferred_lft forever
root@bionic-test:/home/ubuntu# ip r
default via 172.16.0.1 dev ens3 proto dhcp metric 1024 
172.16.0.0/24 dev ens3 proto kernel scope link src 172.16.0.50 


root@bionic-test:/home/ubuntu# ip a
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
   valid_lft forever preferred_lft forever
inet6 ::1/128 scope host 
   valid_lft forever preferred_lft forever
2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
link/ether 52:54:00:db:d8:6a brd ff:ff:ff:ff:ff:ff
inet 172.16.0.50/24 brd 172.16.0.255 scope global ens3
   valid_lft forever preferred_lft forever
inet 172.16.0.24/24 brd 172.16.0.255 scope global secondary dynamic ens3
   valid_lft 3435sec preferred_lft 3435sec
inet6 fe80::5054:ff:fedb:d86a/64 scope link 
   valid_lft forever preferred_lft forever
3: ens7:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
link/ether 52:54:00:11:c6:5b brd ff:ff:ff:ff:ff:ff
root@bionic-test:/home/ubuntu# ip r
default via 172.16.0.1 dev ens3 proto dhcp src 172.16.0.24 metric 1024 
172.16.0.0/24 dev ens3 proto kernel scope link src 172.16.0.50 
root@bionic-test:/home/ubuntu# 


** Tags removed: verification-needed verification-needed-bionic 
verification-needed-disco
** Tags added: verification-done verification-done-bionic 
verification-done-disco

-- 
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/1835581

Title:
  networkd-dhcp4 does not set prefsrc for dhcp-provided classless or
  static routes

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Fix Committed
Status in systemd source package in Eoan:
  In Progress

Bug description:
  [impact]

  the systemd networkd dhcp4 client sets the prefsrc for the default
  route added when a dhcp server provides only the gateway; but if the
  dhcp server provides classless route(s), those are configured instead,
  and the prefsrc is not set for those.

  Normally this is ok, but if the dhcp client system has other
  address(es) configured on the interface using dhcp, then the src for
  packets sent through a classless/static route might not be the same as
  the address provided by the dhcp server.

  If the gateway/router provided in the dhcp classless/static route(s)
  only allows traffic from the address provided to the dhcp client, then
  traffic from the dhcp client may be dropped by the gateway/router.

  [test case]

  set up a dhcp server system (e.g. ubuntu with dnsmasq installed and
  configured) and a dhcp client system.  For example on the dhcp server,
  use this dnsmasq config:

  interface=ens8
  bind-interfaces
  domain=test,10.10.0.0/24
  dhcp-option=42,10.10.0.1
  dhcp-range=test,10.10.0.10,10.10.0.100,1h

  On the dhcp client system, use networkd config such as:

  $ cat /etc/systemd/network/80-ens8.network
  [Match]
  Name=ens8

  [Network]
  DHCP=ipv4
  LinkLocalAddressing=ipv6
  Address=10.10.0.5/24

  Reboot the client, or restart networkd, and it should result in:

  $ ip -4 a show ens8
  3: ens8:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8
     valid_lft forever preferred_lft forever
  inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8
     valid_lft 3580sec preferred_lft 3580sec

  $ ip r
  default via 10.10.0.1 dev ens8 proto dhcp src 10.10.0.75 metric 1024
  10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5
  10.10.0.1 

[Touch-packages] [Bug 1835581] Re: networkd-dhcp4 does not set prefsrc for dhcp-provided classless or static routes

[Jorge Niedbalski]

Hello,

I've verified this with disco-updates.


/etc/systemd/network/80-ens3.network
::
[Match]
Name=ens3

[Network]
DHCP=ipv4
LinkLocalAddressing=ipv6
Address=172.16.0.5/24


root@disco-test:/home/ubuntu# ip -4 a show ens3
2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
inet 172.16.0.5/24 brd 172.16.0.255 scope global ens3
   valid_lft forever preferred_lft forever
inet 172.16.0.21/24 brd 172.16.0.255 scope global secondary dynamic ens3
   valid_lft 3485sec preferred_lft 3485sec


root@disco-test:/home/ubuntu# ip route
default via 172.16.0.1 dev ens3 proto dhcp src 172.16.0.21 metric 1024 
172.16.0.0/24 dev ens3 proto kernel scope link src 172.16.0.5 
172.16.0.1 dev ens3 proto dhcp scope link src 172.16.0.21 metric 1024 

root@disco-test:/home/ubuntu# ip r get 1.1.1.1
1.1.1.1 via 172.16.0.1 dev ens3 src 172.16.0.21 uid 0 
cache 

-> setting classless option

ubuntu@disco-test:~$ sudo su
root@disco-test:/home/ubuntu# ip -4 a show ens3
2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
inet 172.16.0.5/24 brd 172.16.0.255 scope global ens3
   valid_lft forever preferred_lft forever
inet 172.16.0.21/24 brd 172.16.0.255 scope global secondary dynamic ens3
   valid_lft 3575sec preferred_lft 3575sec
root@disco-test:/home/ubuntu# ip r
default via 172.16.0.1 dev ens3 proto dhcp metric 1024 
172.16.0.0/24 dev ens3 proto kernel scope link src 172.16.0.5 
root@disco-test:/home/ubuntu#  ip r get 1.1.1.1
1.1.1.1 via 172.16.0.1 dev ens3 src 172.16.0.5 uid 0 
cache 


-> With the proposed package

ubuntu@disco-test:~$ sudo su
root@disco-test:/home/ubuntu# ip -4 a show ens3
2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
inet 172.16.0.5/24 brd 172.16.0.255 scope global ens3
   valid_lft forever preferred_lft forever
inet 172.16.0.21/24 brd 172.16.0.255 scope global secondary dynamic ens3
   valid_lft 3589sec preferred_lft 3589sec
root@disco-test:/home/ubuntu# ip r get 1.1.1.1
1.1.1.1 via 172.16.0.1 dev ens3 src 172.16.0.21 uid 0 
cache 
root@disco-test:/home/ubuntu# ip r
default via 172.16.0.1 dev ens3 proto dhcp src 172.16.0.21 metric 1024 
172.16.0.0/24 dev ens3 proto kernel scope link src 172.16.0.5

-- 
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/1835581

Title:
  networkd-dhcp4 does not set prefsrc for dhcp-provided classless or
  static routes

Status in systemd:
  Fix Released
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Fix Committed
Status in systemd source package in Eoan:
  In Progress

Bug description:
  [impact]

  the systemd networkd dhcp4 client sets the prefsrc for the default
  route added when a dhcp server provides only the gateway; but if the
  dhcp server provides classless route(s), those are configured instead,
  and the prefsrc is not set for those.

  Normally this is ok, but if the dhcp client system has other
  address(es) configured on the interface using dhcp, then the src for
  packets sent through a classless/static route might not be the same as
  the address provided by the dhcp server.

  If the gateway/router provided in the dhcp classless/static route(s)
  only allows traffic from the address provided to the dhcp client, then
  traffic from the dhcp client may be dropped by the gateway/router.

  [test case]

  set up a dhcp server system (e.g. ubuntu with dnsmasq installed and
  configured) and a dhcp client system.  For example on the dhcp server,
  use this dnsmasq config:

  interface=ens8
  bind-interfaces
  domain=test,10.10.0.0/24
  dhcp-option=42,10.10.0.1
  dhcp-range=test,10.10.0.10,10.10.0.100,1h

  On the dhcp client system, use networkd config such as:

  $ cat /etc/systemd/network/80-ens8.network
  [Match]
  Name=ens8

  [Network]
  DHCP=ipv4
  LinkLocalAddressing=ipv6
  Address=10.10.0.5/24

  Reboot the client, or restart networkd, and it should result in:

  $ ip -4 a show ens8
  3: ens8:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8
     valid_lft forever preferred_lft forever
  inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8
     valid_lft 3580sec preferred_lft 3580sec

  $ ip r
  default via 10.10.0.1 dev ens8 proto dhcp src 10.10.0.75 metric 1024
  10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5
  10.10.0.1 dev ens8 proto dhcp scope link src 10.10.0.75 metric 1024

  Note that, because networkd completes the static ip configuration
  before the dhcp reply is returned and processed, the static address is
  used for the subnet-local routing.  But for global routing through the
  gateway, the dhcp-provided address is used:

  $ ip r 

[Touch-packages] [Bug 1668771] Re: [SRU] systemd-resolved negative caching for extended period of time

[Jorge Niedbalski]

Without the patch for LP: #1668771 resolved caches the SERVFAIL answer
on disco.

oot@disco:/home/multipass# host www.montemar.cl
Host www.montemar.cl not found: 2(SERVFAIL)
(reverse-i-search)`': ^C
root@disco:/home/multipass# journalctl -u systemd-resolved -f
-- Logs begin at Fri 2019-07-26 13:15:35 -04. --
Jul 26 13:17:56 disco systemd-resolved[3872]: Transaction 43091 for 
 scope dns on ens3/*.
Jul 26 13:17:56 disco systemd-resolved[3872]: Using feature level UDP for 
transaction 43091.
Jul 26 13:17:56 disco systemd-resolved[3872]: Sending query packet with id 
43091.
Jul 26 13:17:56 disco systemd-resolved[3872]: Processing incoming packet on 
transaction 43091 (rcode=SERVFAIL).
Jul 26 13:17:56 disco systemd-resolved[3872]: Server returned error: SERVFAIL
Jul 26 13:17:56 disco systemd-resolved[3872]: Verified we get a response at 
feature level UDP from DNS server 10.91.4.1.
Jul 26 13:17:56 disco systemd-resolved[3872]: Added SERVFAIL cache entry for 
www.montemar.cl IN A 30s
Jul 26 13:17:56 disco systemd-resolved[3872]: Transaction 43091 for 
 on scope dns on ens3/* now complete with  
from network (unsigned).
Jul 26 13:17:56 disco systemd-resolved[3872]: Sending response packet with id 
40433 on interface 1/AF_INET.
Jul 26 13:17:56 disco systemd-resolved[3872]: Freeing transaction 43091.

With the patch for LP: #1668771 resolved + setting Cache: 'no-negative' doesn't 
caches the SERVFAIL option on disco.
Logs begin at Fri 2019-07-26 13:15:35 -04. --
Jul 26 13:18:21 disco systemd-resolved[3893]: Transaction 22380 for 
 scope dns on ens3/*.
Jul 26 13:18:21 disco systemd-resolved[3893]: Using feature level UDP for 
transaction 22380.
Jul 26 13:18:21 disco systemd-resolved[3893]: Sending query packet with id 
22380.
Jul 26 13:18:21 disco systemd-resolved[3893]: Processing incoming packet on 
transaction 22380 (rcode=SERVFAIL).
Jul 26 13:18:21 disco systemd-resolved[3893]: Server returned error: SERVFAIL
Jul 26 13:18:21 disco systemd-resolved[3893]: Verified we get a response at 
feature level UDP from DNS server 10.91.4.1.
Jul 26 13:18:21 disco systemd-resolved[3893]: Not caching negative entry for: 
www.montemar.cl IN A, cache mode set to no-negative
Jul 26 13:18:21 disco systemd-resolved[3893]: Transaction 22380 for 
 on scope dns on ens3/* now complete with  
from network (unsigned).
Jul 26 13:18:21 disco systemd-resolved[3893]: Sending response packet with id 
30418 on interface 1/AF_INET.
Jul 26 13:18:21 disco systemd-resolved[3893]: Freeing transaction 22380.


** Tags removed: verification-needed verification-needed-bionic 
verification-needed-disco
** Tags added: verification-done verification-done-bionic 
verification-done-disco

-- 
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/1668771

Title:
  [SRU] systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Committed
Status in systemd source package in Eoan:
  In Progress

Bug description:
  [Impact]

   * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache
  the result for very long (infinity?). I have to restart systemd-
  resolved to have the negative caching purged.

  * After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

  [Test Case]

  * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s 
(See 201d995),
  however, there are several use cases on which this condition is not 
acceptable (See #5552 comments)
  and the only workaround would be to disable cache entirely or flush it , 
which isn't optimal.

  * Configure /etc/systemd/resolved.conf as follows:

  Cache=yes (default)

  * Restart systemd-resolved (systemctl restart systemd-
  resolved.service)

  * Run a host/getent command against a entry that will return SERVFAIL
  and check the journalctl output to see that the reply gets served from
  cache.

  root@systemd-disco:/home/ubuntu# host www.no-record.cl
  Host www.montemar.cl not found: 2(SERVFAIL)
  root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n
  -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 
UTC. --
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for 
 on scope dns on ens3/* now complete with 
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet 
with id 61042 on interface 1/AF_INET.
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 
6222.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Got DNS stub UDP query 
packet for id 53580
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Looking up RR for  
www.no-record.cl IN A.
  Jul 23 15:10:17 systemd-disco 

[Touch-packages] [Bug 1668771] Re: [SRU] systemd-resolved negative caching for extended period of time

[Jorge Niedbalski]

Without the patch for LP: #1668771 resolved caches the SERVFAIL answer.

root@bionic:/home/multipass# host www.montemar.cl
Host www.montemar.cl not found: 2(SERVFAIL)
root@bionic:/home/multipass# journalctl -u systemd-resolved -f
-- Logs begin at Fri 2019-07-26 13:10:01 -04. --
Jul 26 13:13:12 bionic systemd-resolved[3167]: Transaction 25942 for 
 scope dns on ens3/*.
Jul 26 13:13:12 bionic systemd-resolved[3167]: Using feature level UDP for 
transaction 25942.
Jul 26 13:13:12 bionic systemd-resolved[3167]: Sending query packet with id 
25942.
Jul 26 13:13:12 bionic systemd-resolved[3167]: Processing incoming packet on 
transaction 25942. (rcode=SERVFAIL)
Jul 26 13:13:12 bionic systemd-resolved[3167]: Server returned error: SERVFAIL
Jul 26 13:13:12 bionic systemd-resolved[3167]: Verified we get a response at 
feature level UDP from DNS server 10.91.4.1.
Jul 26 13:13:12 bionic systemd-resolved[3167]: Added SERVFAIL cache entry for 
www.montemar.cl IN A 30s
Jul 26 13:13:12 bionic systemd-resolved[3167]: Transaction 25942 for 
 on scope dns on ens3/* now complete with  
from network (unsigned).
Jul 26 13:13:12 bionic systemd-resolved[3167]: Sending response packet with id 
26821 on interface 1/AF_INET.
Jul 26 13:13:12 bionic systemd-resolved[3167]: Freeing transaction 25942.

With the patch for LP: #1668771 resolved + setting Cache: 'no-negative'
doesn't caches the SERVFAIL option


root@bionic:/home/multipass# host www.montemar.cl
Host www.montemar.cl not found: 2(SERVFAIL)
root@bionic:/home/multipass# journalctl -u systemd-resolved -f
-- Logs begin at Fri 2019-07-26 13:10:01 -04. --
Jul 26 13:13:40 bionic systemd-resolved[3199]: Transaction 48671 for 
 scope dns on ens3/*.
Jul 26 13:13:40 bionic systemd-resolved[3199]: Using feature level UDP for 
transaction 48671.
Jul 26 13:13:40 bionic systemd-resolved[3199]: Sending query packet with id 
48671.
Jul 26 13:13:40 bionic systemd-resolved[3199]: Processing incoming packet on 
transaction 48671. (rcode=SERVFAIL)
Jul 26 13:13:40 bionic systemd-resolved[3199]: Server returned error: SERVFAIL
Jul 26 13:13:40 bionic systemd-resolved[3199]: Verified we get a response at 
feature level UDP from DNS server 10.91.4.1.
Jul 26 13:13:40 bionic systemd-resolved[3199]: Not caching negative entry for: 
www.montemar.cl IN A, cache mode set to no-negative
Jul 26 13:13:40 bionic systemd-resolved[3199]: Transaction 48671 for 
 on scope dns on ens3/* now complete with  
from network (unsigned).
Jul 26 13:13:40 bionic systemd-resolved[3199]: Sending response packet with id 
25454 on interface 1/AF_INET.
Jul 26 13:13:40 bionic systemd-resolved[3199]: Freeing transaction 48671.

Marking this as verified and working.

-- 
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/1668771

Title:
  [SRU] systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Committed
Status in systemd source package in Eoan:
  In Progress

Bug description:
  [Impact]

   * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache
  the result for very long (infinity?). I have to restart systemd-
  resolved to have the negative caching purged.

  * After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

  [Test Case]

  * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s 
(See 201d995),
  however, there are several use cases on which this condition is not 
acceptable (See #5552 comments)
  and the only workaround would be to disable cache entirely or flush it , 
which isn't optimal.

  * Configure /etc/systemd/resolved.conf as follows:

  Cache=yes (default)

  * Restart systemd-resolved (systemctl restart systemd-
  resolved.service)

  * Run a host/getent command against a entry that will return SERVFAIL
  and check the journalctl output to see that the reply gets served from
  cache.

  root@systemd-disco:/home/ubuntu# host www.no-record.cl
  Host www.montemar.cl not found: 2(SERVFAIL)
  root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n
  -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 
UTC. --
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for 
 on scope dns on ens3/* now complete with 
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet 
with id 61042 on interface 1/AF_INET.
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 
6222.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Got DNS stub UDP query 
packet for id 53580
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Looking up RR for  
www.no-record.cl IN A.
  Jul 23 15:10:17 systemd-disco 

[Touch-packages] [Bug 1668771] Re: [SRU] systemd-resolved negative caching for extended period of time

[Jorge Niedbalski]

** No longer affects: systemd (Ubuntu Xenial)

-- 
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/1668771

Title:
  [SRU] systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Disco:
  Fix Committed
Status in systemd source package in Eoan:
  In Progress

Bug description:
  [Impact]

   * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache
  the result for very long (infinity?). I have to restart systemd-
  resolved to have the negative caching purged.

  * After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

  [Test Case]

  * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s 
(See 201d995),
  however, there are several use cases on which this condition is not 
acceptable (See #5552 comments)
  and the only workaround would be to disable cache entirely or flush it , 
which isn't optimal.

  * Configure /etc/systemd/resolved.conf as follows:

  Cache=yes (default)

  * Restart systemd-resolved (systemctl restart systemd-
  resolved.service)

  * Run a host/getent command against a entry that will return SERVFAIL
  and check the journalctl output to see that the reply gets served from
  cache.

  root@systemd-disco:/home/ubuntu# host www.no-record.cl
  Host www.montemar.cl not found: 2(SERVFAIL)
  root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n
  -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 
UTC. --
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for 
 on scope dns on ens3/* now complete with 
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet 
with id 61042 on interface 1/AF_INET.
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 
6222.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Got DNS stub UDP query 
packet for id 53580
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Looking up RR for  
www.no-record.cl IN A.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: RCODE SERVFAIL cache 
hit for  www.no-record.cl IN A
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Transaction 58570 for < 
www.no-record.cl IN A> on scope dns on ens3/* now complete with  scope dns on ens3/.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Using feature level UDP 
for transaction 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending query packet 
with id 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Processing incoming 
packet on transaction 22382 (rcode=SERVFAIL).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Server returned error: 
SERVFAIL
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Not caching negative 
entry for: www.metaklass.org IN A, cache mode set to no-negative
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Transaction 22382 for 
 on scope dns on ens3/ now complete with from network 
(unsigned).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending response packet 
with id 31060 on interface 1/AF_INET.

  The following patch https://github.com/systemd/systemd/pull/13047
  implements the required changes.

  [Other Info]

  Note that systemd in Eoan is being upgraded to upstream 242, so I am
  not adding this to Eoan now, as I don't want to disturb the merge. If
  needed after the merge, I'll add to Eoan.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1668771/+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 1668771] Re: [SRU] systemd-resolved negative caching for extended period of time

[Jorge Niedbalski]

** Patch added: "lp1668771-disco.debdiff"
   
https://bugs.launchpad.net/systemd/+bug/1668771/+attachment/5278759/+files/lp1668771-disco.debdiff

-- 
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/1668771

Title:
  [SRU] systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  In Progress

Bug description:
  [Impact]

   * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache
  the result for very long (infinity?). I have to restart systemd-
  resolved to have the negative caching purged.

  * After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

  [Test Case]

  * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s 
(See 201d995),
  however, there are several use cases on which this condition is not 
acceptable (See #5552 comments)
  and the only workaround would be to disable cache entirely or flush it , 
which isn't optimal.

  * Configure /etc/systemd/resolved.conf as follows:

  Cache=yes (default)

  * Restart systemd-resolved (systemctl restart systemd-
  resolved.service)

  * Run a host/getent command against a entry that will return SERVFAIL
  and check the journalctl output to see that the reply gets served from
  cache.

  root@systemd-disco:/home/ubuntu# host www.no-record.cl
  Host www.montemar.cl not found: 2(SERVFAIL)
  root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n
  -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 
UTC. --
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for 
 on scope dns on ens3/* now complete with 
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet 
with id 61042 on interface 1/AF_INET.
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 
6222.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Got DNS stub UDP query 
packet for id 53580
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Looking up RR for  
www.no-record.cl IN A.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: RCODE SERVFAIL cache 
hit for  www.no-record.cl IN A
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Transaction 58570 for < 
www.no-record.cl IN A> on scope dns on ens3/* now complete with  scope dns on ens3/.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Using feature level UDP 
for transaction 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending query packet 
with id 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Processing incoming 
packet on transaction 22382 (rcode=SERVFAIL).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Server returned error: 
SERVFAIL
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Not caching negative 
entry for: www.metaklass.org IN A, cache mode set to no-negative
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Transaction 22382 for 
 on scope dns on ens3/ now complete with from network 
(unsigned).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending response packet 
with id 31060 on interface 1/AF_INET.

  The following patch https://github.com/systemd/systemd/pull/13047
  implements the required changes.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1668771/+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 1668771] Re: systemd-resolved negative caching for extended period of time

[Jorge Niedbalski]

** Patch added: "lp1668771-bionic.debdiff"
   
https://bugs.launchpad.net/systemd/+bug/1668771/+attachment/5278752/+files/lp1668771-bionic.debdiff

** Summary changed:

- systemd-resolved negative caching for extended period of time
+ [SRU] systemd-resolved negative caching for extended period of time

-- 
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/1668771

Title:
  [SRU] systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  In Progress

Bug description:
  [Impact]

   * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache
  the result for very long (infinity?). I have to restart systemd-
  resolved to have the negative caching purged.

  * After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

  [Test Case]

  * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s 
(See 201d995),
  however, there are several use cases on which this condition is not 
acceptable (See #5552 comments)
  and the only workaround would be to disable cache entirely or flush it , 
which isn't optimal.

  * Configure /etc/systemd/resolved.conf as follows:

  Cache=yes (default)

  * Restart systemd-resolved (systemctl restart systemd-
  resolved.service)

  * Run a host/getent command against a entry that will return SERVFAIL
  and check the journalctl output to see that the reply gets served from
  cache.

  root@systemd-disco:/home/ubuntu# host www.no-record.cl
  Host www.montemar.cl not found: 2(SERVFAIL)
  root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n
  -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 
UTC. --
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for 
 on scope dns on ens3/* now complete with 
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet 
with id 61042 on interface 1/AF_INET.
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 
6222.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Got DNS stub UDP query 
packet for id 53580
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Looking up RR for  
www.no-record.cl IN A.
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: RCODE SERVFAIL cache 
hit for  www.no-record.cl IN A
  Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Transaction 58570 for < 
www.no-record.cl IN A> on scope dns on ens3/* now complete with  scope dns on ens3/.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Using feature level UDP 
for transaction 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending query packet 
with id 22382.
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Processing incoming 
packet on transaction 22382 (rcode=SERVFAIL).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Server returned error: 
SERVFAIL
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Not caching negative 
entry for: www.metaklass.org IN A, cache mode set to no-negative
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Transaction 22382 for 
 on scope dns on ens3/ now complete with from network 
(unsigned).
  Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending response packet 
with id 31060 on interface 1/AF_INET.

  The following patch https://github.com/systemd/systemd/pull/13047
  implements the required changes.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1668771/+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 1668771] Re: systemd-resolved negative caching for extended period of time

[Jorge Niedbalski]

** Description changed:

- 231-9ubuntu3
+ [Impact]
  
- If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache the
+  * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache the
  result for very long (infinity?). I have to restart systemd-resolved to
  have the negative caching purged.
  
- After SERVFAIL DNS server issue has been resolved, chromium/firefox
+ * After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.
+ 
+ [Test Case]
+ 
+ * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s 
(See 201d995),
+ however, there are several use cases on which this condition is not 
acceptable (See #5552 comments)
+ and the only workaround would be to disable cache entirely or flush it , 
which isn't optimal.
+ 
+ * Configure /etc/systemd/resolved.conf as follows:
+ 
+ Cache=yes (default)
+ 
+ * Restart systemd-resolved (systemctl restart systemd-resolved.service)
+ 
+ * Run a host/getent command against a entry that will return SERVFAIL
+ and check the journalctl output to see that the reply gets served from
+ cache.
+ 
+ root@systemd-disco:/home/ubuntu# host www.no-record.cl
+ Host www.montemar.cl not found: 2(SERVFAIL)
+ root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n
+ -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 
UTC. --
+ Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Transaction 6222 for 
 on scope dns on ens3/* now complete with 
+ Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Sending response packet 
with id 61042 on interface 1/AF_INET.
+ Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: Freeing transaction 
6222.
+ Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Got DNS stub UDP query 
packet for id 53580
+ Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Looking up RR for  
www.no-record.cl IN A.
+ Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: RCODE SERVFAIL cache 
hit for  www.no-record.cl IN A
+ Jul 23 15:10:17 systemd-disco systemd-resolved[1282]: Transaction 58570 for < 
www.no-record.cl IN A> on scope dns on ens3/* now complete with  scope dns on ens3/.
+ Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Using feature level UDP 
for transaction 22382.
+ Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending query packet 
with id 22382.
+ Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Processing incoming 
packet on transaction 22382 (rcode=SERVFAIL).
+ Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Server returned error: 
SERVFAIL
+ Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Not caching negative 
entry for: www.metaklass.org IN A, cache mode set to no-negative
+ Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Transaction 22382 for 
 on scope dns on ens3/ now complete with from network 
(unsigned).
+ Jul 12 18:48:31 systemd-disco systemd-resolved[2635]: Sending response packet 
with id 31060 on interface 1/AF_INET.
+ 
+ The following patch https://github.com/systemd/systemd/pull/13047
+ implements the required changes.

-- 
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/1668771

Title:
  systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  In Progress

Bug description:
  [Impact]

   * If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache
  the result for very long (infinity?). I have to restart systemd-
  resolved to have the negative caching purged.

  * After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

  [Test Case]

  * If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s 
(See 201d995),
  however, there are several use cases on which this condition is not 
acceptable (See #5552 comments)
  and the only workaround would be to disable cache entirely or flush it , 
which isn't optimal.

  * Configure /etc/systemd/resolved.conf as follows:

  Cache=yes (default)

  * Restart systemd-resolved (systemctl restart systemd-
  resolved.service)

  * Run a host/getent command against a entry that will return SERVFAIL
  and check the journalctl output to see that the reply gets served from
  cache.

  root@systemd-disco:/home/ubuntu# host www.no-record.cl
  Host www.montemar.cl not found: 2(SERVFAIL)
  root@systemd-disco:/home/ubuntu# journalctl -u systemd-resolved -n
  -- Logs begin at Fri 2019-07-12 18:09:42 UTC, end at Tue 2019-07-23 15:10:17 
UTC. --
  Jul 23 15:10:10 systemd-disco systemd-resolved[1282]: 

[Touch-packages] [Bug 1668771] Re: systemd-resolved negative caching for extended period of time

[Jorge Niedbalski]

** Tags added: sts sts-sru-needed

-- 
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/1668771

Title:
  systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  In Progress

Bug description:
  231-9ubuntu3

  If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache the
  result for very long (infinity?). I have to restart systemd-resolved
  to have the negative caching purged.

  After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1668771/+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 1668771] Re: systemd-resolved negative caching for extended period of time

[Jorge Niedbalski]

-- 
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/1668771

Title:
  systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  In Progress

Bug description:
  231-9ubuntu3

  If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache the
  result for very long (infinity?). I have to restart systemd-resolved
  to have the negative caching purged.

  After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1668771/+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 1668771] Re: systemd-resolved negative caching for extended period of time

[Jorge Niedbalski]

** Patch added: "lp1668771-eoan.debdiff"
   
https://bugs.launchpad.net/systemd/+bug/1668771/+attachment/5278115/+files/lp1668771-eoan.debdiff

-- 
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/1668771

Title:
  systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  In Progress

Bug description:
  231-9ubuntu3

  If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache the
  result for very long (infinity?). I have to restart systemd-resolved
  to have the negative caching purged.

  After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1668771/+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 1668771] Re: systemd-resolved negative caching for extended period of time

[Jorge Niedbalski]

** Changed in: systemd (Ubuntu Disco)
   Importance: Undecided => High

** Changed in: systemd (Ubuntu Bionic)
   Importance: Undecided => High

** Changed in: systemd (Ubuntu Xenial)
   Importance: Undecided => High

-- 
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/1668771

Title:
  systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  In Progress

Bug description:
  231-9ubuntu3

  If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache the
  result for very long (infinity?). I have to restart systemd-resolved
  to have the negative caching purged.

  After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1668771/+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 1668771] Re: systemd-resolved negative caching for extended period of time

[Jorge Niedbalski]

** Also affects: systemd (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: systemd (Ubuntu Disco)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

** Changed in: systemd (Ubuntu Bionic)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

** Changed in: systemd (Ubuntu Xenial)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

** Changed in: systemd (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: systemd (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: systemd (Ubuntu Disco)
   Status: New => In Progress

-- 
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/1668771

Title:
  systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  In Progress

Bug description:
  231-9ubuntu3

  If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache the
  result for very long (infinity?). I have to restart systemd-resolved
  to have the negative caching purged.

  After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1668771/+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 1668771] Re: systemd-resolved negative caching for extended period of time

[Jorge Niedbalski]

The proposal to extend the 'cache' option with 'no-negative' has been
merged upstream. I will proceed with the backports to Ubuntu on the
affected LTS releases.

[0] https://github.com/systemd/systemd/pull/13047

-- 
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/1668771

Title:
  systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress

Bug description:
  231-9ubuntu3

  If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache the
  result for very long (infinity?). I have to restart systemd-resolved
  to have the negative caching purged.

  After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1668771/+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 1668771] Re: systemd-resolved negative caching for extended period of time

[Jorge Niedbalski]

I've made a proposal to change the resolved.conf Cache option to a tri-
state "no, no-negative, yes" values. [0]

If a lookup returns SERVFAIL systemd-resolved will cache the result for 30s 
(See 201d995),
however, there are several use cases on which this condition is not acceptable 
(See #5552 comments)
and the only workaround would be to disable cache entirely or flush it , which 
isn't optimal.

This change adds the 'no-negative' option when set it avoids putting in cache
negative answers but still works the same heuristics for positive answers.

[0] https://github.com/systemd/systemd/pull/13047

** Changed in: systemd (Ubuntu)
   Importance: Undecided => High

** Changed in: systemd (Ubuntu)
   Status: Confirmed => In Progress

-- 
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/1668771

Title:
  systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  In Progress

Bug description:
  231-9ubuntu3

  If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache the
  result for very long (infinity?). I have to restart systemd-resolved
  to have the negative caching purged.

  After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1668771/+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 1668771] Re: systemd-resolved negative caching for extended period of time

[Jorge Niedbalski]

** Changed in: systemd (Ubuntu)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

-- 
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/1668771

Title:
  systemd-resolved negative caching for extended period of time

Status in systemd:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  231-9ubuntu3

  If a DNS lookup returns SERVFAIL, systemd-resolved seems to cache the
  result for very long (infinity?). I have to restart systemd-resolved
  to have the negative caching purged.

  After SERVFAIL DNS server issue has been resolved, chromium/firefox
  still returns DNS error despite host can correctly resolve the name.

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1668771/+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 1641272] Re: Debug symbols package doesnt exist

[Jorge Niedbalski]

** Description changed:

- On Yakkery with ddebs repos enabled there is no debug packages for
+ On Yakkety with ddebs repos enabled there is no debug packages for
  dnsmasq

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1641272

Title:
  Debug symbols package doesnt exist

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  On Yakkety with ddebs repos enabled there is no debug packages for
  dnsmasq

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1641272/+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 1686036] Re: mountpoint remains in use after restore snapshot

[Jorge Niedbalski]

** Summary changed:

- strange behavior after restore snapshot
+ mountpoint remains in use after restore snapshot

** Also affects: lxd (Ubuntu)
   Importance: Undecided
   Status: New

** No longer affects: lxc (Ubuntu)

** Changed in: lxd (Ubuntu)
   Status: New => Fix Committed

** Changed in: lxd (Ubuntu)
   Importance: Undecided => High

** Changed in: lxd (Ubuntu)
 Assignee: (unassigned) => Christian Brauner (cbrauner)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1686036

Title:
  mountpoint remains in use after restore snapshot

Status in lxd package in Ubuntu:
  Fix Committed
Status in lxd source package in Xenial:
  New
Status in lxd source package in Yakkety:
  New
Status in lxd source package in Zesty:
  New
Status in lxd source package in Artful:
  Fix Committed

Bug description:
  uname -a
  Linux lxd2-chel1 4.4.0-72-generic #93-Ubuntu SMP Fri Mar 31 14:07:41 UTC 2017 
x86_64 x86_64 x86_64 GNU/Linux

  lxd: 2.12-0ubuntu3~ubuntu16.04.1~ppa1
  zfsutils-linux: 0.6.5.6-0ubuntu16

  # lsb_release -a
  No LSB modules are available.
  Distributor ID: Ubuntu
  Description:Ubuntu 16.04.2 LTS
  Release:16.04
  Codename:   xenial

  after restore container from shapshot cannot add new snapshot or restore again
  until restart container

  example:

  
  # lxc image list
  
+---+--++--++-+--+
  | ALIAS | FINGERPRINT  | PUBLIC | DESCRIPTION 
 |  ARCH  |  SIZE   | UPLOAD DATE  |
  
+---+--++--++-+--+
  | debian/jessie | ba43812c4cb9 | no | Debian jessie amd64 
(20170423_22:42) | x86_64 | 94.14MB | Apr 24, 2017 at 9:07am (UTC) |
  
+---+--++--++-+--+

  # lxc launch debian/jessie
  Creating popular-kitten

  The container you are starting doesn't have any network attached to it.
To create a new network, use: lxc network create
To attach a network to a container, use: lxc network attach

  Starting popular-kitten

  
  # lxc info popular-kitten
  Name: popular-kitten
  Remote: unix:/var/lib/lxd/unix.socket
  Architecture: x86_64
  Created: 2017/04/25 07:17 UTC
  Status: Running
  Type: persistent
  Profiles: default
  Pid: 6965
  Ips:
lo:   inet127.0.0.1
lo:   inet6   ::1
  Resources:
Processes: 7
Disk usage:
  root: 1.48MB
CPU usage:
  CPU usage (in seconds): 25
Memory usage:
  Memory (current): 16.22MB
  Memory (peak): 23.01MB
Network usage:
  lo:
Bytes received: 0B
Bytes sent: 0B
Packets received: 0
Packets sent: 0

  # lxc profile show default
  config: {}
  description: Default LXD profile
  devices:
root:
  path: /
  pool: main-pool
  type: disk
  name: default
  used_by:
  - /1.0/containers/popular-kitten
  # lxc snapshot popular-kitten

  # zfs get mounted main-pool/containers/popular-kitten 
  NAME PROPERTY  VALUESOURCE
  main-pool/containers/popular-kitten  mounted   yes  -

  # zfs get mounted main-pool/snapshots/popular-kitten 
  NAMEPROPERTY  VALUESOURCE
  main-pool/snapshots/popular-kitten  mounted   yes  -

  # lxc restore popular-kitten snap0

  # zfs get mounted main-pool/snapshots/popular-kitten
  NAMEPROPERTY  VALUESOURCE
  main-pool/snapshots/popular-kitten  mounted   yes  -

  # zfs get mounted main-pool/containers/popular-kitten
  NAME PROPERTY  VALUESOURCE
  main-pool/containers/popular-kitten  mounted   no   -

  # lxc snapshot popular-kitten 
  error: Failed to mount ZFS filesystem: filesystem 
'main-pool/containers/popular-kitten' is already mounted
  cannot mount 'main-pool/containers/popular-kitten': mountpoint or dataset is 
busy

  # lxc restore popular-kitten snap0
  error: Failed to mount ZFS filesystem: filesystem 
'main-pool/containers/popular-kitten' is already mounted
  cannot mount 'main-pool/containers/popular-kitten': mountpoint or dataset is 
busy

  but container still work:

  # lxc info popular-kitten
  Name: popular-kitten
  Remote: unix:/var/lib/lxd/unix.socket
  Architecture: x86_64
  Created: 2017/04/25 07:17 UTC
  Status: Running
  ...

  # lxc exec popular-kitten bash
  root@popular-kitten:~# uptime
   07:34:06 up 8 min,  0 users,  load average: 0.00, 0.02, 0.03

  after restart container:

  # lxc restart popular-kitten

  # zfs get mounted main-pool/containers/popular-kitten
  NAME PROPERTY  VALUESOURCE
  

[Touch-packages] [Bug 1641272] Re: Debug symbols package doesnt exist

[Jorge Niedbalski]

** Changed in: dnsmasq (Ubuntu)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1641272

Title:
  Debug symbols package doesnt exist

Status in dnsmasq package in Ubuntu:
  New

Bug description:
  On Yakkery with ddebs repos enabled there is no debug packages for
  dnsmasq

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1641272/+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 1638695] Re: Python 2.7.12 performance regression

[Jorge Niedbalski]

Hello,

I have been working to track down the origin of the performance penalty
exposed by this bug.

All the tests that I am performing are made on top of a locally compiled 
version of python 2.7.12 (from upstream sources, not applying any ubuntu patch 
on it)
built with different versions of GCC, 5.3.1 (current) and 4.8.0 both coming 
from the Ubuntu archives.

I can see important performance differences as I mentioned on my previous 
comments (check the full comparisons stats) just by
switching the GCC version. I decided to focus my investigation on the pickle 
module, since it seems to be the most affected one being
approximately 1.17x slower between the different gcc versions.

Due to the amount of changes introduced between 4.8.0 and 5.3.1 I decided to 
not persue the approach
of doing a bisection of the changes for identifying an offending commit yet, 
until we can identify which optimization or change
at compile time is causing the regression and focus our investigation on that 
specific area.

My understanding is that the performance penalty caused by the compiler might 
be related
to 2 factors, a important change on the linked libc or a optimization made by 
the compiler in the resulting object. 

Since the resulting objects are linked against the same glibc version 2.23, I 
will not consider that factor as part of the analysis,
instead I will focus on analyzing the performance of the resulting objects 
generated by the compiler.

For following this approach I ran the pyperformance suite and used a valgrind 
session excluding all the modules with the exception of the pickle module, 
using the default supressions to avoid missing any reference in the python 
runtime with the following arguments:

valgrind --tool=callgrind --instr-atstart=no --trace-children=yes
venv/cpython2.7-6ed9b6df9cd4/bin/python -m performance run --python
/usr/local/bin/python2.7 -b pickle --inside-venv

I did run this process multiple times with both GCC 4.8.0 and 5.3.1  to produce 
a large set of callgrind files to analyze , those callgrind files contains the 
full tree of execution 
including all the relocations, jumps, calls to the libc and the python runtime 
itself and of course time spent per function and the amount of calls made to it.

I cleaned out all the resulting callgrind files removing the files smaller than 
100k and the ones that were not loading the cPickle
extension (https://pastebin.canonical.com/175951/). 

Over that set of files I executed callgrind_annotate to generate the stats per 
function ordered by the exclusive cost of function, 
Then with this script (http://paste.ubuntu.com/23795048/
) I added all the costs per function per GCC version (4.8 and 5.3.1) and then I 
calculated the variance in cost between them.

The resulting file contains a tuple with the following format:

function name - gcc 4.8 cost - gcc 5.3.1 cost - variance in percent

As an example:

/home/ubuntu/python/cpython/Objects/tupleobject.c:tupleiter_dealloc 
258068.00 445009.00 (variance: 0.724387)
/home/ubuntu/python/cpython/Objects/object.c:try_3way_compare 984860.00 
1676351.00 (variance: 0.702121)
/home/ubuntu/python/cpython/Python/marshal.c:r_object 183524.00 
27742.00 (variance: -0.848837)

The full results can be located here sorted by variance in descending
order http://paste.ubuntu.com/23795023/

Now that we have these results we can move forward comparing the generated code 
for the functions with bigger variance 
and track which optimization done by GCC might be altering the resulting 
objects.

I will update this case after further investigation.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python2.7 in Ubuntu.
https://bugs.launchpad.net/bugs/1638695

Title:
  Python 2.7.12 performance regression

Status in python2.7 package in Ubuntu:
  Confirmed

Bug description:
  I work on the OpenStack-Ansible project and we've noticed that testing
  jobs on 16.04 take quite a bit longer to complete than on 14.04.  They
  complete within an hour on 14.04 but they normally take 90 minutes or
  more on 16.04.  We use the same version of Ansible with both versions
  of Ubuntu.

  After more digging, I tested python performance (using the
  'performance' module) on 14.04 (2.7.6) and on 16.04 (2.7.12).  There
  is a significant performance difference between each version of
  python.  That is detailed in a spreadsheet[0].

  I began using perf to dig into the differences when running the python
  performance module and when using Ansible playbooks.  CPU migrations
  (as measured by perf) are doubled in Ubuntu 16.04 when running the
  same python workloads.

  I tried changing some of the kerne.sched sysctl configurables but they
  had very little effect on the results.

  I compiled python 2.7.12 from source on 14.04 and found the
  performance to be unchanged there.  I'm not entirely sure where the
  problem might be now.

  We also 

[Touch-packages] [Bug 1638695] Re: Python 2.7.12 performance regression

[Jorge Niedbalski]

** Changed in: python2.7 (Ubuntu)
   Importance: Undecided => High

** Changed in: python2.7 (Ubuntu)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python2.7 in Ubuntu.
https://bugs.launchpad.net/bugs/1638695

Title:
  Python 2.7.12 performance regression

Status in python2.7 package in Ubuntu:
  Confirmed

Bug description:
  I work on the OpenStack-Ansible project and we've noticed that testing
  jobs on 16.04 take quite a bit longer to complete than on 14.04.  They
  complete within an hour on 14.04 but they normally take 90 minutes or
  more on 16.04.  We use the same version of Ansible with both versions
  of Ubuntu.

  After more digging, I tested python performance (using the
  'performance' module) on 14.04 (2.7.6) and on 16.04 (2.7.12).  There
  is a significant performance difference between each version of
  python.  That is detailed in a spreadsheet[0].

  I began using perf to dig into the differences when running the python
  performance module and when using Ansible playbooks.  CPU migrations
  (as measured by perf) are doubled in Ubuntu 16.04 when running the
  same python workloads.

  I tried changing some of the kerne.sched sysctl configurables but they
  had very little effect on the results.

  I compiled python 2.7.12 from source on 14.04 and found the
  performance to be unchanged there.  I'm not entirely sure where the
  problem might be now.

  We also have a bug open in OpenStack-Ansible[1] that provides
  additional detail. Thanks in advance for any help you can provide!

  [0] 
https://docs.google.com/spreadsheets/d/18MmptS_DAd1YP3OhHWQqLYVA9spC3xLt4PS3STI6tds/edit?usp=sharing
  [1] https://bugs.launchpad.net/openstack-ansible/+bug/1637494

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1638695/+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 1638695] Re: Python 2.7.12 performance regression

[Jorge Niedbalski]

Hello,

I am in the process of verifying this performance regression on a 16.04
Xenial machine using the kernel Linux-4.4.0-38.

I ran a locally compiled python 2.7.12 version built with different
versions of GCC, 5.3.1 (current) and 4.8.0 both coming from the Ubuntu
archives.

The benchmark suite I am using is the pyperformance suite
(https://github.com/python/performance), I am running the full test
suite, using the following command:

$ pyperformance run --python=python2 -o xxx.json

According to the latest test run i did using Python 2.7.12/GCC 4.8
(using GCC 5.3.1 as the baseline), 50% of the tests (32/64) have a
significant variance in performance from which 19/32 are slower (in
times ranging from 5-15%).

Just for information, I am comparing results using the following
command:

$ pyperformance compare python-2.7.12-gcc-5.3.1.json
python-2.7.12-gcc-4.8.0.json

I am attaching here the current comparison results for analysis.


** Attachment added: "comparison-gcc-5.3.1-gcc-4.8.json"
   
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1638695/+attachment/4778622/+files/comparison-gcc-5.3.1-gcc-4.8.json

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python2.7 in Ubuntu.
https://bugs.launchpad.net/bugs/1638695

Title:
  Python 2.7.12 performance regression

Status in python2.7 package in Ubuntu:
  Confirmed

Bug description:
  I work on the OpenStack-Ansible project and we've noticed that testing
  jobs on 16.04 take quite a bit longer to complete than on 14.04.  They
  complete within an hour on 14.04 but they normally take 90 minutes or
  more on 16.04.  We use the same version of Ansible with both versions
  of Ubuntu.

  After more digging, I tested python performance (using the
  'performance' module) on 14.04 (2.7.6) and on 16.04 (2.7.12).  There
  is a significant performance difference between each version of
  python.  That is detailed in a spreadsheet[0].

  I began using perf to dig into the differences when running the python
  performance module and when using Ansible playbooks.  CPU migrations
  (as measured by perf) are doubled in Ubuntu 16.04 when running the
  same python workloads.

  I tried changing some of the kerne.sched sysctl configurables but they
  had very little effect on the results.

  I compiled python 2.7.12 from source on 14.04 and found the
  performance to be unchanged there.  I'm not entirely sure where the
  problem might be now.

  We also have a bug open in OpenStack-Ansible[1] that provides
  additional detail. Thanks in advance for any help you can provide!

  [0] 
https://docs.google.com/spreadsheets/d/18MmptS_DAd1YP3OhHWQqLYVA9spC3xLt4PS3STI6tds/edit?usp=sharing
  [1] https://bugs.launchpad.net/openstack-ansible/+bug/1637494

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1638695/+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 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

** No longer affects: libnl3 (Ubuntu Precise)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578

Title:
   libnl should be updated to support up to 63 VFs per single PF

Status in libnl3 package in Ubuntu:
  Fix Released
Status in libnl3 source package in Trusty:
  Fix Released

Bug description:
  [Impact]

  libnl can only enable up to 30 VFs even if the PF supports up to 63
  VFs in an Openstack SRIOV configuration.

  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on
  Ubuntu 14.04.4.

  When trying to enable a guest with more than 30 VFs attached, the
  following error is returned:

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

  [Test Case]

   1) Edit /etc/default/grub.

  GRUB_CMDLINE_LINUX="intel_iommu=on ixgbe.max_vfs=63"

   2) Update grub and reboot the machine.

  $ sudo update-grub

   3) Check that the virtual functions are available.

  $ sudo lspci|grep -i eth | grep -i virtual | wc -l
  126

   4) Create a KVM guest.

  $ sudo uvt-kvm create guest1 release=trusty

   5) List the VF devices.

  $ sudo lspci|grep -i eth | grep -i virtual | awk '{print $1}' | sed
  's/\:/\_/g' | sed 's/\./\_/g' > devices.txt

   6) Get the libvirt node device.

  $ sudo for device in $(cat ./devices.txt); do virsh nodedev-list |
  grep $device; done > pci_devices.txt

   7) Generate the XML config for each device.

  $ sudo mkdir devices && for d in $(cat pci_devices.txt); do virsh
  nodedev-dumpxml $d > devices/$d.xml; done

   8) Save and Run the following script.
  (http://pastebin.ubuntu.com/23374186/)

  $ sudo python generate-interfaces.py |grep address | wc -l

   9) Finally attach the devices to the guest.

  $ sudo for i in $(seq 0 63); do virsh attach-device guest1 
./interfaces/$i.xml --config; done
  Device attached successfully
  [...]

  Device attached successfully
  Device attached successfully

   10) Then destroy/start the guest again, at this point the error is
  reproduced.

  $ sudo virsh destroy guest1
  Domain guest1 destroyed

  $ sudo virsh start guest1

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

  [Regression Potential]

   * None identified.

  [Other Info]

   * Redhat Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1040626

   * A workaround is to install a newer library release.

  $ wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  $ wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  $ wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
  $ dpkg -i libnl-3-200_3.2.24-2_amd64.deb
  $ dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
  $ dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+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 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

Hello Bryan,

After installing the -proposed version the error presented on this bug
is not reproducible anymore and the guest starts correctly.

You can follow the reproduction steps that I added to the bug's
description.

Without -proposed:

$ sudo virsh destroy guest1
Domain guest1 destroyed

$ sudo virsh start guest1

error: Failed to start domain guest1
error: internal error: missing IFLA_VF_INFO in netlink response

With proposed:

root@bronzor:/home/ubuntu# start libvirt-bin
libvirt-bin start/running, process 31492

root@bronzor:/home/ubuntu# virsh start guest1
Domain guest1 started


** Tags removed: verification-needed
** Tags added: verification-done

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578

Title:
   libnl should be updated to support up to 63 VFs per single PF

Status in libnl3 package in Ubuntu:
  Fix Released
Status in libnl3 source package in Precise:
  New
Status in libnl3 source package in Trusty:
  Fix Committed

Bug description:
  [Impact]

  libnl can only enable up to 30 VFs even if the PF supports up to 63
  VFs in an Openstack SRIOV configuration.

  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on
  Ubuntu 14.04.4.

  When trying to enable a guest with more than 30 VFs attached, the
  following error is returned:

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

  [Test Case]

   1) Edit /etc/default/grub.

  GRUB_CMDLINE_LINUX="intel_iommu=on ixgbe.max_vfs=63"

   2) Update grub and reboot the machine.

  $ sudo update-grub

   3) Check that the virtual functions are available.

  $ sudo lspci|grep -i eth | grep -i virtual | wc -l
  126

   4) Create a KVM guest.

  $ sudo uvt-kvm create guest1 release=trusty

   5) List the VF devices.

  $ sudo lspci|grep -i eth | grep -i virtual | awk '{print $1}' | sed
  's/\:/\_/g' | sed 's/\./\_/g' > devices.txt

   6) Get the libvirt node device.

  $ sudo for device in $(cat ./devices.txt); do virsh nodedev-list |
  grep $device; done > pci_devices.txt

   7) Generate the XML config for each device.

  $ sudo mkdir devices && for d in $(cat pci_devices.txt); do virsh
  nodedev-dumpxml $d > devices/$d.xml; done

   8) Save and Run the following script.
  (http://pastebin.ubuntu.com/23374186/)

  $ sudo python generate-interfaces.py |grep address | wc -l

   9) Finally attach the devices to the guest.

  $ sudo for i in $(seq 0 63); do virsh attach-device guest1 
./interfaces/$i.xml --config; done
  Device attached successfully
  [...]

  Device attached successfully
  Device attached successfully

   10) Then destroy/start the guest again, at this point the error is
  reproduced.

  $ sudo virsh destroy guest1
  Domain guest1 destroyed

  $ sudo virsh start guest1

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

  [Regression Potential]

   * None identified.

  [Other Info]

   * Redhat Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1040626

   * A workaround is to install a newer library release.

  $ wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  $ wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  $ wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
  $ dpkg -i libnl-3-200_3.2.24-2_amd64.deb
  $ dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
  $ dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+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 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

** Patch added: "fix-1567578-trusty.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+attachment/4766476/+files/fix-1567578-trusty.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578

Title:
   libnl should be updated to support up to 63 VFs per single PF

Status in libnl3 package in Ubuntu:
  Fix Released
Status in libnl3 source package in Precise:
  New
Status in libnl3 source package in Trusty:
  In Progress

Bug description:
  [Description]

  Ubuntu 14.04.4 and SRIOV settings.

  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on
  Ubuntu 14.04.4

  When trying to enable a guest with more than 30 VFs attached, the
  following error is returned:

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

  [Impact]

  The library release is the 3.2.21-1 the bug is impacting on the
  maximum VFs number that can be enabled (up to 30) even if the PF
  supports up to 63 VFs in an Openstack SRIOV configuration

  [Test Case]

  The sequence to reproduce this bug is:

  1) Edit /etc/default/grub

  GRUB_CMDLINE_LINUX="intel_iommu=on ixgbe.max_vfs=63"

  2) $ sudo update-grub

  ### Reboot the machine.

  3) Check that the virtual functions are available:

  $ sudo lspci|grep -i eth | grep -i virtual | wc -l
  126

  4) Create a KVM guest

  $ sudo uvt-kvm create guest1 release=trusty

  5) List the VF devices :

  $ sudo lspci|grep -i eth | grep -i virtual | awk '{print $1}' | sed
  's/\:/\_/g' | sed 's/\./\_/g' > devices.txt

  6) Get the libvirt node device:

  $ sudo for device in $(cat ./devices.txt); do virsh nodedev-list |
  grep $device; done > pci_devices.txt

  7) Generate the XML config for each device:

  $ sudo mkdir devices && for d in $(cat pci_devices.txt); do virsh
  nodedev-dumpxml $d > devices/$d.xml; done

  8) Save and Run the following script
  (http://pastebin.ubuntu.com/23374186/)

  $ sudo python generate-interfaces.py |grep address | wc -l

  9) Finally attach the devices to the guest.

  $ sudo for i in $(seq 0 63); do virsh attach-device guest1 
./interfaces/$i.xml --config; done
  Device attached successfully
  [...]

  Device attached successfully
  Device attached successfully

  10) Then destroy/start the guest again, at this point the error is
  reproduced.

  $ sudo virsh destroy guest1
  Domain guest1 destroyed

  $ sudo virsh start guest1

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

   * detailed instructions how to reproduce the bug

   * these should allow someone who is not familiar with the affected
 package to reproduce the bug and verify that the updated package fixes
 the problem.

  [Regression Potential]

   ** None identified.

  [Other Info]

  - Redhat Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1040626

  [Workaround]

  The workaround is to install a newer library release, the 3.2.24-2:

  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+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 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

Hello,

After running a bisect between tags libnl3_2_21 and libnl3_2_22 I identified
the fixer commit to be 807fddc nl: Increase receive buffer size to 4 pages

commit 807fddc4cd9ecb12ba64e1b7fa26d86b6c2f19b0
Author: Thomas Graf 
Date:   Wed May 8 13:52:27 2013 +0200

nl: Increase receive buffer size to 4 pages

Assuming that the kernel does not send more than a page is no longer valid,
and enabling MSG_PEEK'ing by default to figure out the exact message buffer
requirements can have a negative influence on the performance of existing
applications. Bumping the default receive buffer space to 4 pages seems
a sane default.

Signed-off-by: Thomas Graf 

---

After applying this patch on top of the current trusty-updates this problem
is not longer exhibited and I can attach the full 128 VFs to the guest.

I am proposing this patch for SRU, and I already updated the description
with the reproduction steps.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578

Title:
   libnl should be updated to support up to 63 VFs per single PF

Status in libnl3 package in Ubuntu:
  Fix Released
Status in libnl3 source package in Precise:
  New
Status in libnl3 source package in Trusty:
  In Progress

Bug description:
  [Description]

  Ubuntu 14.04.4 and SRIOV settings.

  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on
  Ubuntu 14.04.4

  When trying to enable a guest with more than 30 VFs attached, the
  following error is returned:

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

  [Impact]

  The library release is the 3.2.21-1 the bug is impacting on the
  maximum VFs number that can be enabled (up to 30) even if the PF
  supports up to 63 VFs in an Openstack SRIOV configuration

  [Test Case]

  The sequence to reproduce this bug is:

  1) Edit /etc/default/grub

  GRUB_CMDLINE_LINUX="intel_iommu=on ixgbe.max_vfs=63"

  2) $ sudo update-grub

  ### Reboot the machine.

  3) Check that the virtual functions are available:

  $ sudo lspci|grep -i eth | grep -i virtual | wc -l
  126

  4) Create a KVM guest

  $ sudo uvt-kvm create guest1 release=trusty

  5) List the VF devices :

  $ sudo lspci|grep -i eth | grep -i virtual | awk '{print $1}' | sed
  's/\:/\_/g' | sed 's/\./\_/g' > devices.txt

  6) Get the libvirt node device:

  $ sudo for device in $(cat ./devices.txt); do virsh nodedev-list |
  grep $device; done > pci_devices.txt

  7) Generate the XML config for each device:

  $ sudo mkdir devices && for d in $(cat pci_devices.txt); do virsh
  nodedev-dumpxml $d > devices/$d.xml; done

  8) Save and Run the following script
  (http://pastebin.ubuntu.com/23374186/)

  $ sudo python generate-interfaces.py |grep address | wc -l

  9) Finally attach the devices to the guest.

  $ sudo for i in $(seq 0 63); do virsh attach-device guest1 
./interfaces/$i.xml --config; done
  Device attached successfully
  [...]

  Device attached successfully
  Device attached successfully

  10) Then destroy/start the guest again, at this point the error is
  reproduced.

  $ sudo virsh destroy guest1
  Domain guest1 destroyed

  $ sudo virsh start guest1

  error: Failed to start domain guest1
  error: internal error: missing IFLA_VF_INFO in netlink response

   * detailed instructions how to reproduce the bug

   * these should allow someone who is not familiar with the affected
 package to reproduce the bug and verify that the updated package fixes
 the problem.

  [Regression Potential]

   ** None identified.

  [Other Info]

  - Redhat Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1040626

  [Workaround]

  The workaround is to install a newer library release, the 3.2.24-2:

  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+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 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

Hello,

I am able to reproduce this bug consistently on a Trusty (3.19.0-73-generic) 
machine
equipped with 2 ixgbe 10GbE cards:

04:00.0 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit 
X540-AT2 (rev 01)
04:00.1 Ethernet controller: Intel Corporation Ethernet Controller 10-Gigabit 
X540-AT2 (rev 01)

The sequence to reproduce this bug is:

1)  Edit /etc/default/grub

GRUB_CMDLINE_LINUX="intel_iommu=on ixgbe.max_vfs=63"

2) $ sudo update-grub

### Reboot the machine.

3) Check that  the virtual functions are available:

$ sudo lspci|grep -i eth | grep -i virtual | wc -l
126

4) Create a KVM guest

$ sudo uvt-kvm create guest1 release=trusty

5) List the VF devices :

$ sudo lspci|grep -i eth | grep -i virtual | awk '{print $1}' | sed
's/\:/\_/g' | sed 's/\./\_/g' > devices.txt

6) Get the libvirt node device:

$ sudo for device in $(cat ./devices.txt); do virsh nodedev-list | grep
$device; done  > pci_devices.txt

7) Generate the XML config for each device:

$ sudo mkdir devices && for d in $(cat pci_devices.txt); do virsh
nodedev-dumpxml $d > devices/$d.xml; done

8) Save and Run the following script
(http://pastebin.ubuntu.com/23374186/)

$ sudo python generate-interfaces.py |grep address | wc -l

9) Finally attach the devices to the guest.

$ sudo for i in $(seq 0 63); do virsh attach-device guest1 ./interfaces/$i.xml 
--config; done
Device attached successfully
[...]

Device attached successfully
Device attached successfully

10) Then destroy/start the guest again, at this point the error is
reproduced.

$ sudo virsh destroy guest1
Domain guest1 destroyed

$ sudo virsh start guest1

error: Failed to start domain guest1
error: internal error: missing IFLA_VF_INFO in netlink response

Please note that this error is not reproducible using libnl3_2_22. I am 
currently 
working to bisect and identify the offending commit and propose a backport to 
Ubuntu Trusty.



** Description changed:

+ [Description]
+ 
  Ubuntu 14.04.4 and SRIOV settings.
  
  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on Ubuntu
  14.04.4
  
- The library release is the 3.2.21-1 and the bug is impacting on the
- maximum VFs number that can be enabled (up to 30) even if the PF
- supports up to 63 VFs in an Openstack SRIOV configuration
+ When trying to enable a guest with more than 30 VFs attached, the
+ following error is returned:
+ 
+ error: Failed to start domain guest1
+ error: internal error: missing IFLA_VF_INFO in netlink response
+ 
+ [Impact]
+ 
+ The library release is the 3.2.21-1 the bug is impacting on the maximum
+ VFs number that can be enabled (up to 30) even if the PF supports up to
+ 63 VFs in an Openstack SRIOV configuration
+ 
+ [Test Case]
+ 
+ The sequence to reproduce this bug is:
+ 
+ 1) Edit /etc/default/grub
+ 
+ GRUB_CMDLINE_LINUX="intel_iommu=on ixgbe.max_vfs=63"
+ 
+ 2) $ sudo update-grub
+ 
+ ### Reboot the machine.
+ 
+ 3) Check that the virtual functions are available:
+ 
+ $ sudo lspci|grep -i eth | grep -i virtual | wc -l
+ 126
+ 
+ 4) Create a KVM guest
+ 
+ $ sudo uvt-kvm create guest1 release=trusty
+ 
+ 5) List the VF devices :
+ 
+ $ sudo lspci|grep -i eth | grep -i virtual | awk '{print $1}' | sed
+ 's/\:/\_/g' | sed 's/\./\_/g' > devices.txt
+ 
+ 6) Get the libvirt node device:
+ 
+ $ sudo for device in $(cat ./devices.txt); do virsh nodedev-list | grep
+ $device; done > pci_devices.txt
+ 
+ 7) Generate the XML config for each device:
+ 
+ $ sudo mkdir devices && for d in $(cat pci_devices.txt); do virsh
+ nodedev-dumpxml $d > devices/$d.xml; done
+ 
+ 8) Save and Run the following script
+ (http://pastebin.ubuntu.com/23374186/)
+ 
+ $ sudo python generate-interfaces.py |grep address | wc -l
+ 
+ 9) Finally attach the devices to the guest.
+ 
+ $ sudo for i in $(seq 0 63); do virsh attach-device guest1 
./interfaces/$i.xml --config; done
+ Device attached successfully
+ [...]
+ 
+ Device attached successfully
+ Device attached successfully
+ 
+ 10) Then destroy/start the guest again, at this point the error is
+ reproduced.
+ 
+ $ sudo virsh destroy guest1
+ Domain guest1 destroyed
+ 
+ $ sudo virsh start guest1
+ 
+ error: Failed to start domain guest1
+ error: internal error: missing IFLA_VF_INFO in netlink response
+ 
+  * detailed instructions how to reproduce the bug
+ 
+  * these should allow someone who is not familiar with the affected
+package to reproduce the bug and verify that the updated package fixes
+the problem.
+ 
+ [Regression Potential]
+ 
+  ** None identified.
+ 
+ [Other Info]
+ 
+ - Redhat Bug: https://bugzilla.redhat.com/show_bug.cgi?id=1040626
+ 
+ [Workaround]
  
  The workaround is to install a newer library release, the 3.2.24-2:
  
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  wget 

[Touch-packages] [Bug 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

** Changed in: libnl3 (Ubuntu Trusty)
   Status: New => In Progress

** Changed in: libnl3 (Ubuntu Trusty)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578

Title:
   libnl should be updated to support up to 63 VFs per single PF

Status in libnl3 package in Ubuntu:
  Fix Released
Status in libnl3 source package in Precise:
  New
Status in libnl3 source package in Trusty:
  In Progress

Bug description:
  Ubuntu 14.04.4 and SRIOV settings.

  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on
  Ubuntu 14.04.4

  The library release is the 3.2.21-1 and the bug is impacting on the
  maximum VFs number that can be enabled (up to 30) even if the PF
  supports up to 63 VFs in an Openstack SRIOV configuration

  The workaround is to install a newer library release, the 3.2.24-2:

  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+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 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

** Changed in: libnl3 (Ubuntu)
   Status: Confirmed => Fix Released

** Changed in: libnl3 (Ubuntu)
 Assignee: Jorge Niedbalski (niedbalski) => (unassigned)

** Changed in: libnl3 (Ubuntu Trusty)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

** Changed in: libnl3 (Ubuntu Precise)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578

Title:
   libnl should be updated to support up to 63 VFs per single PF

Status in libnl3 package in Ubuntu:
  Fix Released
Status in libnl3 source package in Precise:
  New
Status in libnl3 source package in Trusty:
  New

Bug description:
  Ubuntu 14.04.4 and SRIOV settings.

  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on
  Ubuntu 14.04.4

  The library release is the 3.2.21-1 and the bug is impacting on the
  maximum VFs number that can be enabled (up to 30) even if the PF
  supports up to 63 VFs in an Openstack SRIOV configuration

  The workaround is to install a newer library release, the 3.2.24-2:

  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+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 1567578] Re: libnl should be updated to support up to 63 VFs per single PF

[Jorge Niedbalski]

** Changed in: libnl3 (Ubuntu)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

** Changed in: libnl3 (Ubuntu)
   Importance: Low => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libnl3 in Ubuntu.
https://bugs.launchpad.net/bugs/1567578

Title:
   libnl should be updated to support up to 63 VFs per single PF

Status in libnl3 package in Ubuntu:
  Confirmed

Bug description:
  Ubuntu 14.04.4 and SRIOV settings.

  As already documented in https://bugs.launchpad.net/mos/+bug/1501738
  there is a bug in the default libnl library release installed on
  Ubuntu 14.04.4

  The library release is the 3.2.21-1 and the bug is impacting on the
  maximum VFs number that can be enabled (up to 30) even if the PF
  supports up to 63 VFs in an Openstack SRIOV configuration

  The workaround is to install a newer library release, the 3.2.24-2:

  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-genl-3-200_3.2.24-2_amd64.deb
  wget 
https://launchpad.net/ubuntu/+archive/primary/+files/libnl-route-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-genl-3-200_3.2.24-2_amd64.deb
  dpkg -i libnl-route-3-200_3.2.24-2_amd64.deb

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1567578/+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 1628687] [NEW] Assertion failure when PID 1 receives a zero-length message over notify socket

[Jorge Niedbalski]

Public bug reported:

Environment:

Xenial 16.04.1
Amd64

Description.

Systemd fails an assertion in manager_invoke_notify_message when a zero-
length message is received over /run/systemd/notify. This allows a local
user to perform a denial-of-service attack against PID 1.

How to trigger the bug:

$ while true; do NOTIFY_SOCKET=/run/systemd/notify systemd-notify "";
done

The following entries are written into /var/log/syslog, at this point
systemd is crashed.

Sep 28 20:57:20 ubuntu systemd[1]: Started User Manager for UID 1000.
Sep 28 20:57:28 ubuntu systemd[1]: Assertion 'n > 0' failed at 
../src/core/manager.c:1501, function manager_invoke_notify_message(). Aborting.
Sep 28 20:57:29 ubuntu systemd[1]: Caught , dumped core as pid 1307.
Sep 28 20:57:29 ubuntu systemd[1]: Freezing execution.


Public bug: https://github.com/systemd/systemd/issues/4234

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: Confirmed


** Tags: sts

** Tags added: sts

-- 
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/1628687

Title:
  Assertion failure when PID 1 receives a zero-length message over
  notify socket

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Environment:

  Xenial 16.04.1
  Amd64

  Description.

  Systemd fails an assertion in manager_invoke_notify_message when a
  zero-length message is received over /run/systemd/notify. This allows
  a local user to perform a denial-of-service attack against PID 1.

  How to trigger the bug:

  $ while true; do NOTIFY_SOCKET=/run/systemd/notify systemd-notify "";
  done

  The following entries are written into /var/log/syslog, at this point
  systemd is crashed.

  Sep 28 20:57:20 ubuntu systemd[1]: Started User Manager for UID 1000.
  Sep 28 20:57:28 ubuntu systemd[1]: Assertion 'n > 0' failed at 
../src/core/manager.c:1501, function manager_invoke_notify_message(). Aborting.
  Sep 28 20:57:29 ubuntu systemd[1]: Caught , dumped core as pid 1307.
  Sep 28 20:57:29 ubuntu systemd[1]: Freezing execution.

  
  Public bug: https://github.com/systemd/systemd/issues/4234

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1628687/+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 1403955] Re: DHCP's "Option interface-mtu 9000" is being ignored on bridge interface br0

[Jorge Niedbalski]

** Tags removed: sts sts-needs-review

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1403955

Title:
  DHCP's "Option interface-mtu 9000" is being ignored on bridge
  interface br0

Status in juju-core:
  Triaged
Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  In an env with jumbo frames enabled, and using MAAS as DHCP server,
  the client receives the following IPv4 lease:

  $ cat /var/lib/dhcp/dhclient.br0.leases
  lease {
    interface "br0";
    fixed-address 10.230.20.26;
    filename "pxelinux.0";
    option subnet-mask 255.255.248.0;
    option dhcp-lease-time 43200;
    option routers 10.230.16.1;
    option dhcp-message-type 5;
    option dhcp-server-identifier 10.230.20.1;
    option domain-name-servers 10.230.20.1;
    option interface-mtu 9000;
    option broadcast-address 10.230.23.255;
    option domain-name "ctsstack.qa.1ss";
    renew 3 2014/12/17 16:48:15;
    rebind 3 2014/12/17 21:52:09;
    expire 3 2014/12/17 23:22:09;
  }

  The interfaces show the following config after boot:

  $ ifconfig br0
  br0   Link encap:Ethernet  HWaddr a0:d3:c1:01:9d:58
    inet addr:10.230.20.26  Bcast:10.230.23.255  Mask:255.255.248.0
    inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    RX packets:530530 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1591569 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:68713489 (68.7 MB)  TX bytes:213710979 (213.7 MB)

  $ ifconfig eth0
  eth0  Link encap:Ethernet  HWaddr a0:d3:c1:01:9d:58
    inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    RX packets:10539274 errors:0 dropped:3394 overruns:0 frame:454
    TX packets:2627412 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:2320560616 (2.3 GB)  TX bytes:3562885157 (3.5 GB)
    Interrupt:32

  
  "option interface-mtu 9000;" from the lease file is being ignored by br0. 
Could it be related to eth0 MTU size? If that's the case, shouldn't both 
interfaces be updated?

  Other info:

  $ brctl show br0
  bridge name   bridge id   STP enabled interfaces
  br0   8000.a0d3c1019d58   no  eth0

  $ cat /etc/network/eth0.config
  iface eth0 inet manual

  auto br0
  iface br0 inet dhcp
    bridge_ports eth0

To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-core/+bug/1403955/+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 1568485] Re: kernel: audit: type=1400 audit(1460259033.648:34): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13

[Jorge Niedbalski]

** Changed in: isc-dhcp (Ubuntu Trusty)
   Status: New => In Progress

** Changed in: isc-dhcp (Ubuntu Trusty)
   Importance: Undecided => Medium

** Changed in: isc-dhcp (Ubuntu Trusty)
 Assignee: (unassigned) => Jorge Niedbalski (niedbalski)

** Patch added: "Trusty Patch"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1568485/+attachment/4637656/+files/lp-1568485-trusty.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1568485

Title:
  kernel: audit: type=1400 audit(1460259033.648:34): apparmor="DENIED"
  operation="sendmsg" info="Failed name lookup - disconnected path"
  error=-13

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  Confirmed

Bug description:
  Get this logged on a fully upgraded 64 desktop (proposed archive
  enabled)

  kernel: audit: type=1400 audit(1460259033.648:34): apparmor="DENIED"
  operation="sendmsg" info="Failed name lookup - disconnected path"
  error=-13 profile="/sbin/dhclient" name="run/systemd/journal/dev-log"
  pid=1102 comm="dhclient" requested_mask="w" denied_mask="w" fsuid=0
  ouid=0

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: apparmor 2.10.95-0ubuntu1
  ProcVersionSignature: Ubuntu 4.4.0-18.34-generic 4.4.6
  Uname: Linux 4.4.0-18-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_modeset nvidia
  ApportVersion: 2.20.1-0ubuntu1
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sun Apr 10 12:23:56 2016
  ProcKernelCmdline: BOOT_IMAGE=/boot/vmlinuz-4.4.0-18-generic 
root=UUID=7c755ed6-51cc-4b75-88ac-9c75acf82749 ro
  SourcePackage: apparmor
  Syslog:
   
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1568485/+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 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode

[Jorge Niedbalski]

** Changed in: dnsmasq (Ubuntu Precise)
 Assignee: Jorge Niedbalski (niedbalski) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1006898

Title:
  [SRU] dnsmasq fails at leasing issues when using vlan mode

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Precise:
  Incomplete

Bug description:
  ** Issue **

  There is an issue with the way nova uses dnsmasq in VLAN mode. It starts
  up a single copy of dnsmasq for each vlan on the network host (or on
  every host in multi_host mode). The problem is in the way that dnsmasq
  binds to an ip address and port[2]. Both copies can respond to broadcast
  packet, but unicast packets can only be answered by one of the copies.

  In nova this means that guests from only one project will get responses
  to their unicast dhcp renew requests. Unicast projects from guests in
  other projects get ignored. What happens next is different depending on
  the guest os. Linux generally will send a broadcast packet out after
  the unicast fails, and so the only effect is a small (tens of ms) hiccup
  while interface is reconfigured. It can be much worse than that,
  however. I have seen cases where Windows just gives up and ends up with
  a non-configured interface.

  This bug was first noticed by some users of openstack who rolled their
  own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket
  option, it will allow different daemons to share the port and respond to
  unicast packets, as long as they listen on different interfaces. I
  managed to communicate with Simon Kelley, the maintainer of dnsmasq and
  he has integrated a fix[3] for the issue in the current version[1] of
  dnsmaq.

  [3]
  
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12

  ** Development Fix **

  This has been fixed in quantal with the newer version of dnmasq.

  ** Stable Fix **

  I have backported the patch which fixes this issue, I have attached
  the debdiff and the buildlog.

  ** Test Case **

  1. Install openstack with vlan mode.
  2. Watch instances loose their IP addresses.

  ** Regression Potential **

  Minimal, most installations dont use this type of networking.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+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 1403955] Re: DHCP's "Option interface-mtu 9000" is being ignored on bridge interface br0

[Jorge Niedbalski]

** Tags added: sts-needs-review

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1403955

Title:
  DHCP's "Option interface-mtu 9000" is being ignored on bridge
  interface br0

Status in juju-core:
  Triaged
Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  In an env with jumbo frames enabled, and using MAAS as DHCP server,
  the client receives the following IPv4 lease:

  $ cat /var/lib/dhcp/dhclient.br0.leases
  lease {
    interface "br0";
    fixed-address 10.230.20.26;
    filename "pxelinux.0";
    option subnet-mask 255.255.248.0;
    option dhcp-lease-time 43200;
    option routers 10.230.16.1;
    option dhcp-message-type 5;
    option dhcp-server-identifier 10.230.20.1;
    option domain-name-servers 10.230.20.1;
    option interface-mtu 9000;
    option broadcast-address 10.230.23.255;
    option domain-name "ctsstack.qa.1ss";
    renew 3 2014/12/17 16:48:15;
    rebind 3 2014/12/17 21:52:09;
    expire 3 2014/12/17 23:22:09;
  }

  The interfaces show the following config after boot:

  $ ifconfig br0
  br0   Link encap:Ethernet  HWaddr a0:d3:c1:01:9d:58
    inet addr:10.230.20.26  Bcast:10.230.23.255  Mask:255.255.248.0
    inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    RX packets:530530 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1591569 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:68713489 (68.7 MB)  TX bytes:213710979 (213.7 MB)

  $ ifconfig eth0
  eth0  Link encap:Ethernet  HWaddr a0:d3:c1:01:9d:58
    inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    RX packets:10539274 errors:0 dropped:3394 overruns:0 frame:454
    TX packets:2627412 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:2320560616 (2.3 GB)  TX bytes:3562885157 (3.5 GB)
    Interrupt:32

  
  "option interface-mtu 9000;" from the lease file is being ignored by br0. 
Could it be related to eth0 MTU size? If that's the case, shouldn't both 
interfaces be updated?

  Other info:

  $ brctl show br0
  bridge name   bridge id   STP enabled interfaces
  br0   8000.a0d3c1019d58   no  eth0

  $ cat /etc/network/eth0.config
  iface eth0 inet manual

  auto br0
  iface br0 inet dhcp
    bridge_ports eth0

To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-core/+bug/1403955/+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 1382054] Re: Add support for configuring VLAN interfaces in the initrd

[Jorge Niedbalski]

** Tags added: sts

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1382054

Title:
  Add support for configuring VLAN interfaces in the initrd

Status in initramfs-tools package in Ubuntu:
  Confirmed

Bug description:
  It would be helpful to be able to create VLAN network interfaces in initrd 
images provided
  by Ubuntu, based on kernel command line parameters. (i.e. VLAN=eth0.100, )

  Some use cases for this feature addition are MAAS users trying to boot 
machines
  using a specific VLAN interface.

  On a specific case we have 2 physical network interfaces, one is plugged into 
a specific VLAN interface,
  Since we can specify the network interface on BIOS, the initial PXE boot 
occurs, but
  then the installation fails when using the fast-path installer because the 
specific VLAN is not configured on the ram disk.

  While we can use the other network interface because is a trunk interface 
that allows us to use
  several VLANs, this is not supported on all the network architectures and 
some security limitations doesn't allows this method.

  Reference Redhat implementation can be found here:

  - http://marc.info/?l=initramfsm=133767307516594

  Reference Suse implementation can be found here:

  - https://gitorious.org/opensuse/agrafs-
  mkinitrd/commit/6124f87f3132b6369c0335c319832619a49d0bf7

  The command line syntax for this could be something like, similar to
  Redhat implementation

  vlan=vlanname:phydevice

  For an example:

  vlan=eth0.2:eth0

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1382054/+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 1244578] Re: lightdm-session runs xrdb with -nocpp option

[Jorge Niedbalski]

** Changed in: lightdm (Ubuntu Trusty)
   Status: New = In Progress

** Changed in: lightdm (Ubuntu Utopic)
   Status: New = In Progress

** Changed in: lightdm (Ubuntu Vivid)
   Status: New = In Progress

** Changed in: lightdm (Ubuntu Trusty)
 Assignee: (unassigned) = Jorge Niedbalski (niedbalski)

** Changed in: lightdm (Ubuntu Utopic)
 Assignee: (unassigned) = Jorge Niedbalski (niedbalski)

** Changed in: lightdm (Ubuntu Vivid)
 Assignee: (unassigned) = Jorge Niedbalski (niedbalski)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1244578

Title:
  lightdm-session runs xrdb with -nocpp option

Status in lightdm package in Ubuntu:
  Confirmed
Status in lightdm source package in Trusty:
  In Progress
Status in lightdm source package in Utopic:
  In Progress
Status in lightdm source package in Vivid:
  In Progress

Bug description:
  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet

  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213

  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+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 1244578] Re: lightdm-session runs xrdb with -nocpp option

[Jorge Niedbalski]

** Patch removed: Vivid Patch
   
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+attachment/4415158/+files/fix-lp-1244578-vivid.patch

** Patch added: Vivid Patch
   
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+attachment/4415185/+files/fix-lp-1244578-vivid.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1244578

Title:
  lightdm-session runs xrdb with -nocpp option

Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Trusty:
  In Progress
Status in lightdm source package in Utopic:
  In Progress
Status in lightdm source package in Vivid:
  In Progress

Bug description:
  [Impact]

  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet

  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213

  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)

  [Test Case]

   - Install solarized theme
  https://github.com/solarized/xresources/blob/master/solarized

  - Load default Xresources file (xrdb  .XDefaults )

  - Now every macro supported by CPP will not work.

  
  [Regression Potential] 

  * No regression potential advised, small (0.001%) load average increase
  on startup time because of enabling Cpp.

  [Solution]

  Backport default wily session to older releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+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 1244578] Re: lightdm-session runs xrdb with -nocpp option

[Jorge Niedbalski]

** Patch added: Trusty Patch
   
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+attachment/4415160/+files/fix-lp-1244578-trusty.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1244578

Title:
  lightdm-session runs xrdb with -nocpp option

Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Trusty:
  In Progress
Status in lightdm source package in Utopic:
  In Progress
Status in lightdm source package in Vivid:
  In Progress

Bug description:
  [Impact]

  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet

  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213

  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)

  [Test Case]

   - Install solarized theme
  https://github.com/solarized/xresources/blob/master/solarized

  - Load default Xresources file (xrdb  .XDefaults )

  - Now every macro supported by CPP will not work.

  
  [Regression Potential] 

  * No regression potential advised, small (0.001%) load average increase
  on startup time because of enabling Cpp.

  [Solution]

  Backport default wily session to older releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+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 1244578] Re: lightdm-session runs xrdb with -nocpp option

[Jorge Niedbalski]

** Patch added: Vivid Patch
   
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+attachment/4415158/+files/fix-lp-1244578-vivid.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1244578

Title:
  lightdm-session runs xrdb with -nocpp option

Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Trusty:
  In Progress
Status in lightdm source package in Utopic:
  In Progress
Status in lightdm source package in Vivid:
  In Progress

Bug description:
  [Impact]

  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet

  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213

  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)

  [Test Case]

   - Install solarized theme
  https://github.com/solarized/xresources/blob/master/solarized

  - Load default Xresources file (xrdb  .XDefaults )

  - Now every macro supported by CPP will not work.

  
  [Regression Potential] 

  * No regression potential advised, small (0.001%) load average increase
  on startup time because of enabling Cpp.

  [Solution]

  Backport default wily session to older releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+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 1244578] Re: lightdm-session runs xrdb with -nocpp option

[Jorge Niedbalski]

This is fixed on Wily, I am attaching the Vivid, Utopic and Trusty
patches.

** Description changed:

+ [Impact]
+ 
  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet
  
  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213
  
  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)
+ 
+ [Test Case]
+ 
+  - Install solarized theme
+ https://github.com/solarized/xresources/blob/master/solarized
+ 
+ - Load default Xresources file (xrdb  .XDefaults )
+ 
+ - Now every macro supported by CPP will not work.
+ 
+ 
+ [Regression Potential] 
+ 
+ * No regression potential advised, small (0.001%) load average increase
+ on startup time because of enabling Cpp.
+ 
+ [Solution]
+ 
+ Backport default wily session to older releases.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1244578

Title:
  lightdm-session runs xrdb with -nocpp option

Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Trusty:
  In Progress
Status in lightdm source package in Utopic:
  In Progress
Status in lightdm source package in Vivid:
  In Progress

Bug description:
  [Impact]

  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet

  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213

  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)

  [Test Case]

   - Install solarized theme
  https://github.com/solarized/xresources/blob/master/solarized

  - Load default Xresources file (xrdb  .XDefaults )

  - Now every macro supported by CPP will not work.

  
  [Regression Potential] 

  * No regression potential advised, small (0.001%) load average increase
  on startup time because of enabling Cpp.

  [Solution]

  Backport default wily session to older releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+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 1244578] Re: lightdm-session runs xrdb with -nocpp option

[Jorge Niedbalski]

** Patch added: Utopic Patch
   
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+attachment/4415159/+files/fix-lp-1244578-utopic.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1244578

Title:
  lightdm-session runs xrdb with -nocpp option

Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Trusty:
  In Progress
Status in lightdm source package in Utopic:
  In Progress
Status in lightdm source package in Vivid:
  In Progress

Bug description:
  [Impact]

  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet

  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213

  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)

  [Test Case]

   - Install solarized theme
  https://github.com/solarized/xresources/blob/master/solarized

  - Load default Xresources file (xrdb  .XDefaults )

  - Now every macro supported by CPP will not work.

  
  [Regression Potential] 

  * No regression potential advised, small (0.001%) load average increase
  on startup time because of enabling Cpp.

  [Solution]

  Backport default wily session to older releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+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 1403955] Re: DHCP's Option interface-mtu 9000 is being ignored on bridge interface br0

[Jorge Niedbalski]

The fix should check if the phys interface MTU  lxc-default-mtu, then
enforce the MTU on the phys interface or apply the 'post-up /sbin/ip
link set eth0 mtu 9000', entry on the juju-br0 config.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1403955

Title:
  DHCP's Option interface-mtu 9000 is being ignored on bridge
  interface br0

Status in juju-core:
  Triaged
Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  In an env with jumbo frames enabled, and using MAAS as DHCP server,
  the client receives the following IPv4 lease:

  $ cat /var/lib/dhcp/dhclient.br0.leases
  lease {
    interface br0;
    fixed-address 10.230.20.26;
    filename pxelinux.0;
    option subnet-mask 255.255.248.0;
    option dhcp-lease-time 43200;
    option routers 10.230.16.1;
    option dhcp-message-type 5;
    option dhcp-server-identifier 10.230.20.1;
    option domain-name-servers 10.230.20.1;
    option interface-mtu 9000;
    option broadcast-address 10.230.23.255;
    option domain-name ctsstack.qa.1ss;
    renew 3 2014/12/17 16:48:15;
    rebind 3 2014/12/17 21:52:09;
    expire 3 2014/12/17 23:22:09;
  }

  The interfaces show the following config after boot:

  $ ifconfig br0
  br0   Link encap:Ethernet  HWaddr a0:d3:c1:01:9d:58
    inet addr:10.230.20.26  Bcast:10.230.23.255  Mask:255.255.248.0
    inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    RX packets:530530 errors:0 dropped:0 overruns:0 frame:0
    TX packets:1591569 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:0
    RX bytes:68713489 (68.7 MB)  TX bytes:213710979 (213.7 MB)

  $ ifconfig eth0
  eth0  Link encap:Ethernet  HWaddr a0:d3:c1:01:9d:58
    inet6 addr: fe80::a2d3:c1ff:fe01:9d58/64 Scope:Link
    UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
    RX packets:10539274 errors:0 dropped:3394 overruns:0 frame:454
    TX packets:2627412 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:1000
    RX bytes:2320560616 (2.3 GB)  TX bytes:3562885157 (3.5 GB)
    Interrupt:32

  
  option interface-mtu 9000; from the lease file is being ignored by br0. 
Could it be related to eth0 MTU size? If that's the case, shouldn't both 
interfaces be updated?

  Other info:

  $ brctl show br0
  bridge name   bridge id   STP enabled interfaces
  br0   8000.a0d3c1019d58   no  eth0

  $ cat /etc/network/eth0.config
  iface eth0 inet manual

  auto br0
  iface br0 inet dhcp
    bridge_ports eth0

To manage notifications about this bug go to:
https://bugs.launchpad.net/juju-core/+bug/1403955/+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 1244578] Re: lightdm-session runs xrdb with -nocpp option

[Jorge Niedbalski]

** Patch added: Precise Patch
   
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+attachment/4415201/+files/fix-lp-1244578-precise.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1244578

Title:
  lightdm-session runs xrdb with -nocpp option

Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Trusty:
  In Progress
Status in lightdm source package in Utopic:
  In Progress
Status in lightdm source package in Vivid:
  In Progress

Bug description:
  [Impact]

  lightdm-session runs xrdb for .Xresources file with the -nocpp option
  (Line 37 and 43), which prevents the xrdb from preprocessing the
  .Xresources file. Many configurations like the popular solarized color
  theme (https://github.com/solarized/xresources/blob/master/solarized)
  use this and you find some complaints about in on the internet

  https://bbs.archlinux.org/viewtopic.php?id=164108
  https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1163129
  
http://superuser.com/questions/655857/urxvt-uses-pink-instead-of-solarized-until-i-run-xrdb-xresources/656213

  I don't see a reason for not using the preprocessor and so did the
  editor of Xsession (the option is not used in
  /etc/X11/Xsession.d/30x11-common_xresources)

  [Test Case]

   - Install solarized theme
  https://github.com/solarized/xresources/blob/master/solarized

  - Load default Xresources file (xrdb  .XDefaults )

  - Now every macro supported by CPP will not work.

  
  [Regression Potential] 

  * No regression potential advised, small (0.001%) load average increase
  on startup time because of enabling Cpp.

  [Solution]

  Backport default wily session to older releases.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1244578/+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 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode

[Jorge Niedbalski]

Attached patch for precise.

** Patch added: patch for precise
   
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+attachment/4399572/+files/lp1006898-set-so-bindtodevice-on-dhcp.patch

** Patch removed: lp1006898-set-so-bindtodevice-on-dhcp.patch
   
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+attachment/4363091/+files/lp1006898-set-so-bindtodevice-on-dhcp.patch

** Changed in: dnsmasq (Ubuntu Precise)
 Assignee: Chuck Short (zulcss) = Jorge Niedbalski (niedbalski)

** Changed in: dnsmasq (Ubuntu Precise)
   Status: Triaged = In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1006898

Title:
  [SRU] dnsmasq fails at leasing issues when using vlan mode

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Precise:
  In Progress

Bug description:
  ** Issue **

  There is an issue with the way nova uses dnsmasq in VLAN mode. It starts
  up a single copy of dnsmasq for each vlan on the network host (or on
  every host in multi_host mode). The problem is in the way that dnsmasq
  binds to an ip address and port[2]. Both copies can respond to broadcast
  packet, but unicast packets can only be answered by one of the copies.

  In nova this means that guests from only one project will get responses
  to their unicast dhcp renew requests. Unicast projects from guests in
  other projects get ignored. What happens next is different depending on
  the guest os. Linux generally will send a broadcast packet out after
  the unicast fails, and so the only effect is a small (tens of ms) hiccup
  while interface is reconfigured. It can be much worse than that,
  however. I have seen cases where Windows just gives up and ends up with
  a non-configured interface.

  This bug was first noticed by some users of openstack who rolled their
  own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket
  option, it will allow different daemons to share the port and respond to
  unicast packets, as long as they listen on different interfaces. I
  managed to communicate with Simon Kelley, the maintainer of dnsmasq and
  he has integrated a fix[3] for the issue in the current version[1] of
  dnsmaq.

  [3]
  
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12

  ** Development Fix **

  This has been fixed in quantal with the newer version of dnmasq.

  ** Stable Fix **

  I have backported the patch which fixes this issue, I have attached
  the debdiff and the buildlog.

  ** Test Case **

  1. Install openstack with vlan mode.
  2. Watch instances loose their IP addresses.

  ** Regression Potential **

  Minimal, most installations dont use this type of networking.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+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 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode

[Jorge Niedbalski]

@arges,

I re-uploaded the patch, rebasing with current -updates and fixing the
issue you detected. Please sponsor.

Thanks.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1006898

Title:
  [SRU] dnsmasq fails at leasing issues when using vlan mode

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Precise:
  In Progress

Bug description:
  ** Issue **

  There is an issue with the way nova uses dnsmasq in VLAN mode. It starts
  up a single copy of dnsmasq for each vlan on the network host (or on
  every host in multi_host mode). The problem is in the way that dnsmasq
  binds to an ip address and port[2]. Both copies can respond to broadcast
  packet, but unicast packets can only be answered by one of the copies.

  In nova this means that guests from only one project will get responses
  to their unicast dhcp renew requests. Unicast projects from guests in
  other projects get ignored. What happens next is different depending on
  the guest os. Linux generally will send a broadcast packet out after
  the unicast fails, and so the only effect is a small (tens of ms) hiccup
  while interface is reconfigured. It can be much worse than that,
  however. I have seen cases where Windows just gives up and ends up with
  a non-configured interface.

  This bug was first noticed by some users of openstack who rolled their
  own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket
  option, it will allow different daemons to share the port and respond to
  unicast packets, as long as they listen on different interfaces. I
  managed to communicate with Simon Kelley, the maintainer of dnsmasq and
  he has integrated a fix[3] for the issue in the current version[1] of
  dnsmaq.

  [3]
  
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12

  ** Development Fix **

  This has been fixed in quantal with the newer version of dnmasq.

  ** Stable Fix **

  I have backported the patch which fixes this issue, I have attached
  the debdiff and the buildlog.

  ** Test Case **

  1. Install openstack with vlan mode.
  2. Watch instances loose their IP addresses.

  ** Regression Potential **

  Minimal, most installations dont use this type of networking.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+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 1006898] Re: [SRU] dnsmasq fails at leasing issues when using vlan mode

[Jorge Niedbalski]

The attached patch, applies upstream
9380ba70d67db6b69f817d8e318de5ba1e990b12 into precise.

** Patch added: lp1006898-set-so-bindtodevice-on-dhcp.patch
   
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+attachment/4363091/+files/lp1006898-set-so-bindtodevice-on-dhcp.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1006898

Title:
  [SRU] dnsmasq fails at leasing issues when using vlan mode

Status in dnsmasq package in Ubuntu:
  Fix Released
Status in dnsmasq source package in Precise:
  Triaged

Bug description:
  ** Issue **

  There is an issue with the way nova uses dnsmasq in VLAN mode. It starts
  up a single copy of dnsmasq for each vlan on the network host (or on
  every host in multi_host mode). The problem is in the way that dnsmasq
  binds to an ip address and port[2]. Both copies can respond to broadcast
  packet, but unicast packets can only be answered by one of the copies.

  In nova this means that guests from only one project will get responses
  to their unicast dhcp renew requests. Unicast projects from guests in
  other projects get ignored. What happens next is different depending on
  the guest os. Linux generally will send a broadcast packet out after
  the unicast fails, and so the only effect is a small (tens of ms) hiccup
  while interface is reconfigured. It can be much worse than that,
  however. I have seen cases where Windows just gives up and ends up with
  a non-configured interface.

  This bug was first noticed by some users of openstack who rolled their
  own fix. Basically, on linux, if you set the SO_BINDTODEVICE socket
  option, it will allow different daemons to share the port and respond to
  unicast packets, as long as they listen on different interfaces. I
  managed to communicate with Simon Kelley, the maintainer of dnsmasq and
  he has integrated a fix[3] for the issue in the current version[1] of
  dnsmaq.

  [3]
  
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commitdiff;h=9380ba70d67db6b69f817d8e318de5ba1e990b12

  ** Development Fix **

  This has been fixed in quantal with the newer version of dnmasq.

  ** Stable Fix **

  I have backported the patch which fixes this issue, I have attached
  the debdiff and the buildlog.

  ** Test Case **

  1. Install openstack with vlan mode.
  2. Watch instances loose their IP addresses.

  ** Regression Potential **

  Minimal, most installations dont use this type of networking.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1006898/+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 1382054] [NEW] Add support for configuring VLAN interfaces in the initrd

[Jorge Niedbalski]

Public bug reported:

It would be helpful to be able to create VLAN network interfaces in initrd 
images provided
by Ubuntu, based on kernel command line parameters. (i.e. VLAN=eth0.100, )

Some use cases for this feature addition are MAAS users trying to boot machines
using a specific VLAN interface.

On a specific case we have 2 physical network interfaces, one is plugged into a 
specific VLAN interface,
Since we can specify the network interface on BIOS, the initial PXE boot 
occurs, but
then the installation fails when using the fast-path installer because the 
specific VLAN is not configured on the ram disk.

While we can use the other network interface because is a trunk interface that 
allows us to use
several VLANs, this is not supported on all the network architectures and some 
security limitations doesn't allows this method.

Reference Redhat implementation can be found here:

- http://marc.info/?l=initramfsm=133767307516594

Reference Suse implementation can be found here:

- https://gitorious.org/opensuse/agrafs-
mkinitrd/commit/6124f87f3132b6369c0335c319832619a49d0bf7

The command line syntax for this could be something like, similar to
Redhat implementation

vlan=vlanname:phydevice

For an example:

vlan=eth0.2:eth0

** Affects: initramfs-tools (Ubuntu)
 Importance: Undecided
 Status: Confirmed


** Tags: cts

** Changed in: initramfs-tools (Ubuntu)
   Status: New = Confirmed

** Description changed:

  It would be helpful to be able to create VLAN network interfaces in initrd 
images provided
- by Ubuntu,  based on kernel command line parameters. (i.e. VLAN=eth0.100, )
+ by Ubuntu, based on kernel command line parameters. (i.e. VLAN=eth0.100, )
  
  Some use cases for this feature addition are MAAS users trying to boot 
machines
- using a specific VLAN interface. 
+ using a specific VLAN interface.
  
- On a specific case we have 2 physical network interfaces, one is plugged into 
a specific VLAN interface, 
+ On a specific case we have 2 physical network interfaces, one is plugged into 
a specific VLAN interface,
  Since we can specify the network interface on BIOS, the initial PXE boot 
occurs, but
- then the installation fails when using the fast-path installer because the 
specific VLAN is not configured on the ram disk. 
+ then the installation fails when using the fast-path installer because the 
specific VLAN is not configured on the ram disk.
  
  While we can use the other network interface because is a trunk interface 
that allows us to use
  several VLANs, this is not supported on all the network architectures and 
some security limitations doesn't allows this method.
  
- Reference Redhat implementation could be found here:
+ Reference Redhat implementation can be found here:
  
  - http://marc.info/?l=initramfsm=133767307516594
  
- Reference Suse implementation could be found here:
+ Reference Suse implementation can be found here:
  
  - https://gitorious.org/opensuse/agrafs-
  mkinitrd/commit/6124f87f3132b6369c0335c319832619a49d0bf7
  
- 
- The command line syntax for this could be something like, similar to Redhat 
implementation
+ The command line syntax for this could be something like, similar to
+ Redhat implementation
  
  vlan=vlanname:phydevice
  
  For an example:
  
  vlan=eth0.2:eth0

** Tags added: cts

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1382054

Title:
  Add support for configuring VLAN interfaces in the initrd

Status in “initramfs-tools” package in Ubuntu:
  Confirmed

Bug description:
  It would be helpful to be able to create VLAN network interfaces in initrd 
images provided
  by Ubuntu, based on kernel command line parameters. (i.e. VLAN=eth0.100, )

  Some use cases for this feature addition are MAAS users trying to boot 
machines
  using a specific VLAN interface.

  On a specific case we have 2 physical network interfaces, one is plugged into 
a specific VLAN interface,
  Since we can specify the network interface on BIOS, the initial PXE boot 
occurs, but
  then the installation fails when using the fast-path installer because the 
specific VLAN is not configured on the ram disk.

  While we can use the other network interface because is a trunk interface 
that allows us to use
  several VLANs, this is not supported on all the network architectures and 
some security limitations doesn't allows this method.

  Reference Redhat implementation can be found here:

  - http://marc.info/?l=initramfsm=133767307516594

  Reference Suse implementation can be found here:

  - https://gitorious.org/opensuse/agrafs-
  mkinitrd/commit/6124f87f3132b6369c0335c319832619a49d0bf7

  The command line syntax for this could be something like, similar to
  Redhat implementation

  vlan=vlanname:phydevice

  For an example:

  vlan=eth0.2:eth0

To manage notifications 

[Touch-packages] [Bug 1257082] Re: MAAS does not use NTP servers specified in DHCPD options

[Jorge Niedbalski]

** Tags added: cts

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/1257082

Title:
  MAAS does not use NTP servers specified in DHCPD options

Status in MAAS:
  Invalid
Status in “isc-dhcp” package in Ubuntu:
  Invalid
Status in “ntp” package in Ubuntu:
  Confirmed
Status in “isc-dhcp” source package in Precise:
  New
Status in “ntp” source package in Precise:
  In Progress
Status in “isc-dhcp” source package in Trusty:
  New
Status in “ntp” source package in Trusty:
  In Progress
Status in “ntp” package in Debian:
  New

Bug description:
  [Impact]

  MAAS-deployed systems *that do not have persistent RTCs* (unusual)
  have difficulty with time and authentication, generally making these
  nodes unusable.

  [Workaround]

  See comment #8.

  [Original Description]

  I have tried setting up NTP servers as DHCP options to MAAS nodes
  because I am behind a proxy here at work that cannot contact
  ntp.ubuntu.com. Here is the top of the dhcpd.conf file on on my MAAS
  head node, maas01:

  root@maas01:/etc/dhcp# less dhcpd.conf
  default-lease-time 600;
  max-lease-time 7200;

  subnet 192.168.0.0 netmask 255.255.0.0 {
    option domain-name mgmt;
    option domain-name-servers 192.168.255.254;
    option routers 192.168.255.254;

    pool {
  range 192.168.0.1 192.168.255.253;
  deny unknown-clients;
    }
  }

  subnet 10.255.0.0 netmask 255.255.0.0 {
    option domain-name maas;
    option domain-name-servers 10.255.0.1;
    option routers 10.255.0.1;
    option ntp-servers 172.31.22.1, 172.31.23.1, 172.31.20.104;
    next-server 10.255.0.1;

    pool {
  range 10.255.1.0 10.255.255.254;
  deny unknown-clients;
    }
  }

  I have also verified the parameter is being sent to a client’s DHCP
  lease:

  ubuntu@sled204n0:/var$ cat /var/lib/dhcp/dhclient.eth0.leases
  lease {
    interface eth0;
    fixed-address 10.255.4.44;
    option subnet-mask 255.255.0.0;
    option routers 10.255.0.1;
    option dhcp-lease-time 600;
    option dhcp-message-type 5;
    option domain-name-servers 10.255.0.1;
    option dhcp-server-identifier 10.255.0.1;
    option ntp-servers 172.31.22.1,172.31.23.1,172.31.20.104;
    option domain-name maas;
    renew 4 2000/01/06 19:40:51;
    rebind 4 2000/01/06 19:40:51;
    expire 4 2000/01/06 19:40:51;
  }

  Even so, the date on the target node is still incorrect.

  ubuntu@sled204n0:/etc$ date
  Thu Jan  6 19:52:29 UTC 2000

  The ntpdate defaults are the following (unchanged from MAAS defaults):

  ubuntu@sled204n0:/etc$ cat /etc/default/ntpdate
  # The settings in this file are used by the program ntpdate-debian, but not
  # by the upstream program ntpdate.

  # Set to yes to take the server list from /etc/ntp.conf, from package ntp,
  # so you only have to keep it in one place.
  NTPDATE_USE_NTP_CONF=yes

  # List of NTP servers to use  (Separate multiple servers with spaces.)
  # Not used if NTPDATE_USE_NTP_CONF is yes.
  NTPSERVERS=ntp.ubuntu.com

  # Additional options to pass to ntpdate
  NTPOPTIONS=

  And the DHCP generated NTP server file is correct:

  ubuntu@sled204n0:/etc$ cat /var/lib/ntpdate/default.dhcp
  # NTP server entries received from DHCP server
  NTPSERVERS='172.31.22.1 172.31.23.1 172.31.20.104'

  The culprit seems to be in how ntpdate-debian is programmed. the logic
  ignores /var/lib/ntpdate/default.dhcp if /etc/default/ntpdate sets
  NTPDATE_USE_NTP_CONF=yes (the default).

  After examining the script further my recommendation would be for the
  /etc/dhcp/dhclient-exit-hooks.d/ntpdate to create the file
  /var/lib/ntp/ntp.conf.dhcp. By doing so ntpdate-debian will work
  transparently with /etc/defaults/ntpdate and NTP servers advertised by
  DHCPD.

  -
  (contents of /var/log/maas/* is 125MB in size, will post data from there if 
requested)

  # dpkg -l '*maas*'|cat
  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  maas   1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Server
  ii  maas-cli   1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Client Tool
  ii  maas-cluster-controller1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Cluster Controller
  ii  maas-common1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Server
  un  maas-dhcp  none 

[Touch-packages] [Bug 1337873] Re: Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition

[Jorge Niedbalski]

** Tags added: cts

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1337873

Title:
  Precise, Trusty, Utopic - ifupdown initialization problems caused by
  race condition

Status in “ifupdown” package in Ubuntu:
  In Progress
Status in “ifupdown” package in Debian:
  New

Bug description:
  * please consider my bonding examples are using eth1 and eth2 as slave
   interfaces.

  ifupdown some race conditions explained bellow. ifenslave does not
  behave well with sysv networking and upstart network-interface scripts
  running together.

  
  case 1)
  (a) ifup eth0 (b) ifup -a for eth0
  -
  1-1. Lock ifstate.lock file.
1-1. Wait for locking ifstate.lock
file.
  1-2. Read ifstate file to check
   the target NIC.
  1-3. close(=release) ifstate.lock
   file.
  1-4. Judge that the target NIC
   isn't processed.
1-2. Read ifstate file to check
 the target NIC.
1-3. close(=release) ifstate.lock
 file.
1-4. Judge that the target NIC
 isn't processed.
  2. Lock and update ifstate file.
 Release the lock.
2. Lock and update ifstate file.
   Release the lock.
  !!!

  to be explained

  !!!
  case 2)
  (a) ifenslave of eth0  (b) ifenslave of eth0
  --
  3. Execute ifenslave of eth0.  3. Execute ifenslave of eth0.
  4. Link down the target NIC.
  5. Write NIC id to
 /sys/class/net/bond0/bonding
 /slaves then NIC gets up
4. Link down the target NIC.
5. Fails to write NIC id to
   /sys/class/net/bond0/bonding/
   slaves it is already written.
  !!!

  #

   My setup:

  root@provisioned:~# cat /etc/modprobe.d/bonding.conf
  alias bond0 bonding options bonding mode=1 arp_interval=2000

  Both, /etc/init.d/networking and upstart network-interface begin
  enabled.

   Beginning:

  root@provisioned:~# cat /etc/network/interfaces
  # /etc/network/interfaces

  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet dhcp

  I'm able to boot with both scripts (networking and network-interface
  enabled) with no problem. I can also boot with only networking 
  script enabled:

  ---
  root@provisioned:~# initctl list | grep network
  network-interface stop/waiting
  networking start/running
  ---

  OR only the script network-interface enabled:

  ---
  root@provisioned:~# initctl list | grep network
  network-interface (eth2) start/running
  network-interface (lo) start/running
  network-interface (eth0) start/running
  network-interface (eth1) start/running
  ---

   Enabling bonding:

  Following ifenslave configuration example (/usr/share/doc/ifenslave/
  examples/two_hotplug_ethernet), my /etc/network/interfaces has to 
  look like this:

  ---
  auto eth1
  iface eth1 inet manual
  bond-master bond0

  auto eth2
  iface eth2 inet manual
  bond-master bond0

  auto bond0
  iface bond0 inet static
  bond-mode 1
  bond-miimon 100
  bond-primary eth1 eth2
address 192.168.169.1
netmask 255.255.255.0
broadcast 192.168.169.255
  ---

  Having both scripts running does not make any difference since we
  are missing bond-slaves keyword on slave interfaces, for ifenslave
  to work, and they are set to manual.

  Ifenslave code:

  
  for slave in $BOND_SLAVES ; do
  ...
  # Ensure $slave is down.
  ip link set $slave down 2/dev/null
  if ! sysfs_add slaves $slave 2/dev/null ; then
echo Failed to enslave $slave to $BOND_MASTER. Is $BOND_MASTER 
ready and a bonding interface ? 2
  else
# Bring up slave if it is the target of an allow-bondX stanza.
# This is usefull to bring up slaves that need extra setup.
if [ -z $(which ifquery) ] || ifquery --allow \$BOND_MASTER\ 
--list | grep -q $slave; then
ifup $v --allow $BOND_MASTER $slave
fi
  

  Without the keyword bond-slaves on the master interface declaration,
  ifenslave will NOT bring any slave interface up on the master 
  interface ifup invocation. 

  *** Part 1

  So, having networking sysv init script AND upstart network-interface
  script running together... the following example works:

  ---
  root@provisioned:~# cat /etc/network/interfaces

[Touch-packages] [Bug 1257082] Re: MAAS does not use NTP servers specified in DHCPD options

[Jorge Niedbalski]

** Patch added: lp1257082_prefers_dhcp_ntp_servers_trusty.debdiff
   
https://bugs.launchpad.net/maas/+bug/1257082/+attachment/4201542/+files/lp1257082_prefers_dhcp_ntp_servers_trusty.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1257082

Title:
  MAAS does not use NTP servers specified in DHCPD options

Status in MAAS:
  Invalid
Status in “isc-dhcp” package in Ubuntu:
  Invalid
Status in “ntp” package in Ubuntu:
  Confirmed
Status in “isc-dhcp” source package in Precise:
  New
Status in “ntp” source package in Precise:
  In Progress
Status in “isc-dhcp” source package in Trusty:
  New
Status in “ntp” source package in Trusty:
  In Progress
Status in “ntp” package in Debian:
  New

Bug description:
  [Impact]

  MAAS-deployed systems *that do not have persistent RTCs* (unusual)
  have difficulty with time and authentication, generally making these
  nodes unusable.

  [Workaround]

  See comment #8.

  [Original Description]

  I have tried setting up NTP servers as DHCP options to MAAS nodes
  because I am behind a proxy here at work that cannot contact
  ntp.ubuntu.com. Here is the top of the dhcpd.conf file on on my MAAS
  head node, maas01:

  root@maas01:/etc/dhcp# less dhcpd.conf
  default-lease-time 600;
  max-lease-time 7200;

  subnet 192.168.0.0 netmask 255.255.0.0 {
    option domain-name mgmt;
    option domain-name-servers 192.168.255.254;
    option routers 192.168.255.254;

    pool {
  range 192.168.0.1 192.168.255.253;
  deny unknown-clients;
    }
  }

  subnet 10.255.0.0 netmask 255.255.0.0 {
    option domain-name maas;
    option domain-name-servers 10.255.0.1;
    option routers 10.255.0.1;
    option ntp-servers 172.31.22.1, 172.31.23.1, 172.31.20.104;
    next-server 10.255.0.1;

    pool {
  range 10.255.1.0 10.255.255.254;
  deny unknown-clients;
    }
  }

  I have also verified the parameter is being sent to a client’s DHCP
  lease:

  ubuntu@sled204n0:/var$ cat /var/lib/dhcp/dhclient.eth0.leases
  lease {
    interface eth0;
    fixed-address 10.255.4.44;
    option subnet-mask 255.255.0.0;
    option routers 10.255.0.1;
    option dhcp-lease-time 600;
    option dhcp-message-type 5;
    option domain-name-servers 10.255.0.1;
    option dhcp-server-identifier 10.255.0.1;
    option ntp-servers 172.31.22.1,172.31.23.1,172.31.20.104;
    option domain-name maas;
    renew 4 2000/01/06 19:40:51;
    rebind 4 2000/01/06 19:40:51;
    expire 4 2000/01/06 19:40:51;
  }

  Even so, the date on the target node is still incorrect.

  ubuntu@sled204n0:/etc$ date
  Thu Jan  6 19:52:29 UTC 2000

  The ntpdate defaults are the following (unchanged from MAAS defaults):

  ubuntu@sled204n0:/etc$ cat /etc/default/ntpdate
  # The settings in this file are used by the program ntpdate-debian, but not
  # by the upstream program ntpdate.

  # Set to yes to take the server list from /etc/ntp.conf, from package ntp,
  # so you only have to keep it in one place.
  NTPDATE_USE_NTP_CONF=yes

  # List of NTP servers to use  (Separate multiple servers with spaces.)
  # Not used if NTPDATE_USE_NTP_CONF is yes.
  NTPSERVERS=ntp.ubuntu.com

  # Additional options to pass to ntpdate
  NTPOPTIONS=

  And the DHCP generated NTP server file is correct:

  ubuntu@sled204n0:/etc$ cat /var/lib/ntpdate/default.dhcp
  # NTP server entries received from DHCP server
  NTPSERVERS='172.31.22.1 172.31.23.1 172.31.20.104'

  The culprit seems to be in how ntpdate-debian is programmed. the logic
  ignores /var/lib/ntpdate/default.dhcp if /etc/default/ntpdate sets
  NTPDATE_USE_NTP_CONF=yes (the default).

  After examining the script further my recommendation would be for the
  /etc/dhcp/dhclient-exit-hooks.d/ntpdate to create the file
  /var/lib/ntp/ntp.conf.dhcp. By doing so ntpdate-debian will work
  transparently with /etc/defaults/ntpdate and NTP servers advertised by
  DHCPD.

  -
  (contents of /var/log/maas/* is 125MB in size, will post data from there if 
requested)

  # dpkg -l '*maas*'|cat
  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  maas   1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Server
  ii  maas-cli   1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Client Tool
  ii  maas-cluster-controller1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Cluster Controller
  ii  

[Touch-packages] [Bug 1257082] Re: MAAS does not use NTP servers specified in DHCPD options

[Jorge Niedbalski]

** Patch added: lp1257082_prefers_dhcp_ntp_servers_precise.debdiff
   
https://bugs.launchpad.net/maas/+bug/1257082/+attachment/4201543/+files/lp1257082_prefers_dhcp_ntp_servers_precise.debdiff

** Changed in: ntp (Ubuntu Precise)
   Status: New = In Progress

** Changed in: ntp (Ubuntu Trusty)
   Status: New = In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1257082

Title:
  MAAS does not use NTP servers specified in DHCPD options

Status in MAAS:
  Invalid
Status in “isc-dhcp” package in Ubuntu:
  Invalid
Status in “ntp” package in Ubuntu:
  Confirmed
Status in “isc-dhcp” source package in Precise:
  New
Status in “ntp” source package in Precise:
  In Progress
Status in “isc-dhcp” source package in Trusty:
  New
Status in “ntp” source package in Trusty:
  In Progress
Status in “ntp” package in Debian:
  New

Bug description:
  [Impact]

  MAAS-deployed systems *that do not have persistent RTCs* (unusual)
  have difficulty with time and authentication, generally making these
  nodes unusable.

  [Workaround]

  See comment #8.

  [Original Description]

  I have tried setting up NTP servers as DHCP options to MAAS nodes
  because I am behind a proxy here at work that cannot contact
  ntp.ubuntu.com. Here is the top of the dhcpd.conf file on on my MAAS
  head node, maas01:

  root@maas01:/etc/dhcp# less dhcpd.conf
  default-lease-time 600;
  max-lease-time 7200;

  subnet 192.168.0.0 netmask 255.255.0.0 {
    option domain-name mgmt;
    option domain-name-servers 192.168.255.254;
    option routers 192.168.255.254;

    pool {
  range 192.168.0.1 192.168.255.253;
  deny unknown-clients;
    }
  }

  subnet 10.255.0.0 netmask 255.255.0.0 {
    option domain-name maas;
    option domain-name-servers 10.255.0.1;
    option routers 10.255.0.1;
    option ntp-servers 172.31.22.1, 172.31.23.1, 172.31.20.104;
    next-server 10.255.0.1;

    pool {
  range 10.255.1.0 10.255.255.254;
  deny unknown-clients;
    }
  }

  I have also verified the parameter is being sent to a client’s DHCP
  lease:

  ubuntu@sled204n0:/var$ cat /var/lib/dhcp/dhclient.eth0.leases
  lease {
    interface eth0;
    fixed-address 10.255.4.44;
    option subnet-mask 255.255.0.0;
    option routers 10.255.0.1;
    option dhcp-lease-time 600;
    option dhcp-message-type 5;
    option domain-name-servers 10.255.0.1;
    option dhcp-server-identifier 10.255.0.1;
    option ntp-servers 172.31.22.1,172.31.23.1,172.31.20.104;
    option domain-name maas;
    renew 4 2000/01/06 19:40:51;
    rebind 4 2000/01/06 19:40:51;
    expire 4 2000/01/06 19:40:51;
  }

  Even so, the date on the target node is still incorrect.

  ubuntu@sled204n0:/etc$ date
  Thu Jan  6 19:52:29 UTC 2000

  The ntpdate defaults are the following (unchanged from MAAS defaults):

  ubuntu@sled204n0:/etc$ cat /etc/default/ntpdate
  # The settings in this file are used by the program ntpdate-debian, but not
  # by the upstream program ntpdate.

  # Set to yes to take the server list from /etc/ntp.conf, from package ntp,
  # so you only have to keep it in one place.
  NTPDATE_USE_NTP_CONF=yes

  # List of NTP servers to use  (Separate multiple servers with spaces.)
  # Not used if NTPDATE_USE_NTP_CONF is yes.
  NTPSERVERS=ntp.ubuntu.com

  # Additional options to pass to ntpdate
  NTPOPTIONS=

  And the DHCP generated NTP server file is correct:

  ubuntu@sled204n0:/etc$ cat /var/lib/ntpdate/default.dhcp
  # NTP server entries received from DHCP server
  NTPSERVERS='172.31.22.1 172.31.23.1 172.31.20.104'

  The culprit seems to be in how ntpdate-debian is programmed. the logic
  ignores /var/lib/ntpdate/default.dhcp if /etc/default/ntpdate sets
  NTPDATE_USE_NTP_CONF=yes (the default).

  After examining the script further my recommendation would be for the
  /etc/dhcp/dhclient-exit-hooks.d/ntpdate to create the file
  /var/lib/ntp/ntp.conf.dhcp. By doing so ntpdate-debian will work
  transparently with /etc/defaults/ntpdate and NTP servers advertised by
  DHCPD.

  -
  (contents of /var/log/maas/* is 125MB in size, will post data from there if 
requested)

  # dpkg -l '*maas*'|cat
  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  maas   1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Server
  ii  maas-cli   1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS 

[Touch-packages] [Bug 1257082] Re: MAAS does not use NTP servers specified in DHCPD options

[Jorge Niedbalski]

Hello,

Since there is no consensus on the definitive solution , I am proposing
a simple fix for prefers dhcp provided NTP servers if one is found as
also @elmo pointed here.

Please review the test-case and description for further details.


** Description changed:

  [Impact]
  
  MAAS-deployed systems *that do not have persistent RTCs* (unusual) have
  difficulty with time and authentication, generally making these nodes
  unusable.
  
  [Workaround]
  
  See comment #8.
  
  [Original Description]
  
  I have tried setting up NTP servers as DHCP options to MAAS nodes
  because I am behind a proxy here at work that cannot contact
  ntp.ubuntu.com. Here is the top of the dhcpd.conf file on on my MAAS
  head node, maas01:
  
  root@maas01:/etc/dhcp# less dhcpd.conf
  default-lease-time 600;
  max-lease-time 7200;
  
  subnet 192.168.0.0 netmask 255.255.0.0 {
    option domain-name mgmt;
    option domain-name-servers 192.168.255.254;
    option routers 192.168.255.254;
  
    pool {
  range 192.168.0.1 192.168.255.253;
  deny unknown-clients;
    }
  }
  
  subnet 10.255.0.0 netmask 255.255.0.0 {
    option domain-name maas;
    option domain-name-servers 10.255.0.1;
    option routers 10.255.0.1;
    option ntp-servers 172.31.22.1, 172.31.23.1, 172.31.20.104;
    next-server 10.255.0.1;
  
    pool {
  range 10.255.1.0 10.255.255.254;
  deny unknown-clients;
    }
  }
  
  I have also verified the parameter is being sent to a client’s DHCP
  lease:
  
  ubuntu@sled204n0:/var$ cat /var/lib/dhcp/dhclient.eth0.leases
  lease {
    interface eth0;
    fixed-address 10.255.4.44;
    option subnet-mask 255.255.0.0;
    option routers 10.255.0.1;
    option dhcp-lease-time 600;
    option dhcp-message-type 5;
    option domain-name-servers 10.255.0.1;
    option dhcp-server-identifier 10.255.0.1;
    option ntp-servers 172.31.22.1,172.31.23.1,172.31.20.104;
    option domain-name maas;
    renew 4 2000/01/06 19:40:51;
    rebind 4 2000/01/06 19:40:51;
    expire 4 2000/01/06 19:40:51;
  }
  
  Even so, the date on the target node is still incorrect.
  
  ubuntu@sled204n0:/etc$ date
  Thu Jan  6 19:52:29 UTC 2000
  
  The ntpdate defaults are the following (unchanged from MAAS defaults):
  
  ubuntu@sled204n0:/etc$ cat /etc/default/ntpdate
  # The settings in this file are used by the program ntpdate-debian, but not
  # by the upstream program ntpdate.
  
  # Set to yes to take the server list from /etc/ntp.conf, from package ntp,
  # so you only have to keep it in one place.
  NTPDATE_USE_NTP_CONF=yes
  
  # List of NTP servers to use  (Separate multiple servers with spaces.)
  # Not used if NTPDATE_USE_NTP_CONF is yes.
  NTPSERVERS=ntp.ubuntu.com
  
  # Additional options to pass to ntpdate
  NTPOPTIONS=
  
  And the DHCP generated NTP server file is correct:
  
  ubuntu@sled204n0:/etc$ cat /var/lib/ntpdate/default.dhcp
  # NTP server entries received from DHCP server
  NTPSERVERS='172.31.22.1 172.31.23.1 172.31.20.104'
  
  The culprit seems to be in how ntpdate-debian is programmed. the logic
  ignores /var/lib/ntpdate/default.dhcp if /etc/default/ntpdate sets
  NTPDATE_USE_NTP_CONF=yes (the default).
  
  After examining the script further my recommendation would be for the
  /etc/dhcp/dhclient-exit-hooks.d/ntpdate to create the file
  /var/lib/ntp/ntp.conf.dhcp. By doing so ntpdate-debian will work
  transparently with /etc/defaults/ntpdate and NTP servers advertised by
  DHCPD.
  
  -
  (contents of /var/log/maas/* is 125MB in size, will post data from there if 
requested)
  
  # dpkg -l '*maas*'|cat
  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  maas   1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Server
  ii  maas-cli   1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Client Tool
  ii  maas-cluster-controller1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Cluster Controller
  ii  maas-common1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Server
  un  maas-dhcp  none 
 (no description available)
  un  maas-dns   none 
 (no description available)
  ii  maas-region-controller 1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Server
  ii  python-django-maas 

[Touch-packages] [Bug 1257082] Re: MAAS does not use NTP servers specified in DHCPD options

[Jorge Niedbalski]

** Patch added: lp1257082_prefers_dhcp_ntp_servers_utopic.debdiff
   
https://bugs.launchpad.net/maas/+bug/1257082/+attachment/4201541/+files/lp1257082_prefers_dhcp_ntp_servers_utopic.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/1257082

Title:
  MAAS does not use NTP servers specified in DHCPD options

Status in MAAS:
  Invalid
Status in “isc-dhcp” package in Ubuntu:
  Invalid
Status in “ntp” package in Ubuntu:
  Confirmed
Status in “isc-dhcp” source package in Precise:
  New
Status in “ntp” source package in Precise:
  In Progress
Status in “isc-dhcp” source package in Trusty:
  New
Status in “ntp” source package in Trusty:
  In Progress
Status in “ntp” package in Debian:
  New

Bug description:
  [Impact]

  MAAS-deployed systems *that do not have persistent RTCs* (unusual)
  have difficulty with time and authentication, generally making these
  nodes unusable.

  [Workaround]

  See comment #8.

  [Original Description]

  I have tried setting up NTP servers as DHCP options to MAAS nodes
  because I am behind a proxy here at work that cannot contact
  ntp.ubuntu.com. Here is the top of the dhcpd.conf file on on my MAAS
  head node, maas01:

  root@maas01:/etc/dhcp# less dhcpd.conf
  default-lease-time 600;
  max-lease-time 7200;

  subnet 192.168.0.0 netmask 255.255.0.0 {
    option domain-name mgmt;
    option domain-name-servers 192.168.255.254;
    option routers 192.168.255.254;

    pool {
  range 192.168.0.1 192.168.255.253;
  deny unknown-clients;
    }
  }

  subnet 10.255.0.0 netmask 255.255.0.0 {
    option domain-name maas;
    option domain-name-servers 10.255.0.1;
    option routers 10.255.0.1;
    option ntp-servers 172.31.22.1, 172.31.23.1, 172.31.20.104;
    next-server 10.255.0.1;

    pool {
  range 10.255.1.0 10.255.255.254;
  deny unknown-clients;
    }
  }

  I have also verified the parameter is being sent to a client’s DHCP
  lease:

  ubuntu@sled204n0:/var$ cat /var/lib/dhcp/dhclient.eth0.leases
  lease {
    interface eth0;
    fixed-address 10.255.4.44;
    option subnet-mask 255.255.0.0;
    option routers 10.255.0.1;
    option dhcp-lease-time 600;
    option dhcp-message-type 5;
    option domain-name-servers 10.255.0.1;
    option dhcp-server-identifier 10.255.0.1;
    option ntp-servers 172.31.22.1,172.31.23.1,172.31.20.104;
    option domain-name maas;
    renew 4 2000/01/06 19:40:51;
    rebind 4 2000/01/06 19:40:51;
    expire 4 2000/01/06 19:40:51;
  }

  Even so, the date on the target node is still incorrect.

  ubuntu@sled204n0:/etc$ date
  Thu Jan  6 19:52:29 UTC 2000

  The ntpdate defaults are the following (unchanged from MAAS defaults):

  ubuntu@sled204n0:/etc$ cat /etc/default/ntpdate
  # The settings in this file are used by the program ntpdate-debian, but not
  # by the upstream program ntpdate.

  # Set to yes to take the server list from /etc/ntp.conf, from package ntp,
  # so you only have to keep it in one place.
  NTPDATE_USE_NTP_CONF=yes

  # List of NTP servers to use  (Separate multiple servers with spaces.)
  # Not used if NTPDATE_USE_NTP_CONF is yes.
  NTPSERVERS=ntp.ubuntu.com

  # Additional options to pass to ntpdate
  NTPOPTIONS=

  And the DHCP generated NTP server file is correct:

  ubuntu@sled204n0:/etc$ cat /var/lib/ntpdate/default.dhcp
  # NTP server entries received from DHCP server
  NTPSERVERS='172.31.22.1 172.31.23.1 172.31.20.104'

  The culprit seems to be in how ntpdate-debian is programmed. the logic
  ignores /var/lib/ntpdate/default.dhcp if /etc/default/ntpdate sets
  NTPDATE_USE_NTP_CONF=yes (the default).

  After examining the script further my recommendation would be for the
  /etc/dhcp/dhclient-exit-hooks.d/ntpdate to create the file
  /var/lib/ntp/ntp.conf.dhcp. By doing so ntpdate-debian will work
  transparently with /etc/defaults/ntpdate and NTP servers advertised by
  DHCPD.

  -
  (contents of /var/log/maas/* is 125MB in size, will post data from there if 
requested)

  # dpkg -l '*maas*'|cat
  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  maas   1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Server
  ii  maas-cli   1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Client Tool
  ii  maas-cluster-controller1.3+bzr1461+dfsg-0ubuntu2.2+tay.8  
all  Ubuntu MAAS Cluster Controller
  ii  

[Touch-packages] [Bug 427775] Re: ntpdate.dhcp always ignored

[Jorge Niedbalski]

For MAAS users. A quick workaround that you can use for this, is to
setting NTPDATE_USE_NTP_CONF to NO via the generic preseed file.

Edit /etc/maas/preseeds/generic, add a late_command into the file

d-i preseed/late_command string true  \
in-target sed -i 's/NTPDATE_USE_NTP_CONF=yes/NTPDATE_USE_NTP_CONF=no/'
/etc/default/ntpdate

This change will force the usage of /var/lib/ntpdate/default.dhcp ,
which is being written correctly by MAAS.

The proper solution for this fix would be to fix the ntpdate package to
fall back to /etc/default/ntpdate.dhcp if it doesn't find any ntp.conf
configuration by default.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ntp in Ubuntu.
https://bugs.launchpad.net/bugs/427775

Title:
  ntpdate.dhcp always ignored

Status in “ntp” package in Ubuntu:
  Triaged

Bug description:
  Ubuntu 9.04, affects the ntpdate binary package

  Problem: Using dhcp a file ntpdate.dhcp is created but never used.

  By default NTPDATE_USE_NTP_CONF in /etc/default/ntpdate is set to
  yes. This has the following consequences:

  /usr/sbin/ntpdate-debian parses /etc/default/ntpdate and checks for
  /etc/ntp.conf.dhcp /etc/ntp.conf /etc/openntpd/ntpd.conf if
  NTPDATE_USE_NTP_CONF is set to yes.  By default ntpd is not installed
  therefore there is no  /etc/ntp.conf.dhcp /etc/ntp.conf or
  /etc/openntpd/ntpd.conf. ntpdate-debian then defaults to the
  NTPSERVERS set in /etc/default/ntpdate, namely ntp.ubuntu.com. Only
  if NTPDATE_USE_NTP_CONF is set to no there will be a check for
  /etc/default/ntpdate.dhcp and consequently the server supplied by dhcp
  be used.

  I propose to set NTPDATE_USE_NTP_CONF to no by default. If ntpd is
  installed, this will override the use of ntpdate and
  /etc/ntpd.conf.dhcp and /etc/default/ntpdate.dhcp will both be created
  by DHCP anyway, therefore both packages will use the DHCP supplied
  servers in any case.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/427775/+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