[Touch-packages] [Bug 1920047] Re: sanlock global lock creation fail

2021-05-24 Thread Heitor Alves de Siqueira
** Changed in: lvm2 (Ubuntu)
 Assignee: (unassigned) => Heitor Alves de Siqueira (halves)

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

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

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

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

** Changed in: lvm2 (Ubuntu Focal)
   Status: New => Confirmed

** Changed in: lvm2 (Ubuntu Groovy)
   Status: New => Confirmed

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

** Changed in: lvm2 (Ubuntu Focal)
 Assignee: (unassigned) => Heitor Alves de Siqueira (halves)

** Changed in: lvm2 (Ubuntu Groovy)
 Assignee: (unassigned) => Heitor Alves de Siqueira (halves)

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

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

Title:
  sanlock global lock creation fail

Status in lvm2 package in Ubuntu:
  Fix Released
Status in lvm2 source package in Focal:
  Confirmed
Status in lvm2 source package in Groovy:
  Confirmed

Bug description:
  Hello,

  Running Ubuntu server 20.04, I cannot create a shared VG using sanlock
  :

  # vgcreate --shared foo /dev/mapper/vol
Enabling sanlock global lock
Skipping global lock: lockspace not found or started
Logical volume "lvmlock" created.
VG foo init failed: -28
Failed to initialize lock args for lock type sanlock
Volume group "foo" successfully removed

  Messages in /var/log/syslog

  lvmlockd[446807]: 1616089866 WARNING: mixed block sizes physical 4096 logical 
512 (using 4096) for /dev/mapper/foo-lvmlock
  lvmlockd[446807]: 1616089866 S lvm_foo init_vg_san write_resource gl error 
-28 /dev/mapper/foo-lvmlock

  # lsb_release -rd
  Description:Ubuntu 20.04.2 LTS
  Release:20.04

  # dpkg -l | grep lvm
  ii  liblvm2cmd2.03:amd64 2.03.07-1ubuntu1 
 amd64LVM2 command library
  ii  lvm2 2.03.07-1ubuntu1 
 amd64Linux Logical Volume Manager
  ii  lvm2-lockd   2.03.07-1ubuntu1 
 amd64LVM locking daemon

  A similar bug report from RHEL8 :
  https://bugzilla.redhat.com/show_bug.cgi?id=1833837

  Bug has been fixed upstream :
  
https://sourceware.org/git/?p=lvm2.git;a=commit;h=2d1fe38d84d499011d13ae1ea11535398528fc87

  It seems to be included in version 2.03.10 :
  https://sourceware.org/git/?p=lvm2.git;a=shortlog;h=refs/tags/v2_03_10

  How can we get this patch included in Ubuntu 20.04 ?

  King Regards,

  Charles

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1920047/+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 1920047] Re: sanlock global lock creation fail

2021-04-13 Thread Heitor Alves de Siqueira
** Tags added: sts

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

Title:
  sanlock global lock creation fail

Status in lvm2 package in Ubuntu:
  New

Bug description:
  Hello,

  Running Ubuntu server 20.04, I cannot create a shared VG using sanlock
  :

  # vgcreate --shared foo /dev/mapper/vol
Enabling sanlock global lock
Skipping global lock: lockspace not found or started
Logical volume "lvmlock" created.
VG foo init failed: -28
Failed to initialize lock args for lock type sanlock
Volume group "foo" successfully removed

  Messages in /var/log/syslog

  lvmlockd[446807]: 1616089866 WARNING: mixed block sizes physical 4096 logical 
512 (using 4096) for /dev/mapper/foo-lvmlock
  lvmlockd[446807]: 1616089866 S lvm_foo init_vg_san write_resource gl error 
-28 /dev/mapper/foo-lvmlock

  # lsb_release -rd
  Description:Ubuntu 20.04.2 LTS
  Release:20.04

  # dpkg -l | grep lvm
  ii  liblvm2cmd2.03:amd64 2.03.07-1ubuntu1 
 amd64LVM2 command library
  ii  lvm2 2.03.07-1ubuntu1 
 amd64Linux Logical Volume Manager
  ii  lvm2-lockd   2.03.07-1ubuntu1 
 amd64LVM locking daemon

  A similar bug report from RHEL8 :
  https://bugzilla.redhat.com/show_bug.cgi?id=1833837

  Bug has been fixed upstream :
  
https://sourceware.org/git/?p=lvm2.git;a=commit;h=2d1fe38d84d499011d13ae1ea11535398528fc87

  It seems to be included in version 2.03.10 :
  https://sourceware.org/git/?p=lvm2.git;a=shortlog;h=refs/tags/v2_03_10

  How can we get this patch included in Ubuntu 20.04 ?

  King Regards,

  Charles

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1920047/+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 1825186] Re: gpgv-win32 autopkgtest always fails

2021-02-22 Thread Heitor Alves de Siqueira
Autopkgtest failures for gnupg2 on armhf have been fixed with a re-run,
so it was likely due to a flaky testbed setup.

Failures for libgnupg-interface-perl are the result of the upstream test
suite and very unlikely to be related to this SRU. I've opened bug
1916499 to investigate those separately.

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

Title:
  gpgv-win32 autopkgtest always fails

Status in gnupg package in Ubuntu:
  Invalid
Status in gnupg2 package in Ubuntu:
  Fix Released
Status in gnupg source package in Xenial:
  Won't Fix
Status in gnupg2 source package in Bionic:
  Fix Committed
Status in gnupg2 source package in Cosmic:
  Won't Fix
Status in gnupg2 source package in Disco:
  Fix Released

Bug description:
  [impact]

  gpgv-win32 autopkgtest always fails

  [test case]

  check http://autopkgtest.ubuntu.com/packages/g/gnupg2

  or run autopkgtest manually

  note the gpgv-win32 test is skipped on ppc64el and s390x for b/c, and
  has been removed from d/t/control entirely in d

  [regression potential]

  little to none; this affects the test case only

  [other info]

  as mentioned, in disco, the gpgv-win32 test has been removed from the
  tests/control completely.  not sure if that is a better approach than
  fixing the test case.  For now, I marked this Fix Released for disco
  since it doesn't fail there (since the testcase was removed).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1825186/+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 1825186] Re: gpgv-win32 autopkgtest always fails

2021-02-19 Thread Heitor Alves de Siqueira
I can see autopkgtest completing successfully for most archs on
http://autopkgtest.ubuntu.com/packages/g/gnupg2 for the new Bionic
release, so I'll mark this as verified.

I'm still looking into the regressions for armhf and for libgnupg-
interface-perl, but the latter seems to have been broken since 2018.

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

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

Title:
  gpgv-win32 autopkgtest always fails

Status in gnupg package in Ubuntu:
  Invalid
Status in gnupg2 package in Ubuntu:
  Fix Released
Status in gnupg source package in Xenial:
  Won't Fix
Status in gnupg2 source package in Bionic:
  Fix Committed
Status in gnupg2 source package in Cosmic:
  Won't Fix
Status in gnupg2 source package in Disco:
  Fix Released

Bug description:
  [impact]

  gpgv-win32 autopkgtest always fails

  [test case]

  check http://autopkgtest.ubuntu.com/packages/g/gnupg2

  or run autopkgtest manually

  note the gpgv-win32 test is skipped on ppc64el and s390x for b/c, and
  has been removed from d/t/control entirely in d

  [regression potential]

  little to none; this affects the test case only

  [other info]

  as mentioned, in disco, the gpgv-win32 test has been removed from the
  tests/control completely.  not sure if that is a better approach than
  fixing the test case.  For now, I marked this Fix Released for disco
  since it doesn't fail there (since the testcase was removed).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnupg/+bug/1825186/+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 1895757] Re: Terminal hangs running sudo when "use_pty" is set in /etc/sudoers

2020-10-23 Thread Heitor Alves de Siqueira
Verified according to test case from description:

halves@bionic-vm:~$ sudo grep use_pty /etc/sudoers
Defaultsuse_pty
halves@bionic-vm:~$ dpkg -l | grep sudo
ii  sudo 1.8.21p2-3ubuntu1.3
 amd64Provide limited super user privileges to specific users
halves@bionic-vm:~$ for i in {1..10}; do sudo -- cat /var/log/syslog; done

Oct  1 14:37:40 bionic-vm kernel: [0.00] Linux version 
4.15.0-118-generic (buildd@lgw01-amd64-039) (gcc version 7.5.0 (Ubuntu 
7.5.0-3ubuntu1~18.04)) #119-Ubuntu SMP Tue Sep 8 12:30:01 UTC 2020 (Ubuntu 
4.15.0-118.119-generic 4.15.18)
O

Oct 23 15:53:15 bionic-vm systemd[1]: Started User Manager for UID 1000.
Oct 23 15:53:15 bionic-vm systemd[1810]: Reached target Default.
Oct 23 15:53:15 bionic-vm systemd[1810]: Startup finished in 30ms.
halves@bionic-vm:~$


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

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

Title:
  Terminal hangs running sudo when "use_pty" is set in /etc/sudoers

Status in sudo package in Ubuntu:
  Fix Released
Status in sudo source package in Bionic:
  Fix Committed

Bug description:
  [Impact]
  sudo commands can hang when IO logging is enabled

  [Description]
  When doing cleanup in pty_close(), sudo can leave file descriptors and events
  behind that would later cause poll() to wait on a "dead" pty. This can cause
  sudo to hang when IO logging is enabled, due to the poll() timeouts.

  The issue has been fixed upstream by the commit below:
  - In pty_close() close the slave and remove any events associated 
(4df454310dae)

  $ git describe --contains 4df454310dae96d01d09a05be89dc8c57fd4cef7
  SUDO_1_8_23

  $ rmadison sudo
   sudo | 1.8.16-0ubuntu1 | xenial   | source, ...
   sudo | 1.8.16-0ubuntu1.9   | xenial-security  | source, ...
   sudo | 1.8.16-0ubuntu1.9   | xenial-updates   | source, ...
   sudo | 1.8.21p2-3ubuntu1   | bionic   | source, ...
   sudo | 1.8.21p2-3ubuntu1.2 | bionic-security  | source, ...
   => sudo | 1.8.21p2-3ubuntu1.2 | bionic-updates   | source, ... <
   sudo | 1.8.31-1ubuntu1 | focal| source, ...
   sudo | 1.8.31-1ubuntu1.1   | focal-updates| source, ...
   sudo | 1.9.1-1ubuntu1  | groovy   | source, ...

  Xenial doesn't exhibit this behaviour, so fixes are only needed for Bionic
  (Focal onwards already have the fix by default due to sudo version).

  [Test Case]

  1. Ensure /etc/sudoers contains 'Defaults use_pty'
  2. Execute the following test command:
  $ for i in {1..10}; do sudo -- cat /var/log/syslog; done

  The terminal will hang during syslog output.

  [Regression Potential]
  The fix introduces additional cleaning when closing/flushing pty devices, so 
the
  regression potential should be low. It has been present upstream since
  sudo-1.8.23, so it has seen thorough testing in most Linux distributions
  including Ubuntu.

  A regression could possibly cause issues when switching back out from sudo
  sessions, as the changes only touch the pty_close path, but seems unlikely
  considering the patch has been present in other Ubuntu releases as well.

  --
  An SSH terminal into an Ubuntu server (tested on 18.04.5) hangs running a 
command using 'sudo' when 'use_pty' is set in /etc/sudoers.

  Steps to reproduce ('sudo' version --> 1.8.21p2-3ubuntu1.2):

  1) Log in into an Ubuntu server (tested on 18.04.5 using SSH)
  2) Ensure that /etc/sudoers has the following line (add this line if not 
present)
  Defaults  use_pty
  3) Execute the following (test 'sudo' command):
  for i in {1..10}; do sudo -- cat /var/log/syslog; done

  The terminal hangs and the following backtrace is obtained:

  (gdb) bt
  #0  0x7f751d5c8cc4 in __GI___poll (fds=0x55d0159917b0, nfds=1, 
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  #1  0x7f751d8b146a in poll (__timeout=, __nfds=, __fds=) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
  #2  sudo_ev_scan_impl (base=base@entry=0x55d015990dc0, flags=flags@entry=0) 
at ../../../lib/util/event_poll.c:155
  #3  0x7f751d8aa74d in sudo_ev_loop_v1 (base=base@entry=0x55d015990dc0, 
flags=flags@entry=0) at ../../../lib/util/event.c:617
  #4  0x55d01570597a in del_io_events (nonblocking=nonblocking@entry=false) 
at ../../src/exec_pty.c:1537
  #5  0x55d015707b97 in pty_close (cstat=0x7ffd074d6110) at 
../../src/exec_pty.c:697
  #6  exec_pty (details=details@entry=0x55d01591e0e0 , 
cstat=cstat@entry=0x7ffd074d6110) at ../../src/exec_pty.c:1412
  #7  0x55d015701178 in sudo_execute (details=0x55d01591e0e0 
, cstat=0x7ffd074d6110) at ../../src/exec.c:391
  #8  0x55d01570e15b in run_command (details=0x55d01591e0e0 
) at ../../src/sudo.c:968
  #9  0x55d0156ff9a0 in main (argc=, argv=, 

[Touch-packages] [Bug 1895757] Re: Terminal hangs running sudo when "use_pty" is set in /etc/sudoers

2020-09-23 Thread Heitor Alves de Siqueira
Builds for this patchset have been uploaded to:
https://launchpad.net/~halves/+archive/ubuntu/lp1895757

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

Title:
  Terminal hangs running sudo when "use_pty" is set in /etc/sudoers

Status in sudo package in Ubuntu:
  Fix Released
Status in sudo source package in Bionic:
  In Progress

Bug description:
  [Impact]
  sudo commands can hang when IO logging is enabled

  [Description]
  When doing cleanup in pty_close(), sudo can leave file descriptors and events
  behind that would later cause poll() to wait on a "dead" pty. This can cause
  sudo to hang when IO logging is enabled, due to the poll() timeouts.

  The issue has been fixed upstream by the commit below:
  - In pty_close() close the slave and remove any events associated 
(4df454310dae)

  $ rmadison sudo
   sudo | 1.8.16-0ubuntu1 | xenial   | source, ...
   sudo | 1.8.16-0ubuntu1.9   | xenial-security  | source, ...
   sudo | 1.8.16-0ubuntu1.9   | xenial-updates   | source, ...
   sudo | 1.8.21p2-3ubuntu1   | bionic   | source, ...
   sudo | 1.8.21p2-3ubuntu1.2 | bionic-security  | source, ...
   sudo | 1.8.21p2-3ubuntu1.2 | bionic-updates   | source, ... <
   sudo | 1.8.31-1ubuntu1 | focal| source, ...
   sudo | 1.8.31-1ubuntu1.1   | focal-updates| source, ...
   sudo | 1.9.1-1ubuntu1  | groovy   | source, ...

  Xenial doesn't exhibit this behaviour, so fixes are only needed for Bionic
  (Focal onwards already have the fix by default due to sudo version).

  [Test Case]

  1. Ensure /etc/sudoers contains 'Defaults use_pty'
  2. Execute the following test command:
  $ for i in {1..10}; do sudo -- cat /var/log/syslog; done

  The terminal will hang during syslog output.

  [Regression Potential]
  The fix introduces additional cleaning when closing/flushing pty devices, so 
the
  regression potential should be low. It has been present upstream since
  sudo-1.8.23, so it has seen thorough testing in most Linux distributions
  including Ubuntu.

  A regression could possibly cause issues when switching back out from sudo
  sessions, as the changes only touch the pty_close path, but seems unlikely
  considering the patch has been present in other Ubuntu releases as well.

  --
  An SSH terminal into an Ubuntu server (tested on 18.04.5) hangs running a 
command using 'sudo' when 'use_pty' is set in /etc/sudoers.

  Steps to reproduce ('sudo' version --> 1.8.21p2-3ubuntu1.2):

  1) Log in into an Ubuntu server (tested on 18.04.5 using SSH)
  2) Ensure that /etc/sudoers has the following line (add this line if not 
present)
  Defaults  use_pty
  3) Execute the following (test 'sudo' command):
  for i in {1..10}; do sudo -- cat /var/log/syslog; done

  The terminal hangs and the following backtrace is obtained:

  (gdb) bt
  #0  0x7f751d5c8cc4 in __GI___poll (fds=0x55d0159917b0, nfds=1, 
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  #1  0x7f751d8b146a in poll (__timeout=, __nfds=, __fds=) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
  #2  sudo_ev_scan_impl (base=base@entry=0x55d015990dc0, flags=flags@entry=0) 
at ../../../lib/util/event_poll.c:155
  #3  0x7f751d8aa74d in sudo_ev_loop_v1 (base=base@entry=0x55d015990dc0, 
flags=flags@entry=0) at ../../../lib/util/event.c:617
  #4  0x55d01570597a in del_io_events (nonblocking=nonblocking@entry=false) 
at ../../src/exec_pty.c:1537
  #5  0x55d015707b97 in pty_close (cstat=0x7ffd074d6110) at 
../../src/exec_pty.c:697
  #6  exec_pty (details=details@entry=0x55d01591e0e0 , 
cstat=cstat@entry=0x7ffd074d6110) at ../../src/exec_pty.c:1412
  #7  0x55d015701178 in sudo_execute (details=0x55d01591e0e0 
, cstat=0x7ffd074d6110) at ../../src/exec.c:391
  #8  0x55d01570e15b in run_command (details=0x55d01591e0e0 
) at ../../src/sudo.c:968
  #9  0x55d0156ff9a0 in main (argc=, argv=, 
envp=) at ../../src/sudo.c:294

  A similar (most likely the same) bug has been reported here
  https://access.redhat.com/solutions/3404401.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1895757/+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 1895757] Re: Terminal hangs running sudo when "use_pty" is set in /etc/sudoers

2020-09-23 Thread Heitor Alves de Siqueira
** Tags added: sts-sponsor

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

Title:
  Terminal hangs running sudo when "use_pty" is set in /etc/sudoers

Status in sudo package in Ubuntu:
  Fix Released
Status in sudo source package in Bionic:
  In Progress

Bug description:
  [Impact]
  sudo commands can hang when IO logging is enabled

  [Description]
  When doing cleanup in pty_close(), sudo can leave file descriptors and events
  behind that would later cause poll() to wait on a "dead" pty. This can cause
  sudo to hang when IO logging is enabled, due to the poll() timeouts.

  The issue has been fixed upstream by the commit below:
  - In pty_close() close the slave and remove any events associated 
(4df454310dae)

  $ rmadison sudo
   sudo | 1.8.16-0ubuntu1 | xenial   | source, ...
   sudo | 1.8.16-0ubuntu1.9   | xenial-security  | source, ...
   sudo | 1.8.16-0ubuntu1.9   | xenial-updates   | source, ...
   sudo | 1.8.21p2-3ubuntu1   | bionic   | source, ...
   sudo | 1.8.21p2-3ubuntu1.2 | bionic-security  | source, ...
   sudo | 1.8.21p2-3ubuntu1.2 | bionic-updates   | source, ... <
   sudo | 1.8.31-1ubuntu1 | focal| source, ...
   sudo | 1.8.31-1ubuntu1.1   | focal-updates| source, ...
   sudo | 1.9.1-1ubuntu1  | groovy   | source, ...

  Xenial doesn't exhibit this behaviour, so fixes are only needed for Bionic
  (Focal onwards already have the fix by default due to sudo version).

  [Test Case]

  1. Ensure /etc/sudoers contains 'Defaults use_pty'
  2. Execute the following test command:
  $ for i in {1..10}; do sudo -- cat /var/log/syslog; done

  The terminal will hang during syslog output.

  [Regression Potential]
  The fix introduces additional cleaning when closing/flushing pty devices, so 
the
  regression potential should be low. It has been present upstream since
  sudo-1.8.23, so it has seen thorough testing in most Linux distributions
  including Ubuntu.

  A regression could possibly cause issues when switching back out from sudo
  sessions, as the changes only touch the pty_close path, but seems unlikely
  considering the patch has been present in other Ubuntu releases as well.

  --
  An SSH terminal into an Ubuntu server (tested on 18.04.5) hangs running a 
command using 'sudo' when 'use_pty' is set in /etc/sudoers.

  Steps to reproduce ('sudo' version --> 1.8.21p2-3ubuntu1.2):

  1) Log in into an Ubuntu server (tested on 18.04.5 using SSH)
  2) Ensure that /etc/sudoers has the following line (add this line if not 
present)
  Defaults  use_pty
  3) Execute the following (test 'sudo' command):
  for i in {1..10}; do sudo -- cat /var/log/syslog; done

  The terminal hangs and the following backtrace is obtained:

  (gdb) bt
  #0  0x7f751d5c8cc4 in __GI___poll (fds=0x55d0159917b0, nfds=1, 
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  #1  0x7f751d8b146a in poll (__timeout=, __nfds=, __fds=) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
  #2  sudo_ev_scan_impl (base=base@entry=0x55d015990dc0, flags=flags@entry=0) 
at ../../../lib/util/event_poll.c:155
  #3  0x7f751d8aa74d in sudo_ev_loop_v1 (base=base@entry=0x55d015990dc0, 
flags=flags@entry=0) at ../../../lib/util/event.c:617
  #4  0x55d01570597a in del_io_events (nonblocking=nonblocking@entry=false) 
at ../../src/exec_pty.c:1537
  #5  0x55d015707b97 in pty_close (cstat=0x7ffd074d6110) at 
../../src/exec_pty.c:697
  #6  exec_pty (details=details@entry=0x55d01591e0e0 , 
cstat=cstat@entry=0x7ffd074d6110) at ../../src/exec_pty.c:1412
  #7  0x55d015701178 in sudo_execute (details=0x55d01591e0e0 
, cstat=0x7ffd074d6110) at ../../src/exec.c:391
  #8  0x55d01570e15b in run_command (details=0x55d01591e0e0 
) at ../../src/sudo.c:968
  #9  0x55d0156ff9a0 in main (argc=, argv=, 
envp=) at ../../src/sudo.c:294

  A similar (most likely the same) bug has been reported here
  https://access.redhat.com/solutions/3404401.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1895757/+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 1895757] Re: Terminal hangs running sudo when "use_pty" is set in /etc/sudoers

2020-09-23 Thread Heitor Alves de Siqueira
** Description changed:

- An SSH terminal into an Ubuntu server (tested on 18.04.5) hangs running
- a command using 'sudo' when 'use_pty' is set in /etc/sudoers.
+ [Impact]
+ sudo commands can hang when IO logging is enabled
+ 
+ [Description]
+ When doing cleanup in pty_close(), sudo can leave file descriptors and events
+ behind that would later cause poll() to wait on a "dead" pty. This can cause
+ sudo to hang when IO logging is enabled, due to the poll() timeouts.
+ 
+ The issue has been fixed upstream by the commit below:
+ - In pty_close() close the slave and remove any events associated 
(4df454310dae)
+ 
+ $ rmadison sudo
+  sudo | 1.8.16-0ubuntu1 | xenial   | source, ...
+  sudo | 1.8.16-0ubuntu1.9   | xenial-security  | source, ...
+  sudo | 1.8.16-0ubuntu1.9   | xenial-updates   | source, ...
+  sudo | 1.8.21p2-3ubuntu1   | bionic   | source, ...
+  sudo | 1.8.21p2-3ubuntu1.2 | bionic-security  | source, ...
+  sudo | 1.8.21p2-3ubuntu1.2 | bionic-updates   | source, ... <
+  sudo | 1.8.31-1ubuntu1 | focal| source, ...
+  sudo | 1.8.31-1ubuntu1.1   | focal-updates| source, ...
+  sudo | 1.9.1-1ubuntu1  | groovy   | source, ...
+ 
+ Xenial doesn't exhibit this behaviour, so fixes are only needed for Bionic
+ (Focal onwards already have the fix by default due to sudo version).
+ 
+ [Test Case]
+ 
+ 1. Ensure /etc/sudoers contains 'Defaults use_pty'
+ 2. Execute the following test command:
+ $ for i in {1..10}; do sudo -- cat /var/log/syslog; done
+ 
+ The terminal will hang during syslog output.
+ 
+ [Regression Potential]
+ The fix introduces additional cleaning when closing/flushing pty devices, so 
the
+ regression potential should be low. It has been present upstream since
+ sudo-1.8.23, so it has seen thorough testing in most Linux distributions
+ including Ubuntu.
+ 
+ A regression could possibly cause issues when switching back out from sudo
+ sessions, as the changes only touch the pty_close path, but seems unlikely
+ considering the patch has been present in other Ubuntu releases as well.
+ 
+ --
+ An SSH terminal into an Ubuntu server (tested on 18.04.5) hangs running a 
command using 'sudo' when 'use_pty' is set in /etc/sudoers.
  
  Steps to reproduce ('sudo' version --> 1.8.21p2-3ubuntu1.2):
  
  1) Log in into an Ubuntu server (tested on 18.04.5 using SSH)
  2) Ensure that /etc/sudoers has the following line (add this line if not 
present)
  Defaults  use_pty
  3) Execute the following (test 'sudo' command):
  for i in {1..10}; do sudo -- cat /var/log/syslog; done
  
  The terminal hangs and the following backtrace is obtained:
  
  (gdb) bt
  #0  0x7f751d5c8cc4 in __GI___poll (fds=0x55d0159917b0, nfds=1, 
timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:29
  #1  0x7f751d8b146a in poll (__timeout=, __nfds=, __fds=) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
  #2  sudo_ev_scan_impl (base=base@entry=0x55d015990dc0, flags=flags@entry=0) 
at ../../../lib/util/event_poll.c:155
  #3  0x7f751d8aa74d in sudo_ev_loop_v1 (base=base@entry=0x55d015990dc0, 
flags=flags@entry=0) at ../../../lib/util/event.c:617
  #4  0x55d01570597a in del_io_events (nonblocking=nonblocking@entry=false) 
at ../../src/exec_pty.c:1537
  #5  0x55d015707b97 in pty_close (cstat=0x7ffd074d6110) at 
../../src/exec_pty.c:697
  #6  exec_pty (details=details@entry=0x55d01591e0e0 , 
cstat=cstat@entry=0x7ffd074d6110) at ../../src/exec_pty.c:1412
  #7  0x55d015701178 in sudo_execute (details=0x55d01591e0e0 
, cstat=0x7ffd074d6110) at ../../src/exec.c:391
  #8  0x55d01570e15b in run_command (details=0x55d01591e0e0 
) at ../../src/sudo.c:968
  #9  0x55d0156ff9a0 in main (argc=, argv=, 
envp=) at ../../src/sudo.c:294
  
  A similar (most likely the same) bug has been reported here
  https://access.redhat.com/solutions/3404401.

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

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

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

** Changed in: sudo (Ubuntu Bionic)
 Assignee: (unassigned) => Heitor Alves de Siqueira (halves)

** Tags added: sts

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

Title:
  Terminal hangs running sudo when "use_pty" is set in /etc/sudoers

Status in sudo package in Ubuntu:
  Fix Released
Status in sudo source package in Bionic:
  In Progress

Bug description:
  [Impact]
  sudo commands can hang when IO logging is enabled

  [Description]
  When doing cleanup in pty_close(), sudo can leave file descriptors and events
  behind that would later cause poll() to wait on a "dead" pty. This can cause
  sudo to hang when IO logging is enabled, due to the poll() timeouts.

  The issue has been fixed upstream by the commit below:
 

[Touch-packages] [Bug 1876600] Re: cookie overruns can cause org.freedesktop.systemd1 dbus to hang

2020-09-09 Thread Heitor Alves de Siqueira
Validated systemd/229-4ubuntu21.29 from xenial-proposed, according to
test case from description:

ubuntu@systemd-cookie-xenial:~$ dpkg -l systemd | grep systemd
ii  systemd229-4ubuntu21.29 amd64system and service manager
ubuntu@systemd-cookie-xenial:~$ gcc -Wall test.c -o cookie -lsystemd -g
ubuntu@systemd-cookie-xenial:~$ gdb --batch --command=test.gdb --args ./cookie
Breakpoint 1 at 0x400ddb: file test.c, line 38.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
(65s) cookie: 0x0001reply-cookie: 0x0001

Breakpoint 1, print_unit_path (bus=0x603040) at test.c:38
38  r = sd_bus_message_new_method_call(bus, ,
$1 = 0x1
$2 = 0xff00
(65s) cookie: 0x8000reply-cookie: 0x8000
(129s) cookie: 0x8001   reply-cookie: 0x8001
(188s) cookie: 0x8002   reply-cookie: 0x8002


** Tags removed: verification-needed verification-needed-xenial
** Tags added: verification-done verification-done-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/1876600

Title:
  cookie overruns can cause org.freedesktop.systemd1 dbus to hang

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Fix Committed
Status in systemd source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  Long-running services overflow the sd_bus->cookie counter, causing further 
communication with org.freedesktop.systemd1 to stall.

  [Description]
  Systemd dbus messages include a "cookie" value to uniquely identify them in 
their bus context. This value is obtained from the bus header, and incremented 
for each exchanged message in the same bus object. For services that run for 
longer periods of time and keep communicating through dbus, it's possible to 
overflow the cookie value, causing further messages to the 
org.freedesktop.systemd1 dbus to fail. This can lead to these services becoming 
unresponsive, as they get stuck trying to communicate with invalid bus cookie 
values.

  This issue has been fixed upstream by the commit below:
  -  sd-bus: deal with cookie overruns (1f82f5bb4237)

  $ git describe --contains 1f82f5bb4237
  v242-rc1~228

  $ rmadison systemd
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.27 | xenial-security | source, ...
   systemd | 229-4ubuntu21.27 | xenial-updates  | source, ...
   systemd | 229-4ubuntu21.28 | xenial-proposed | source, ...
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.38 | bionic-security | source, ...
   systemd | 237-3ubuntu10.39 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <
   systemd | 242-7ubuntu3 | eoan| source, ...

  Releases starting with Eoan already have this fix.

  [Test Case]
  There doesn't seem to be an easy test case for this, as the cookie values 
start at zero and won't overflow until (1<<32). There have been reports from 
users hitting this on Kubernetes clusters continuously running for longer 
periods (~5 months).
  Using GDB, we can construct an artificial test case to test the cookie 
overflow. The test case below performs the following steps:

  1. Create a new system bus object through sd_bus_default_system()
  2. Allocate and append a new method_call message to the bus
  3. Send the message through sd_bus_call()
  4. Handle the response message and free up the message objects

  It's essentially the example code from the
  sd_bus_message_new_method_call() manpage, with minor modifications:
  this is done continuously, to keep incrementing the bus cookie value.
  We step in with GDB when it reaches 0x1, and set its value to
  0xff00 which then causes the test program to fail shortly
  afterwards. An example test run of an impacted system:

  ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g
  ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie
  Breakpoint 1 at 0xe61: file test.c, line 38.
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  (16s) cookie: 0x0001reply-cookie: 0x0001

  Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38
  38  r = sd_bus_message_new_method_call(bus, ,
  $1 = 0x1
  $2 = 0xff00
  Call failed: Operation not supported
  Sleeping and retrying...
  Call failed: Invalid argument
  Assertion 'm->n_ref > 0' failed at 
../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). 
Aborting.

  Program received signal SIGABRT, Aborted.
  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
  51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

  To compile and debug the test 

[Touch-packages] [Bug 1876600] Re: cookie overruns can cause org.freedesktop.systemd1 dbus to hang

2020-05-22 Thread Heitor Alves de Siqueira
Validated systemd 237-3ubuntu10.41 from bionic-proposed, according to
test case from bug description:

ubuntu@systemd-cookie-bionic:~$ dpkg -l systemd | grep systemd
ii  systemd237-3ubuntu10.41 amd64system and service manager
ubuntu@systemd-cookie-bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g
ubuntu@systemd-cookie-bionic:~$ gdb --batch --command=test.gdb --args ./cookie
Breakpoint 1 at 0xe61: file test.c, line 38.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
(15s) cookie: 0x0001reply-cookie: 0x0001

Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38
38  r = sd_bus_message_new_method_call(bus, ,
$1 = 0x1
$2 = 0xff00
(15s) cookie: 0x8000reply-cookie: 0x8000
(29s) cookie: 0x8001reply-cookie: 0x8001
(43s) cookie: 0x8002reply-cookie: 0x8002


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

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

Title:
  cookie overruns can cause org.freedesktop.systemd1 dbus to hang

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  Fix Committed

Bug description:
  [Impact]
  Long-running services overflow the sd_bus->cookie counter, causing further 
communication with org.freedesktop.systemd1 to stall.

  [Description]
  Systemd dbus messages include a "cookie" value to uniquely identify them in 
their bus context. This value is obtained from the bus header, and incremented 
for each exchanged message in the same bus object. For services that run for 
longer periods of time and keep communicating through dbus, it's possible to 
overflow the cookie value, causing further messages to the 
org.freedesktop.systemd1 dbus to fail. This can lead to these services becoming 
unresponsive, as they get stuck trying to communicate with invalid bus cookie 
values.

  This issue has been fixed upstream by the commit below:
  -  sd-bus: deal with cookie overruns (1f82f5bb4237)

  $ git describe --contains 1f82f5bb4237
  v242-rc1~228

  $ rmadison systemd
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.27 | xenial-security | source, ...
   systemd | 229-4ubuntu21.27 | xenial-updates  | source, ...
   systemd | 229-4ubuntu21.28 | xenial-proposed | source, ...
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.38 | bionic-security | source, ...
   systemd | 237-3ubuntu10.39 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <
   systemd | 242-7ubuntu3 | eoan| source, ...

  Releases starting with Eoan already have this fix.

  [Test Case]
  There doesn't seem to be an easy test case for this, as the cookie values 
start at zero and won't overflow until (1<<32). There have been reports from 
users hitting this on Kubernetes clusters continuously running for longer 
periods (~5 months).
  Using GDB, we can construct an artificial test case to test the cookie 
overflow. The test case below performs the following steps:

  1. Create a new system bus object through sd_bus_default_system()
  2. Allocate and append a new method_call message to the bus
  3. Send the message through sd_bus_call()
  4. Handle the response message and free up the message objects

  It's essentially the example code from the
  sd_bus_message_new_method_call() manpage, with minor modifications:
  this is done continuously, to keep incrementing the bus cookie value.
  We step in with GDB when it reaches 0x1, and set its value to
  0xff00 which then causes the test program to fail shortly
  afterwards. An example test run of an impacted system:

  ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g
  ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie
  Breakpoint 1 at 0xe61: file test.c, line 38.
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  (16s) cookie: 0x0001reply-cookie: 0x0001

  Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38
  38  r = sd_bus_message_new_method_call(bus, ,
  $1 = 0x1
  $2 = 0xff00
  Call failed: Operation not supported
  Sleeping and retrying...
  Call failed: Invalid argument
  Assertion 'm->n_ref > 0' failed at 
../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). 
Aborting.

  Program received signal SIGABRT, Aborted.
  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
  51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

  To compile and debug the 

[Touch-packages] [Bug 1876600] Re: cookie overruns can cause org.freedesktop.systemd1 dbus to hang

2020-05-05 Thread Heitor Alves de Siqueira
** Changed in: systemd (Ubuntu Xenial)
   Status: Confirmed => In Progress

** Changed in: systemd (Ubuntu Bionic)
   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/1876600

Title:
  cookie overruns can cause org.freedesktop.systemd1 dbus to hang

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress

Bug description:
  [Impact]
  Long-running services overflow the sd_bus->cookie counter, causing further 
communication with org.freedesktop.systemd1 to stall.

  [Description]
  Systemd dbus messages include a "cookie" value to uniquely identify them in 
their bus context. This value is obtained from the bus header, and incremented 
for each exchanged message in the same bus object. For services that run for 
longer periods of time and keep communicating through dbus, it's possible to 
overflow the cookie value, causing further messages to the 
org.freedesktop.systemd1 dbus to fail. This can lead to these services becoming 
unresponsive, as they get stuck trying to communicate with invalid bus cookie 
values.

  This issue has been fixed upstream by the commit below:
  -  sd-bus: deal with cookie overruns (1f82f5bb4237)

  $ git describe --contains 1f82f5bb4237
  v242-rc1~228

  $ rmadison systemd
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.27 | xenial-security | source, ...
   systemd | 229-4ubuntu21.27 | xenial-updates  | source, ...
   systemd | 229-4ubuntu21.28 | xenial-proposed | source, ...
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.38 | bionic-security | source, ...
   systemd | 237-3ubuntu10.39 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <
   systemd | 242-7ubuntu3 | eoan| source, ...

  Releases starting with Eoan already have this fix.

  [Test Case]
  There doesn't seem to be an easy test case for this, as the cookie values 
start at zero and won't overflow until (1<<32). There have been reports from 
users hitting this on Kubernetes clusters continuously running for longer 
periods (~5 months).
  Using GDB, we can construct an artificial test case to test the cookie 
overflow. The test case below performs the following steps:

  1. Create a new system bus object through sd_bus_default_system()
  2. Allocate and append a new method_call message to the bus
  3. Send the message through sd_bus_call()
  4. Handle the response message and free up the message objects

  It's essentially the example code from the
  sd_bus_message_new_method_call() manpage, with minor modifications:
  this is done continuously, to keep incrementing the bus cookie value.
  We step in with GDB when it reaches 0x1, and set its value to
  0xff00 which then causes the test program to fail shortly
  afterwards. An example test run of an impacted system:

  ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g
  ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie
  Breakpoint 1 at 0xe61: file test.c, line 38.
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  (16s) cookie: 0x0001reply-cookie: 0x0001

  Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38
  38  r = sd_bus_message_new_method_call(bus, ,
  $1 = 0x1
  $2 = 0xff00
  Call failed: Operation not supported
  Sleeping and retrying...
  Call failed: Invalid argument
  Assertion 'm->n_ref > 0' failed at 
../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). 
Aborting.

  Program received signal SIGABRT, Aborted.
  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
  51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.

  To compile and debug the test case above, libsystemd-dev and 
libsystemd0-dbgsym are required.
  Both test.c and test.gdb source code are attached to this LP bug.

  [Regression Potential]
  This fix introduces some changes in the way cookie incrementation is handled. 
We now have a reduced number of available values, since the patch makes use of 
a high order bit to indicate whether we have overflowed or not. Potential 
issues could arise from two distinct messages repeating the cookie value, or 
from us not handling the cookie reuse properly. In practice, this shouldn't 
cause serious problems as most dbus messages should not stall long enough for a 
possible overlap in the 2^31 space. The patch has been present in other stable 
Ubuntu Series and upstream, and has been validated and tested through the 
systemd test suite and autopkgtests.

To manage notifications about this bug go to:

[Touch-packages] [Bug 1876600] Re: cookie overruns can cause org.freedesktop.systemd1 dbus to hang

2020-05-05 Thread Heitor Alves de Siqueira
** Description changed:

  [Impact]
  Long-running services overflow the sd_bus->cookie counter, causing further 
communication with org.freedesktop.systemd1 to stall.
  
  [Description]
  Systemd dbus messages include a "cookie" value to uniquely identify them in 
their bus context. This value is obtained from the bus header, and incremented 
for each exchanged message in the same bus object. For services that run for 
longer periods of time and keep communicating through dbus, it's possible to 
overflow the cookie value, causing further messages to the 
org.freedesktop.systemd1 dbus to fail. This can lead to these services becoming 
unresponsive, as they get stuck trying to communicate with invalid bus cookie 
values.
  
  This issue has been fixed upstream by the commit below:
  -  sd-bus: deal with cookie overruns (1f82f5bb4237)
  
  $ git describe --contains 1f82f5bb4237
  v242-rc1~228
  
  $ rmadison systemd
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.27 | xenial-security | source, ...
   systemd | 229-4ubuntu21.27 | xenial-updates  | source, ...
   systemd | 229-4ubuntu21.28 | xenial-proposed | source, ...
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.38 | bionic-security | source, ...
   systemd | 237-3ubuntu10.39 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <
   systemd | 242-7ubuntu3 | eoan| source, ...
  
  Releases starting with Eoan already have this fix.
  
  [Test Case]
  There doesn't seem to be an easy test case for this, as the cookie values 
start at zero and won't overflow until (1<<32). There have been reports from 
users hitting this on Kubernetes clusters continuously running for longer 
periods (~5 months).
  Using GDB, we can construct an artificial test case to test the cookie 
overflow. The test case below performs the following steps:
  
  1. Create a new system bus object through sd_bus_default_system()
  2. Allocate and append a new method_call message to the bus
  3. Send the message through sd_bus_call()
  4. Handle the response message and free up the message objects
  
  It's essentially the example code from the
  sd_bus_message_new_method_call() manpage, with minor modifications: this
  is done continuously, to keep incrementing the bus cookie value. We step
  in with GDB when it reaches 0x1, and set its value to 0xff00
  which then causes the test program to fail shortly afterwards. An
  example test run of an impacted system:
  
  ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g
  ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie
  Breakpoint 1 at 0xe61: file test.c, line 38.
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  (16s) cookie: 0x0001reply-cookie: 0x0001
  
  Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38
  38  r = sd_bus_message_new_method_call(bus, ,
  $1 = 0x1
  $2 = 0xff00
  Call failed: Operation not supported
  Sleeping and retrying...
  Call failed: Invalid argument
  Assertion 'm->n_ref > 0' failed at 
../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). 
Aborting.
  
  Program received signal SIGABRT, Aborted.
  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
  51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
- u
  
  To compile and debug the test case above, libsystemd-dev and 
libsystemd0-dbgsym are required.
  Both test.c and test.gdb source code are attached to this LP bug.
  
  [Regression Potential]
  This fix introduces some changes in the way cookie incrementation is handled. 
We now have a reduced number of available values, since the patch makes use of 
a high order bit to indicate whether we have overflowed or not. Potential 
issues could arise from two distinct messages repeating the cookie value, or 
from us not handling the cookie reuse properly. In practice, this shouldn't 
cause serious problems as most dbus messages should not stall long enough for a 
possible overlap in the 2^31 space. The patch has been present in other stable 
Ubuntu Series and upstream, and has been validated and tested through the 
systemd test suite and autopkgtests.

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

Title:
  cookie overruns can cause org.freedesktop.systemd1 dbus to hang

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  In Progress
Status in systemd source package in Bionic:
  In Progress

Bug description:
  [Impact]
  Long-running services overflow the sd_bus->cookie counter, causing further 
communication with org.freedesktop.systemd1 to stall.

  [Description]
  Systemd dbus messages 

[Touch-packages] [Bug 1876600] Re: cookie overruns can cause org.freedesktop.systemd1 dbus to hang

2020-05-05 Thread Heitor Alves de Siqueira
Test builds for the proposed merge can be found at the lp1876600 PPA
[0].

[0] https://launchpad.net/~halves/+archive/ubuntu/lp1876600

** Tags added: sts-sponsor

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

Title:
  cookie overruns can cause org.freedesktop.systemd1 dbus to hang

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Confirmed
Status in systemd source package in Bionic:
  Confirmed

Bug description:
  [Impact]
  Long-running services overflow the sd_bus->cookie counter, causing further 
communication with org.freedesktop.systemd1 to stall.

  [Description]
  Systemd dbus messages include a "cookie" value to uniquely identify them in 
their bus context. This value is obtained from the bus header, and incremented 
for each exchanged message in the same bus object. For services that run for 
longer periods of time and keep communicating through dbus, it's possible to 
overflow the cookie value, causing further messages to the 
org.freedesktop.systemd1 dbus to fail. This can lead to these services becoming 
unresponsive, as they get stuck trying to communicate with invalid bus cookie 
values.

  This issue has been fixed upstream by the commit below:
  -  sd-bus: deal with cookie overruns (1f82f5bb4237)

  $ git describe --contains 1f82f5bb4237
  v242-rc1~228

  $ rmadison systemd
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.27 | xenial-security | source, ...
   systemd | 229-4ubuntu21.27 | xenial-updates  | source, ...
   systemd | 229-4ubuntu21.28 | xenial-proposed | source, ...
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.38 | bionic-security | source, ...
   systemd | 237-3ubuntu10.39 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <
   systemd | 242-7ubuntu3 | eoan| source, ...

  Releases starting with Eoan already have this fix.

  [Test Case]
  There doesn't seem to be an easy test case for this, as the cookie values 
start at zero and won't overflow until (1<<32). There have been reports from 
users hitting this on Kubernetes clusters continuously running for longer 
periods (~5 months).
  Using GDB, we can construct an artificial test case to test the cookie 
overflow. The test case below performs the following steps:

  1. Create a new system bus object through sd_bus_default_system()
  2. Allocate and append a new method_call message to the bus
  3. Send the message through sd_bus_call()
  4. Handle the response message and free up the message objects

  It's essentially the example code from the
  sd_bus_message_new_method_call() manpage, with minor modifications:
  this is done continuously, to keep incrementing the bus cookie value.
  We step in with GDB when it reaches 0x1, and set its value to
  0xff00 which then causes the test program to fail shortly
  afterwards. An example test run of an impacted system:

  ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g
  ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie
  Breakpoint 1 at 0xe61: file test.c, line 38.
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  (16s) cookie: 0x0001reply-cookie: 0x0001

  Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38
  38  r = sd_bus_message_new_method_call(bus, ,
  $1 = 0x1
  $2 = 0xff00
  Call failed: Operation not supported
  Sleeping and retrying...
  Call failed: Invalid argument
  Assertion 'm->n_ref > 0' failed at 
../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). 
Aborting.

  Program received signal SIGABRT, Aborted.
  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
  51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
  u

  To compile and debug the test case above, libsystemd-dev and 
libsystemd0-dbgsym are required.
  Both test.c and test.gdb source code are attached to this LP bug.

  [Regression Potential]
  This fix introduces some changes in the way cookie incrementation is handled. 
We now have a reduced number of available values, since the patch makes use of 
a high order bit to indicate whether we have overflowed or not. Potential 
issues could arise from two distinct messages repeating the cookie value, or 
from us not handling the cookie reuse properly. In practice, this shouldn't 
cause serious problems as most dbus messages should not stall long enough for a 
possible overlap in the 2^31 space. The patch has been present in other stable 
Ubuntu Series and upstream, and has been validated and tested through the 
systemd test suite and autopkgtests.

To manage notifications about this bug go to:

[Touch-packages] [Bug 1876600] Re: cookie overruns can cause org.freedesktop.systemd1 dbus to hang

2020-05-05 Thread Heitor Alves de Siqueira
** Attachment added: "test.gdb"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1876600/+attachment/5366780/+files/test.gdb

** Description changed:

  [Impact]
  Long-running services overflow the sd_bus->cookie counter, causing further 
communication with org.freedesktop.systemd1 to stall.
  
  [Description]
  Systemd dbus messages include a "cookie" value to uniquely identify them in 
their bus context. This value is obtained from the bus header, and incremented 
for each exchanged message in the same bus object. For services that run for 
longer periods of time and keep communicating through dbus, it's possible to 
overflow the cookie value, causing further messages to the 
org.freedesktop.systemd1 dbus to fail. This can lead to these services becoming 
unresponsive, as they get stuck trying to communicate with invalid bus cookie 
values.
  
  This issue has been fixed upstream by the commit below:
  -  sd-bus: deal with cookie overruns (1f82f5bb4237)
  
  $ git describe --contains 1f82f5bb4237
  v242-rc1~228
  
  $ rmadison systemd
-  systemd | 229-4ubuntu4 | xenial  | source, ...
-  systemd | 229-4ubuntu21.27 | xenial-security | source, ...
-  systemd | 229-4ubuntu21.27 | xenial-updates  | source, ...
-  systemd | 229-4ubuntu21.28 | xenial-proposed | source, ...
-  systemd | 237-3ubuntu10| bionic  | source, ...
-  systemd | 237-3ubuntu10.38 | bionic-security | source, ...
-  systemd | 237-3ubuntu10.39 | bionic-updates  | source, ...
-  systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <
-  systemd | 242-7ubuntu3 | eoan| source, ...
+  systemd | 229-4ubuntu4 | xenial  | source, ...
+  systemd | 229-4ubuntu21.27 | xenial-security | source, ...
+  systemd | 229-4ubuntu21.27 | xenial-updates  | source, ...
+  systemd | 229-4ubuntu21.28 | xenial-proposed | source, ...
+  systemd | 237-3ubuntu10| bionic  | source, ...
+  systemd | 237-3ubuntu10.38 | bionic-security | source, ...
+  systemd | 237-3ubuntu10.39 | bionic-updates  | source, ...
+  systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <
+  systemd | 242-7ubuntu3 | eoan| source, ...
  
  Releases starting with Eoan already have this fix.
  
  [Test Case]
  There doesn't seem to be an easy test case for this, as the cookie values 
start at zero and won't overflow until (1<<32). There have been reports from 
users hitting this on Kubernetes clusters continuously running for longer 
periods (~5 months).
  Using GDB, we can construct an artificial test case to test the cookie 
overflow. The test case below performs the following steps:
  
  1. Create a new system bus object through sd_bus_default_system()
  2. Allocate and append a new method_call message to the bus
  3. Send the message through sd_bus_call()
  4. Handle the response message and free up the message objects
  
- This is done continuously, to keep incrementing the bus cookie value. We step 
in with GDB when it reaches 0x1, and set its value to 0xff00 which then 
causes the test program to fail shortly afterwards. An example test run of an 
impacted system:
+ It's essentially the example code from the
+ sd_bus_message_new_method_call() manpage, with minor modifications: this
+ is done continuously, to keep incrementing the bus cookie value. We step
+ in with GDB when it reaches 0x1, and set its value to 0xff00
+ which then causes the test program to fail shortly afterwards. An
+ example test run of an impacted system:
+ 
  ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g
  ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie
  Breakpoint 1 at 0xe61: file test.c, line 38.
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
  (16s) cookie: 0x0001reply-cookie: 0x0001
  
  Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38
  38  r = sd_bus_message_new_method_call(bus, ,
  $1 = 0x1
  $2 = 0xff00
  Call failed: Operation not supported
  Sleeping and retrying...
  Call failed: Invalid argument
  Assertion 'm->n_ref > 0' failed at 
../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). 
Aborting.
  
  Program received signal SIGABRT, Aborted.
  __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
  51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
  u
  
  To compile and debug the test case above, libsystemd-dev and 
libsystemd0-dbgsym are required.
  Both test.c and test.gdb source code are attached to this LP bug.
  
  [Regression Potential]
  This fix introduces some changes in the way cookie incrementation is handled. 
We now have a reduced number of available values, since the patch makes use of 
a high order bit to indicate whether we have overflowed or not. Potential 
issues could arise from two distinct messages repeating the cookie value, or 
from us not 

[Touch-packages] [Bug 1876600] Re: cookie overruns cause org.freedesktop.systemd1 dbus to hang

2020-05-05 Thread Heitor Alves de Siqueira
** Description changed:

  [Impact]
  Long-running services overflow the sd_bus->cookie counter, causing further 
communication with org.freedesktop.systemd1 to stall.
  
  [Description]
- Systemd dbus messages usually include a "cookie" value to uniquely identify 
them in their bus context. For services that run for longer periods of time and 
keep communicating through dbus, it's possible to overflow the cookie value, 
causing further messages to the org.freedesktop.systemd1 dbus to hang.
+ Systemd dbus messages include a "cookie" value to uniquely identify them in 
their bus context. This value is obtained from the bus header, and incremented 
for each exchanged message in the same bus object. For services that run for 
longer periods of time and keep communicating through dbus, it's possible to 
overflow the cookie value, causing further messages to the 
org.freedesktop.systemd1 dbus to fail. This can lead to these services becoming 
unresponsive, as they get stuck trying to communicate with invalid bus cookie 
values.
  
- This has been fixed upstream by the commit below:
+ This issue has been fixed upstream by the commit below:
  -  sd-bus: deal with cookie overruns (1f82f5bb4237)
  
  $ git describe --contains 1f82f5bb4237
  v242-rc1~228
  
  $ rmadison systemd
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.27 | xenial-security | source, ...
   systemd | 229-4ubuntu21.27 | xenial-updates  | source, ...
   systemd | 229-4ubuntu21.28 | xenial-proposed | source, ...
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.38 | bionic-security | source, ...
   systemd | 237-3ubuntu10.39 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <
   systemd | 242-7ubuntu3 | eoan| source, ...
  
  Releases starting with Eoan already have this fix.
  
  [Test Case]
  There doesn't seem to be an easy test case for this, as the cookie values 
start at zero and won't overflow until (1<<32). There have been reports from 
users hitting this on Kubernetes clusters continuously running for longer 
periods (~5 months).
+ Using GDB, we can construct an artificial test case to test the cookie 
overflow. The test case below performs the following steps:
+ 
+ 1. Create a new system bus object through sd_bus_default_system()
+ 2. Allocate and append a new method_call message to the bus
+ 3. Send the message through sd_bus_call()
+ 4. Handle the response message and free up the message objects
+ 
+ This is done continuously, to keep incrementing the bus cookie value. We step 
in with GDB when it reaches 0x1, and set its value to 0xff00 which then 
causes the test program to fail shortly afterwards. An example test run of an 
impacted system:
+ ubuntu@bionic:~$ gcc -Wall test.c -o cookie -lsystemd -g
+ ubuntu@bionic:~$ gdb --batch --command=test.gdb --args ./cookie
+ Breakpoint 1 at 0xe61: file test.c, line 38.
+ [Thread debugging using libthread_db enabled]
+ Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
+ (16s) cookie: 0x0001reply-cookie: 0x0001
+ 
+ Breakpoint 1, print_unit_path (bus=0x55757290) at test.c:38
+ 38  r = sd_bus_message_new_method_call(bus, ,
+ $1 = 0x1
+ $2 = 0xff00
+ Call failed: Operation not supported
+ Sleeping and retrying...
+ Call failed: Invalid argument
+ Assertion 'm->n_ref > 0' failed at 
../src/libsystemd/sd-bus/bus-message.c:934, function sd_bus_message_unref(). 
Aborting.
+ 
+ Program received signal SIGABRT, Aborted.
+ __GI_raise (sig=sig@entry=0x6) at ../sysdeps/unix/sysv/linux/raise.c:51
+ 51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
+ u
+ 
+ To compile and debug the test case above, libsystemd-dev and 
libsystemd0-dbgsym are required.
+ Both test.c and test.gdb source code are attached to this LP bug.
+ 
+ [Regression Potential]
+ This fix introduces some changes in the way cookie incrementation is handled. 
We now have a reduced number of available values, since the patch makes use of 
a high order bit to indicate whether we have overflowed or not. Potential 
issues could arise from two distinct messages repeating the cookie value, or 
from us not handling the cookie reuse properly. In practice, this shouldn't 
cause serious problems as most dbus messages should not stall long enough for a 
possible overlap in the 2^31 space. The patch has been present in other stable 
Ubuntu Series and upstream, and has been validated and tested through the 
systemd test suite and autopkgtests.

** Summary changed:

- cookie overruns cause org.freedesktop.systemd1 dbus to hang
+ cookie overruns can cause org.freedesktop.systemd1 dbus to hang

** Attachment added: "test.c"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1876600/+attachment/5366779/+files/test.c

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, 

[Touch-packages] [Bug 1876600] Re: cookie overruns cause org.freedesktop.systemd1 dbus to hang

2020-05-04 Thread Heitor Alves de Siqueira
** Also affects: systemd (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

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

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

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

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

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

** Changed in: systemd (Ubuntu Bionic)
 Assignee: (unassigned) => Heitor Alves de Siqueira (halves)

** Changed in: systemd (Ubuntu Xenial)
 Assignee: (unassigned) => Heitor Alves de Siqueira (halves)

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

Title:
  cookie overruns cause org.freedesktop.systemd1 dbus to hang

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Confirmed
Status in systemd source package in Bionic:
  Confirmed

Bug description:
  [Impact]
  Long-running services overflow the sd_bus->cookie counter, causing further 
communication with org.freedesktop.systemd1 to stall.

  [Description]
  Systemd dbus messages usually include a "cookie" value to uniquely identify 
them in their bus context. For services that run for longer periods of time and 
keep communicating through dbus, it's possible to overflow the cookie value, 
causing further messages to the org.freedesktop.systemd1 dbus to hang.

  This has been fixed upstream by the commit below:
  -  sd-bus: deal with cookie overruns (1f82f5bb4237)

  $ git describe --contains 1f82f5bb4237
  v242-rc1~228

  $ rmadison systemd
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.27 | xenial-security | source, ...
   systemd | 229-4ubuntu21.27 | xenial-updates  | source, ...
   systemd | 229-4ubuntu21.28 | xenial-proposed | source, ...
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.38 | bionic-security | source, ...
   systemd | 237-3ubuntu10.39 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <
   systemd | 242-7ubuntu3 | eoan| source, ...

  Releases starting with Eoan already have this fix.

  [Test Case]
  There doesn't seem to be an easy test case for this, as the cookie values 
start at zero and won't overflow until (1<<32). There have been reports from 
users hitting this on Kubernetes clusters continuously running for longer 
periods (~5 months).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1876600/+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 1876600] [NEW] cookie overruns cause org.freedesktop.systemd1 dbus to hang

2020-05-03 Thread Heitor Alves de Siqueira
Public bug reported:

[Impact]
Long-running services overflow the sd_bus->cookie counter, causing further 
communication with org.freedesktop.systemd1 to stall.

[Description]
Systemd dbus messages usually include a "cookie" value to uniquely identify 
them in their bus context. For services that run for longer periods of time and 
keep communicating through dbus, it's possible to overflow the cookie value, 
causing further messages to the org.freedesktop.systemd1 dbus to hang.

This has been fixed upstream by the commit below:
-  sd-bus: deal with cookie overruns (1f82f5bb4237)

$ git describe --contains 1f82f5bb4237
v242-rc1~228

$ rmadison systemd
 systemd | 229-4ubuntu4 | xenial  | source, ...
 systemd | 229-4ubuntu21.27 | xenial-security | source, ...
 systemd | 229-4ubuntu21.27 | xenial-updates  | source, ...
 systemd | 229-4ubuntu21.28 | xenial-proposed | source, ...
 systemd | 237-3ubuntu10| bionic  | source, ...
 systemd | 237-3ubuntu10.38 | bionic-security | source, ...
 systemd | 237-3ubuntu10.39 | bionic-updates  | source, ...
 systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <
 systemd | 242-7ubuntu3 | eoan| source, ...

Releases starting with Eoan already have this fix.

[Test Case]
There doesn't seem to be an easy test case for this, as the cookie values start 
at zero and won't overflow until (1<<32). There have been reports from users 
hitting this on Kubernetes clusters continuously running for longer periods (~5 
months).

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


** Tags: 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/1876600

Title:
  cookie overruns cause org.freedesktop.systemd1 dbus to hang

Status in systemd package in Ubuntu:
  New

Bug description:
  [Impact]
  Long-running services overflow the sd_bus->cookie counter, causing further 
communication with org.freedesktop.systemd1 to stall.

  [Description]
  Systemd dbus messages usually include a "cookie" value to uniquely identify 
them in their bus context. For services that run for longer periods of time and 
keep communicating through dbus, it's possible to overflow the cookie value, 
causing further messages to the org.freedesktop.systemd1 dbus to hang.

  This has been fixed upstream by the commit below:
  -  sd-bus: deal with cookie overruns (1f82f5bb4237)

  $ git describe --contains 1f82f5bb4237
  v242-rc1~228

  $ rmadison systemd
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.27 | xenial-security | source, ...
   systemd | 229-4ubuntu21.27 | xenial-updates  | source, ...
   systemd | 229-4ubuntu21.28 | xenial-proposed | source, ...
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.38 | bionic-security | source, ...
   systemd | 237-3ubuntu10.39 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.40 | bionic-proposed | source, ... <
   systemd | 242-7ubuntu3 | eoan| source, ...

  Releases starting with Eoan already have this fix.

  [Test Case]
  There doesn't seem to be an easy test case for this, as the cookie values 
start at zero and won't overflow until (1<<32). There have been reports from 
users hitting this on Kubernetes clusters continuously running for longer 
periods (~5 months).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1876600/+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 1410558] Re: ps doesn't support "thcount" format specifier on Xenial

2020-03-17 Thread Heitor Alves de Siqueira
Given this is an extremely simple fix to the procps output flags, none of the 
autopkgtest regressions seem to be a result of this patch.
More details on each reported regression:

* apport/2.20.1-0ubuntu2.21 (amd64/i386)
- has failed since 2.20.1-0ubuntu2.18 according to [0]
- test_sandbox_cache_options: fails due to "ERROR: Package download error, try 
again later: Untrusted packages:"
- test_get_logind_session: fails due to a systemd-logind error
- test_core_dump_packaged, test_core_dump_unpackaged: fail with "leaves 
unexpected core file behind"
- test_crash_setuid_drop, test_crash_setuid_keep, 
test_crash_setuid_nonwritable_cwd, test_lock_symlink: fail to generate reports
- test_run_crash_kernel: fails due to an URL mismatch 
(http://linux-signed.bugs.example.com/5 vs http://linux.bugs.example.com/5)

* cmake/3.5.1-1ubuntu3 (armhf)
- retest could fix the proxy error
- CTestTestUpload: fails due to resolve error ("squid.internal" proxy)

* livecd-rootfs/2.408.57 (amd64/i386)
- tests timed out, a re-test should clear this regression

* openssh/1:7.2p2-4ubuntu2.8 (amd64/arm64/i386)
- failed due to host key certification, re-test should also clear this one

[0] http://autopkgtest.ubuntu.com/packages/a/apport/xenial/amd64

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

Title:
  ps doesn't support "thcount" format specifier on Xenial

Status in procps package in Ubuntu:
  Fix Released
Status in procps source package in Xenial:
  Fix Committed

Bug description:
  [Impact]
  ps -o thcount prints out an error (error: unknown user-defined format 
specifier "thcount")

  [Description]
  The Xenial version of procps has a bug in the thcount format specifier. ps 
doesn't recognize it, and complains about an unknown user-defined format.
  This is due to the format specifier table in ps/output.c, which is queried 
with a binary search. Since the "thcount" entry appears out of order in Xenial, 
it can't be looked up and the program fails with the "unknown user-defined 
format specifier" error.

  This has been fixed upstream by the commit below:
  - Fix for Bug:1174313 (3a52dfa34027)

  $ git describe --contains 3a52dfa34027
  v3.3.12~58^2

  $ rmadison procps
   procps | 2:3.3.10-4ubuntu2   | xenial  | source, ...
   procps | 2:3.3.10-4ubuntu2.4 | xenial-security | source, ...
   procps | 2:3.3.10-4ubuntu2.4 | xenial-updates  | source, ... <
   procps | 2:3.3.12-3ubuntu1   | bionic  | source, ...
   procps | 2:3.3.12-3ubuntu1.1 | bionic-security | source, ...
   procps | 2:3.3.12-3ubuntu1.2 | bionic-updates  | source, ...

  Releases starting with Bionic already have this fix, so it's only
  needed for Xenial.

  [Test case]
  1. Boot up a Xenial environment with e.g. an lxd container:
  # lxc launch images:ubuntu/xenial xenial

  2. Execute ps with the '-o thcount' options:
  # lxc exec xenial -- ps -o thcount
  error: unknown user-defined format specifier "thcount"

  Usage:
   ps [options]

   Try 'ps --help '
    or 'ps --help '
   for additional help text.

  For more details see ps(1).

  [Regression Potential]
  The fix just fixes the order of two entries in the format specifier array, so 
the regression potential is very low. Furthermore, the patch has been present 
and tested in up-to-date versions of procps since Bionic. Any new regressions 
introduced in Xenial will be checked with autopkgtest.

  [Original Description]
  In Ubuntu 12.04.5 LTS (procps 1:3.2.8-11ubuntu6.3), the following worked fine:

  $ export PS_FORMAT=thcount
  $ ps
  THCNT
  1
  1

  In Ubuntu 14.04.1 LTS (procps 1:3.3.9-1ubuntu2), it does not work
  anymore:

  $ export PS_FORMAT=thcount
  $ ps
  warning: $PS_FORMAT ignored. (unknown user-defined format specifier "thcount")
    PID TTY  TIME CMD
   6593 pts/100:00:00 ps
  16633 pts/100:00:00 bash

  Other PS_FORMAT specifiers still work fine (I have tried many, but not
  all).

  In real-life usage, a more complex PS_FORMAT would of course be used,
  such as
  
PS_FORMAT=pid,s,thcount,nice,euser,egroup,etime,cputime,%mem,rssize:6,size:7,vsize:7,command

  Workaround: use nlwp instead of thcount (they are alias to the same
  data, and nlwp works fine in both versions).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1410558/+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 1410558] Re: ps doesn't support "thcount" format specifier on Xenial

2020-03-05 Thread Heitor Alves de Siqueira
Verified according to test case from description:

ubuntu@xenial:~$ dpkg -l | grep procps
ii  procps   2:3.3.10-4ubuntu2.5
amd64/proc file system utilities

ubuntu@xenial:~$ ps -o thcount
THCNT
1
1

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

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

Title:
  ps doesn't support "thcount" format specifier on Xenial

Status in procps package in Ubuntu:
  Fix Released
Status in procps source package in Xenial:
  Fix Committed

Bug description:
  [Impact]
  ps -o thcount prints out an error (error: unknown user-defined format 
specifier "thcount")

  [Description]
  The Xenial version of procps has a bug in the thcount format specifier. ps 
doesn't recognize it, and complains about an unknown user-defined format.
  This is due to the format specifier table in ps/output.c, which is queried 
with a binary search. Since the "thcount" entry appears out of order in Xenial, 
it can't be looked up and the program fails with the "unknown user-defined 
format specifier" error.

  This has been fixed upstream by the commit below:
  - Fix for Bug:1174313 (3a52dfa34027)

  $ git describe --contains 3a52dfa34027
  v3.3.12~58^2

  $ rmadison procps
   procps | 2:3.3.10-4ubuntu2   | xenial  | source, ...
   procps | 2:3.3.10-4ubuntu2.4 | xenial-security | source, ...
   procps | 2:3.3.10-4ubuntu2.4 | xenial-updates  | source, ... <
   procps | 2:3.3.12-3ubuntu1   | bionic  | source, ...
   procps | 2:3.3.12-3ubuntu1.1 | bionic-security | source, ...
   procps | 2:3.3.12-3ubuntu1.2 | bionic-updates  | source, ...

  Releases starting with Bionic already have this fix, so it's only
  needed for Xenial.

  [Test case]
  1. Boot up a Xenial environment with e.g. an lxd container:
  # lxc launch images:ubuntu/xenial xenial

  2. Execute ps with the '-o thcount' options:
  # lxc exec xenial -- ps -o thcount
  error: unknown user-defined format specifier "thcount"

  Usage:
   ps [options]

   Try 'ps --help '
    or 'ps --help '
   for additional help text.

  For more details see ps(1).

  [Regression Potential]
  The fix just fixes the order of two entries in the format specifier array, so 
the regression potential is very low. Furthermore, the patch has been present 
and tested in up-to-date versions of procps since Bionic. Any new regressions 
introduced in Xenial will be checked with autopkgtest.

  [Original Description]
  In Ubuntu 12.04.5 LTS (procps 1:3.2.8-11ubuntu6.3), the following worked fine:

  $ export PS_FORMAT=thcount
  $ ps
  THCNT
  1
  1

  In Ubuntu 14.04.1 LTS (procps 1:3.3.9-1ubuntu2), it does not work
  anymore:

  $ export PS_FORMAT=thcount
  $ ps
  warning: $PS_FORMAT ignored. (unknown user-defined format specifier "thcount")
    PID TTY  TIME CMD
   6593 pts/100:00:00 ps
  16633 pts/100:00:00 bash

  Other PS_FORMAT specifiers still work fine (I have tried many, but not
  all).

  In real-life usage, a more complex PS_FORMAT would of course be used,
  such as
  
PS_FORMAT=pid,s,thcount,nice,euser,egroup,etime,cputime,%mem,rssize:6,size:7,vsize:7,command

  Workaround: use nlwp instead of thcount (they are alias to the same
  data, and nlwp works fine in both versions).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1410558/+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 1410558] Re: ps doesn't support "thcount" format specifier on Xenial

2020-02-15 Thread Heitor Alves de Siqueira
** Description changed:

  [Impact]
- ps -o thcount doesn't print out an error (error: unknown user-defined format 
specifier "thcount")
+ ps -o thcount prints out an error (error: unknown user-defined format 
specifier "thcount")
  
  [Description]
  The Xenial version of procps has a bug in the thcount format specifier. ps 
doesn't recognize it, and complains about an unknown user-defined format.
  This is due to the format specifier table in ps/output.c, which is queried 
with a binary search. Since the "thcount" entry appears out of order in Xenial, 
it can't be looked up and the program fails with the "unknown user-defined 
format specifier" error.
  
  This has been fixed upstream by the commit below:
  - Fix for Bug:1174313 (3a52dfa34027)
  
  $ git describe --contains 3a52dfa34027
  v3.3.12~58^2
  
  $ rmadison procps
-  procps | 2:3.3.10-4ubuntu2   | xenial  | source, ...
-  procps | 2:3.3.10-4ubuntu2.4 | xenial-security | source, ...
-  procps | 2:3.3.10-4ubuntu2.4 | xenial-updates  | source, ... <
-  procps | 2:3.3.12-3ubuntu1   | bionic  | source, ...
-  procps | 2:3.3.12-3ubuntu1.1 | bionic-security | source, ...
-  procps | 2:3.3.12-3ubuntu1.2 | bionic-updates  | source, ...
+  procps | 2:3.3.10-4ubuntu2   | xenial  | source, ...
+  procps | 2:3.3.10-4ubuntu2.4 | xenial-security | source, ...
+  procps | 2:3.3.10-4ubuntu2.4 | xenial-updates  | source, ... <
+  procps | 2:3.3.12-3ubuntu1   | bionic  | source, ...
+  procps | 2:3.3.12-3ubuntu1.1 | bionic-security | source, ...
+  procps | 2:3.3.12-3ubuntu1.2 | bionic-updates  | source, ...
  
  Releases starting with Bionic already have this fix, so it's only needed
  for Xenial.
  
  [Test case]
  1. Boot up a Xenial environment with e.g. an lxd container:
  # lxc launch images:ubuntu/xenial xenial
  
  2. Execute ps with the '-o thcount' options:
  # lxc exec xenial -- ps -o thcount
  error: unknown user-defined format specifier "thcount"
  
  Usage:
-  ps [options]
+  ps [options]
  
-  Try 'ps --help '
-   or 'ps --help '
-  for additional help text.
+  Try 'ps --help '
+   or 'ps --help '
+  for additional help text.
  
  For more details see ps(1).
  
  [Regression Potential]
  The fix just fixes the order of two entries in the format specifier array, so 
the regression potential is very low. Furthermore, the patch has been present 
and tested in up-to-date versions of procps since Bionic. Any new regressions 
introduced in Xenial will be checked with autopkgtest.
  
  [Original Description]
  In Ubuntu 12.04.5 LTS (procps 1:3.2.8-11ubuntu6.3), the following worked fine:
  
  $ export PS_FORMAT=thcount
  $ ps
  THCNT
  1
  1
  
  In Ubuntu 14.04.1 LTS (procps 1:3.3.9-1ubuntu2), it does not work
  anymore:
  
  $ export PS_FORMAT=thcount
  $ ps
  warning: $PS_FORMAT ignored. (unknown user-defined format specifier "thcount")
    PID TTY  TIME CMD
   6593 pts/100:00:00 ps
  16633 pts/100:00:00 bash
  
  Other PS_FORMAT specifiers still work fine (I have tried many, but not
  all).
  
  In real-life usage, a more complex PS_FORMAT would of course be used,
  such as
  
PS_FORMAT=pid,s,thcount,nice,euser,egroup,etime,cputime,%mem,rssize:6,size:7,vsize:7,command
  
  Workaround: use nlwp instead of thcount (they are alias to the same
  data, and nlwp works fine in both versions).

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

Title:
  ps doesn't support "thcount" format specifier on Xenial

Status in procps package in Ubuntu:
  Fix Released
Status in procps source package in Xenial:
  In Progress

Bug description:
  [Impact]
  ps -o thcount prints out an error (error: unknown user-defined format 
specifier "thcount")

  [Description]
  The Xenial version of procps has a bug in the thcount format specifier. ps 
doesn't recognize it, and complains about an unknown user-defined format.
  This is due to the format specifier table in ps/output.c, which is queried 
with a binary search. Since the "thcount" entry appears out of order in Xenial, 
it can't be looked up and the program fails with the "unknown user-defined 
format specifier" error.

  This has been fixed upstream by the commit below:
  - Fix for Bug:1174313 (3a52dfa34027)

  $ git describe --contains 3a52dfa34027
  v3.3.12~58^2

  $ rmadison procps
   procps | 2:3.3.10-4ubuntu2   | xenial  | source, ...
   procps | 2:3.3.10-4ubuntu2.4 | xenial-security | source, ...
   procps | 2:3.3.10-4ubuntu2.4 | xenial-updates  | source, ... <
   procps | 2:3.3.12-3ubuntu1   | bionic  | source, ...
   procps | 2:3.3.12-3ubuntu1.1 | bionic-security | source, ...
   procps | 2:3.3.12-3ubuntu1.2 | bionic-updates  | source, ...

  Releases starting with Bionic already have this fix, so it's only
  needed for Xenial.

  [Test case]
  1. Boot up a Xenial environment with e.g. an lxd 

[Touch-packages] [Bug 1410558] Re: PS_FORMAT=thcount does not work anymore

2020-02-05 Thread Heitor Alves de Siqueira
** Tags added: sts

** Description changed:

- In Ubuntu 12.04.5 LTS (procps 1:3.2.8-11ubuntu6.3), the following worked
- fine:
+ [Impact]
+ ps -o thcount doesn't print out an error (error: unknown user-defined format 
specifier "thcount")
+ 
+ [Description]
+ The Xenial version of procps has a bug in the thcount format specifier. ps 
doesn't recognize it, and complains about an unknown user-defined format.
+ This is due to the format specifier table in ps/output.c, which is queried 
with a binary search. Since the "thcount" entry appears out of order in Xenial, 
it can't be looked up and the program fails with the "unknown user-defined 
format specifier" error.
+ 
+ This has been fixed upstream by the commit below:
+ - Fix for Bug:1174313 (3a52dfa34027)
+ 
+ $ git describe --contains 3a52dfa34027
+ v3.3.12~58^2
+ 
+ $ rmadison procps
+  procps | 2:3.3.10-4ubuntu2   | xenial  | source, ...
+  procps | 2:3.3.10-4ubuntu2.4 | xenial-security | source, ...
+  procps | 2:3.3.10-4ubuntu2.4 | xenial-updates  | source, ... <
+  procps | 2:3.3.12-3ubuntu1   | bionic  | source, ...
+  procps | 2:3.3.12-3ubuntu1.1 | bionic-security | source, ...
+  procps | 2:3.3.12-3ubuntu1.2 | bionic-updates  | source, ...
+ 
+ Releases starting with Bionic already have this fix, so it's only needed
+ for Xenial.
+ 
+ [Test case]
+ 1. Boot up a Xenial environment with e.g. an lxd container:
+ # lxc launch images:ubuntu/xenial xenial
+ 
+ 2. Execute ps with the '-o thcount' options:
+ # lxc exec xenial -- ps -o thcount
+ error: unknown user-defined format specifier "thcount"
+ 
+ Usage:
+  ps [options]
+ 
+  Try 'ps --help '
+   or 'ps --help '
+  for additional help text.
+ 
+ For more details see ps(1).
+ 
+ [Regression Potential]
+ The fix just fixes the order of two entries in the format specifier array, so 
the regression potential is very low. Furthermore, the patch has been present 
and tested in up-to-date versions of procps since Bionic. Any new regressions 
introduced in Xenial will be checked with autopkgtest.
+ 
+ [Original Description]
+ In Ubuntu 12.04.5 LTS (procps 1:3.2.8-11ubuntu6.3), the following worked fine:
  
  $ export PS_FORMAT=thcount
  $ ps
  THCNT
- 1
- 1
+ 1
+ 1
  
  In Ubuntu 14.04.1 LTS (procps 1:3.3.9-1ubuntu2), it does not work
  anymore:
  
  $ export PS_FORMAT=thcount
  $ ps
  warning: $PS_FORMAT ignored. (unknown user-defined format specifier "thcount")
-   PID TTY  TIME CMD
-  6593 pts/100:00:00 ps
+   PID TTY  TIME CMD
+  6593 pts/100:00:00 ps
  16633 pts/100:00:00 bash
  
  Other PS_FORMAT specifiers still work fine (I have tried many, but not
  all).
  
  In real-life usage, a more complex PS_FORMAT would of course be used,
  such as
  
PS_FORMAT=pid,s,thcount,nice,euser,egroup,etime,cputime,%mem,rssize:6,size:7,vsize:7,command
  
  Workaround: use nlwp instead of thcount (they are alias to the same
  data, and nlwp works fine in both versions).

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

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

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

** Changed in: procps (Ubuntu Xenial)
 Assignee: (unassigned) => Heitor Alves de Siqueira (halves)

** Summary changed:

- PS_FORMAT=thcount does not work anymore
+ ps doesn't support "thcount" format specifier on Xenial

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

Title:
  ps doesn't support "thcount" format specifier on Xenial

Status in procps package in Ubuntu:
  Fix Released
Status in procps source package in Xenial:
  In Progress

Bug description:
  [Impact]
  ps -o thcount doesn't print out an error (error: unknown user-defined format 
specifier "thcount")

  [Description]
  The Xenial version of procps has a bug in the thcount format specifier. ps 
doesn't recognize it, and complains about an unknown user-defined format.
  This is due to the format specifier table in ps/output.c, which is queried 
with a binary search. Since the "thcount" entry appears out of order in Xenial, 
it can't be looked up and the program fails with the "unknown user-defined 
format specifier" error.

  This has been fixed upstream by the commit below:
  - Fix for Bug:1174313 (3a52dfa34027)

  $ git describe --contains 3a52dfa34027
  v3.3.12~58^2

  $ rmadison procps
   procps | 2:3.3.10-4ubuntu2   | xenial  | source, ...
   procps | 2:3.3.10-4ubuntu2.4 | xenial-security | source, ...
   procps | 2:3.3.10-4ubuntu2.4 | xenial-updates  | source, ... <
   procps | 2:3.3.12-3ubuntu1   | bionic  | source, ...
   procps | 2:3.3.12-3ubuntu1.1 | bionic-security | source, ...
   procps | 2:3.3.12-3ubun

[Touch-packages] [Bug 1846787] Re: systemd-logind leaves leftover sessions and scope files

2019-10-07 Thread Heitor Alves de Siqueira
** Description changed:

  [Impact]
  Scope file leakage can cause SSH delays and reduce performance in systemd
  
  [Description]
  The current systemd-logind version present in Xenial can leave abandoned SSH
  sessions and scope files in cases where the host sees a lot of concurrent SSH
  connections. These leftover sessions can slow down systemd performance
  greatly, and can have an impact on sshd handling a great number of concurrent
  connections.
  
  To fix this issue, patches are needed in both dbus and systemd. These improve 
the
  performance of the communication between dbus and systemd, so that they can
  handle a better volume of events (e.g. SSH logins). All of those patches are
  already present from Bionic onwards, so we only need those fixes for Xenial.
  
  == Systemd ==
  Upstream patches:
  - core: use an AF_UNIX/SOCK_DGRAM socket for cgroup agent notification 
(d8fdc62037b5)
  
  $ git describe --contains d8fdc62037b5
  v230~71^2~2
  
  $ rmadison systemd
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.21 | xenial-security | source, ...
   systemd | 229-4ubuntu21.22 | xenial-updates  | source, ... <
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.29 | bionic-security | source, ...
   systemd | 237-3ubuntu10.29 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.31 | bionic-proposed | source, ...
  
  == DBus ==
  Upstream patches:
  - Only read one message at a time if there are fds pending (892f084eeda0)
  - bus: Fix timeout restarts  (529600397bca)
  - DBusMainLoop: ensure all required timeouts are restarted (446b0d9ac75a)
  
  $ git describe --contains 892f084eeda0 529600397bca 446b0d9ac75a
  dbus-1.11.10~44
  dbus-1.11.10~45
  dbus-1.11.16~2
  
  $ rmadison dbus
   dbus | 1.10.6-1ubuntu3| xenial   | source, ...
   dbus | 1.10.6-1ubuntu3.4  | xenial-security  | source, ...
   dbus | 1.10.6-1ubuntu3.4  | xenial-updates   | source, ... <
   dbus | 1.12.2-1ubuntu1| bionic   | source, ...
   dbus | 1.12.2-1ubuntu1.1  | bionic-security  | source, ...
   dbus | 1.12.2-1ubuntu1.1  | bionic-updates   | source, ...
  
  [Test Case]
  1) Simulate a lot of concurrent SSH connections with e.g. a for loop:
  multipass@xenial-logind:~$ for i in {1..1000}; do sleep 0.1; ssh localhost 
sleep 1 & done
  
  2) Check for leaked sessions in /run/systemd/system/:
  multipass@xenial-logind:~$ ls -ld /run/systemd/system/session-*.scope*
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-103.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-104.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-105.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-106.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-110.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-111.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-112.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-113.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-114.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-115.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-116.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-117.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-118.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-119.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-120.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-121.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-122.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-123.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-126.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-131.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-134.scope.d
  ...
  
  [Regression Potential]
- The regression potential is low, as these patches have seen extensive testing
- both upstream and in more recent releases of Ubuntu. Nonetheless, these new
- packages will be rigorously tested through autopkgtest to avoid any possible
- Xenial-specific regressions.
+ As the patches change the communication socket between dbus and systemd, 
possible regressions could cause systemd to not be notified of dbus events and 
vice-versa. We could see units not getting started properly, and communication 
between different services break down (e.g. between systemd-logind and other 
processes).
+ 
+ In this case, the regression potential should be low as these patches
+ have seen extensive testing both upstream and in more recent releases of
+ Ubuntu. 

[Touch-packages] [Bug 1846787] Re: systemd-logind leaves leftover sessions and scope files

2019-10-07 Thread Heitor Alves de Siqueira
** Description changed:

  [Impact]
  Scope file leakage can cause SSH delays and reduce performance in systemd
  
  [Description]
  The current systemd-logind version present in Xenial can leave abandoned SSH
  sessions and scope files in cases where the host sees a lot of concurrent SSH
  connections. These leftover sessions can slow down systemd performance
  greatly, and can have an impact on sshd handling a great number of concurrent
  connections.
  
  To fix this issue, patches are needed in both dbus and systemd. These improve 
the
  performance of the communication between dbus and systemd, so that they can
  handle a better volume of events (e.g. SSH logins). All of those patches are
  already present from Bionic onwards, so we only need those fixes for Xenial.
  
  == Systemd ==
  Upstream patches:
  - core: use an AF_UNIX/SOCK_DGRAM socket for cgroup agent notification 
(d8fdc62037b5)
- - tree-wide: introduce new SOCKADDR_UN_LEN() macro, and use it everywhere 
(fc2fffe7706e)
- - journald: stack allocation cannot fail (23be5709e10b)
  
- $ git describe --contains d8fdc62037b5 fc2fffe7706e 23be5709e10b
+ $ git describe --contains d8fdc62037b5
  v230~71^2~2
- v230~71^2~1
- v230~71^2
  
  $ rmadison systemd
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.21 | xenial-security | source, ...
   systemd | 229-4ubuntu21.22 | xenial-updates  | source, ... <
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.29 | bionic-security | source, ...
   systemd | 237-3ubuntu10.29 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.31 | bionic-proposed | source, ...
  
  == DBus ==
  Upstream patches:
  - Only read one message at a time if there are fds pending (892f084eeda0)
  - bus: Fix timeout restarts  (529600397bca)
  - DBusMainLoop: ensure all required timeouts are restarted (446b0d9ac75a)
  
  $ git describe --contains 892f084eeda0 529600397bca 446b0d9ac75a
  dbus-1.11.10~44
  dbus-1.11.10~45
  dbus-1.11.16~2
  
  $ rmadison dbus
   dbus | 1.10.6-1ubuntu3| xenial   | source, ...
   dbus | 1.10.6-1ubuntu3.4  | xenial-security  | source, ...
   dbus | 1.10.6-1ubuntu3.4  | xenial-updates   | source, ... <
   dbus | 1.12.2-1ubuntu1| bionic   | source, ...
   dbus | 1.12.2-1ubuntu1.1  | bionic-security  | source, ...
   dbus | 1.12.2-1ubuntu1.1  | bionic-updates   | source, ...
  
  [Test Case]
  1) Simulate a lot of concurrent SSH connections with e.g. a for loop:
  multipass@xenial-logind:~$ for i in {1..1000}; do sleep 0.1; ssh localhost 
sleep 1 & done
  
  2) Check for leaked sessions in /run/systemd/system/:
  multipass@xenial-logind:~$ ls -ld /run/systemd/system/session-*.scope*
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-103.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-104.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-105.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-106.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-110.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-111.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-112.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-113.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-114.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-115.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-116.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-117.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-118.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-119.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-120.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-121.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-122.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-123.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-126.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-131.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-134.scope.d
  ...
  
  [Regression Potential]
  The regression potential is low, as these patches have seen extensive testing
  both upstream and in more recent releases of Ubuntu. Nonetheless, these new
  packages will be rigorously tested through autopkgtest to avoid any possible
  Xenial-specific regressions.

** Tags added: sts-sponsor

** Patch added: "lp1846787-dbus-xenial.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1846787/+attachment/5295136/+files/lp1846787-dbus-xenial.debdiff

-- 
You received this bug notification 

[Touch-packages] [Bug 1846787] Re: systemd-logind leaves leftover sessions and scope files

2019-10-07 Thread Heitor Alves de Siqueira
** Patch added: "lp1846787-systemd-xenial.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/dbus/+bug/1846787/+attachment/5295137/+files/lp1846787-systemd-xenial.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/1846787

Title:
  systemd-logind leaves leftover sessions and scope files

Status in dbus package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in dbus source package in Xenial:
  In Progress
Status in systemd source package in Xenial:
  In Progress

Bug description:
  [Impact]
  Scope file leakage can cause SSH delays and reduce performance in systemd

  [Description]
  The current systemd-logind version present in Xenial can leave abandoned SSH
  sessions and scope files in cases where the host sees a lot of concurrent SSH
  connections. These leftover sessions can slow down systemd performance
  greatly, and can have an impact on sshd handling a great number of concurrent
  connections.

  To fix this issue, patches are needed in both dbus and systemd. These improve 
the
  performance of the communication between dbus and systemd, so that they can
  handle a better volume of events (e.g. SSH logins). All of those patches are
  already present from Bionic onwards, so we only need those fixes for Xenial.

  == Systemd ==
  Upstream patches:
  - core: use an AF_UNIX/SOCK_DGRAM socket for cgroup agent notification 
(d8fdc62037b5)

  $ git describe --contains d8fdc62037b5
  v230~71^2~2

  $ rmadison systemd
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.21 | xenial-security | source, ...
   systemd | 229-4ubuntu21.22 | xenial-updates  | source, ... <
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.29 | bionic-security | source, ...
   systemd | 237-3ubuntu10.29 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.31 | bionic-proposed | source, ...

  == DBus ==
  Upstream patches:
  - Only read one message at a time if there are fds pending (892f084eeda0)
  - bus: Fix timeout restarts  (529600397bca)
  - DBusMainLoop: ensure all required timeouts are restarted (446b0d9ac75a)

  $ git describe --contains 892f084eeda0 529600397bca 446b0d9ac75a
  dbus-1.11.10~44
  dbus-1.11.10~45
  dbus-1.11.16~2

  $ rmadison dbus
   dbus | 1.10.6-1ubuntu3| xenial   | source, ...
   dbus | 1.10.6-1ubuntu3.4  | xenial-security  | source, ...
   dbus | 1.10.6-1ubuntu3.4  | xenial-updates   | source, ... <
   dbus | 1.12.2-1ubuntu1| bionic   | source, ...
   dbus | 1.12.2-1ubuntu1.1  | bionic-security  | source, ...
   dbus | 1.12.2-1ubuntu1.1  | bionic-updates   | source, ...

  [Test Case]
  1) Simulate a lot of concurrent SSH connections with e.g. a for loop:
  multipass@xenial-logind:~$ for i in {1..1000}; do sleep 0.1; ssh localhost 
sleep 1 & done

  2) Check for leaked sessions in /run/systemd/system/:
  multipass@xenial-logind:~$ ls -ld /run/systemd/system/session-*.scope*
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-103.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-104.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-105.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-106.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-110.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-111.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-112.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-113.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-114.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-115.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-116.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-117.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-118.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-119.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-120.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-121.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-122.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-123.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-126.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-131.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-134.scope.d
  ...

  [Regression Potential]
  The regression potential is low, as these patches have seen extensive testing
  both upstream and in more recent releases of Ubuntu. 

[Touch-packages] [Bug 1846787] Re: systemd-logind leaves leftover sessions and scope files

2019-10-07 Thread Heitor Alves de Siqueira
** Changed in: dbus (Ubuntu Xenial)
   Status: New => In Progress

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

** Description changed:

  [Impact]
  Scope file leakage can cause SSH delays and reduce performance in systemd
  
  [Description]
  The current systemd-logind version present in Xenial can leave abandoned SSH
  sessions and scope files in cases where the host sees a lot of concurrent SSH
  connections. These leftover sessions can slow down systemd performance
  greatly, and can have an impact on sshd handling a great number of concurrent
  connections.
  
  To fix this issue, patches are needed in both dbus and systemd. These improve 
the
  performance of the communication between dbus and systemd, so that they can
  handle a better volume of events (e.g. SSH logins). All of those patches are
  already present from Bionic onwards, so we only need those fixes for Xenial.
  
  == Systemd ==
  Upstream patches:
  - core: use an AF_UNIX/SOCK_DGRAM socket for cgroup agent notification 
(d8fdc62037b5)
  - tree-wide: introduce new SOCKADDR_UN_LEN() macro, and use it everywhere 
(fc2fffe7706e)
  - journald: stack allocation cannot fail (23be5709e10b)
  
  $ git describe --contains d8fdc62037b5 fc2fffe7706e 23be5709e10b
  v230~71^2~2
  v230~71^2~1
  v230~71^2
  
  $ rmadison systemd
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.21 | xenial-security | source, ...
   systemd | 229-4ubuntu21.22 | xenial-updates  | source, ... <
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.29 | bionic-security | source, ...
   systemd | 237-3ubuntu10.29 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.31 | bionic-proposed | source, ...
  
  == DBus ==
  Upstream patches:
  - Only read one message at a time if there are fds pending (892f084eeda0)
  - bus: Fix timeout restarts  (529600397bca)
  - DBusMainLoop: ensure all required timeouts are restarted (446b0d9ac75a)
  
  $ git describe --contains 892f084eeda0 529600397bca 446b0d9ac75a
  dbus-1.11.10~44
  dbus-1.11.10~45
  dbus-1.11.16~2
  
  $ rmadison dbus
   dbus | 1.10.6-1ubuntu3| xenial   | source, ...
   dbus | 1.10.6-1ubuntu3.4  | xenial-security  | source, ...
   dbus | 1.10.6-1ubuntu3.4  | xenial-updates   | source, ... <
   dbus | 1.12.2-1ubuntu1| bionic   | source, ...
   dbus | 1.12.2-1ubuntu1.1  | bionic-security  | source, ...
   dbus | 1.12.2-1ubuntu1.1  | bionic-updates   | source, ...
  
  [Test Case]
  1) Simulate a lot of concurrent SSH connections with e.g. a for loop:
- multipass@xenial-logind:~$ for i in {1..1000}; do sleep 0.1; ssh localhost 
sleep 1 > /dev/null & done
+ multipass@xenial-logind:~$ for i in {1..1000}; do sleep 0.1; ssh localhost 
sleep 1 & done
  
  2) Check for leaked sessions in /run/systemd/system/:
  multipass@xenial-logind:~$ ls -ld /run/systemd/system/session-*.scope*
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-103.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-104.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-105.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-106.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-110.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-111.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-112.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-113.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-114.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-115.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-116.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-117.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-118.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-119.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-120.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-121.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-122.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-123.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-126.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-131.scope.d
  drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-134.scope.d
  ...
  
  [Regression Potential]
  The regression potential is low, as these patches have seen extensive testing
  both upstream and in more recent releases of Ubuntu. Nonetheless, these new
  packages will be rigorously tested through autopkgtest to avoid any possible
  Xenial-specific regressions.

-- 
You received this bug 

[Touch-packages] [Bug 1846787] [NEW] systemd-logind leaves leftover sessions and scope files

2019-10-04 Thread Heitor Alves de Siqueira
Public bug reported:

[Impact]
Scope file leakage can cause SSH delays and reduce performance in systemd

[Description]
The current systemd-logind version present in Xenial can leave abandoned SSH
sessions and scope files in cases where the host sees a lot of concurrent SSH
connections. These leftover sessions can slow down systemd performance
greatly, and can have an impact on sshd handling a great number of concurrent
connections.

To fix this issue, patches are needed in both dbus and systemd. These improve 
the
performance of the communication between dbus and systemd, so that they can
handle a better volume of events (e.g. SSH logins). All of those patches are
already present from Bionic onwards, so we only need those fixes for Xenial.

== Systemd ==
Upstream patches:
- core: use an AF_UNIX/SOCK_DGRAM socket for cgroup agent notification 
(d8fdc62037b5)
- tree-wide: introduce new SOCKADDR_UN_LEN() macro, and use it everywhere 
(fc2fffe7706e)
- journald: stack allocation cannot fail (23be5709e10b)

$ git describe --contains d8fdc62037b5 fc2fffe7706e 23be5709e10b
v230~71^2~2
v230~71^2~1
v230~71^2

$ rmadison systemd
 systemd | 229-4ubuntu4 | xenial  | source, ...
 systemd | 229-4ubuntu21.21 | xenial-security | source, ...
 systemd | 229-4ubuntu21.22 | xenial-updates  | source, ... <
 systemd | 237-3ubuntu10| bionic  | source, ...
 systemd | 237-3ubuntu10.29 | bionic-security | source, ...
 systemd | 237-3ubuntu10.29 | bionic-updates  | source, ...
 systemd | 237-3ubuntu10.31 | bionic-proposed | source, ...

== DBus ==
Upstream patches:
- Only read one message at a time if there are fds pending (892f084eeda0)
- bus: Fix timeout restarts  (529600397bca)
- DBusMainLoop: ensure all required timeouts are restarted (446b0d9ac75a)

$ git describe --contains 892f084eeda0 529600397bca 446b0d9ac75a
dbus-1.11.10~44
dbus-1.11.10~45
dbus-1.11.16~2

$ rmadison dbus
 dbus | 1.10.6-1ubuntu3| xenial   | source, ...
 dbus | 1.10.6-1ubuntu3.4  | xenial-security  | source, ...
 dbus | 1.10.6-1ubuntu3.4  | xenial-updates   | source, ... <
 dbus | 1.12.2-1ubuntu1| bionic   | source, ...
 dbus | 1.12.2-1ubuntu1.1  | bionic-security  | source, ...
 dbus | 1.12.2-1ubuntu1.1  | bionic-updates   | source, ...

[Test Case]
1) Simulate a lot of concurrent SSH connections with e.g. a for loop:
multipass@xenial-logind:~$ for i in {1..1000}; do sleep 0.1; ssh localhost 
sleep 1 > /dev/null & done

2) Check for leaked sessions in /run/systemd/system/:
multipass@xenial-logind:~$ ls -ld /run/systemd/system/session-*.scope*
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-103.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-104.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-105.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-106.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-110.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-111.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-112.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-113.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-114.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-115.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-116.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-117.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-118.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-119.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-120.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-121.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-122.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-123.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-126.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-131.scope.d
drwxr-xr-x 2 root root 160 Oct 4 15:34 /run/systemd/system/session-134.scope.d
...

[Regression Potential]
The regression potential is low, as these patches have seen extensive testing
both upstream and in more recent releases of Ubuntu. Nonetheless, these new
packages will be rigorously tested through autopkgtest to avoid any possible
Xenial-specific regressions.

** Affects: dbus (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Affects: dbus (Ubuntu Xenial)
 Importance: Undecided
     Assignee: Heitor Alves de Siqueira (halves)
 Status: New

** Affects: systemd (Ubuntu Xenial)
 Importance: Undecided
     Assignee: Heitor Alves de Siqueira (halves)
 Status: New


[Touch-packages] [Bug 1818527] Re: Stub resolver cache is corrupted

2019-06-18 Thread Heitor Alves de Siqueira
Some comments on the Autopkgtest regressions:

- lxc (armhf) fails due to the ftpmaster.internal mirror failing

- libvirt (armhf) fails for the same reason ("Unable to connect to
ftpmaster.internal:http")

- systemd (ppc64el) has been failing since before this patch was
introduced, and looking at the test logs it doesn't seem to be related
to the stub resolver

- network-manager (arm64) has been failing since previous systemd
versions (since systemd/237-3ubuntu10.21)

- gvfs (arm64) fails due to a permission error that should be unrelated
to the stub resolver ("GLib.Error('Not authorized to perform ope[83
chars]', 0) != True")

- gvfs (i386) has been failing since before this patch was introduced

After going through the autopkgtest logs for the above, it seems that
the failures are either due to autopkgtest infra, or have been
introduced by something other than the systemd upload.

** 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 systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1818527

Title:
  Stub resolver cache is corrupted

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  Fix Committed

Bug description:
  [Impact]
  systemd-resolved fails to resolve A records

  [Description]
  When systemd-resolve caches a non-existent CNAME record for a specific 
domain, further attempts at resolving A records for that same domain  fail. 
This has been fixed upstream in v240.

  Upstream commit:
  https://github.com/systemd/systemd/commit/3740146a4cbd

  $ git describe --contains 3740146a4cbd
  v240~839

  $ rmadison systemd --arch amd64
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.21 | xenial-security | source, ...
   systemd | 229-4ubuntu21.21 | xenial-updates  | source, ...
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.19 | bionic-security | source, ...
   systemd | 237-3ubuntu10.21 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.22 | bionic-proposed | source, ...
   systemd | 239-7ubuntu10| cosmic  | source, ...
   systemd | 239-7ubuntu10.12 | cosmic-security | source, ...
   systemd | 239-7ubuntu10.13 | cosmic-updates  | source, ...
   systemd | 239-7ubuntu10.14 | cosmic-proposed | source, ...
   systemd | 240-6ubuntu5 | disco   | source, ...
   systemd | 240-6ubuntu5.1   | disco-proposed  | source, ...
   systemd | 240-6ubuntu9 | eoan| source, ...

  Despite the package versions above, only Bionic is affected. Cosmic
  already includes a backported fix, and Xenial doesn't seem affected
  due  to resolvconf handling DNS resolution.

  [Test Case]
  Flush resolved's caches and try resolving a non-existent CNAME record. 
Further resolution attempts for the corresponding A record will fail:

  #1
  On a Bionic host:
  $ systemd-resolve --flush-caches
  $ dig github.com CNAME
  
  ;; QUESTION SECTION:
  ;github.com.  IN  CNAME

  ;; Query time: 47 msec
  .

  $ dig github.com A
  
  ;; QUESTION SECTION:
  ;github.com.  IN  A

  ;; Query time: 0 msec
  

  While in reality, if no non-existent CNAME result query has been made
  first:

  $ systemd-resolve --flush-caches
  $ dig github.com
  
  ; QUESTION SECTION:
  ;github.com.  IN  A

  ;; ANSWER SECTION:
  github.com.   59  IN  A   192.30.253.112

  ;; Query time: 51 msec
  

  #2
  On a Bionic host:
  $ systemd-resolve --flush-caches
  $ dig github.com CNAME
  $ dig github.com A

  Build a lxd container with Cosmic/Disco/Eoan (systemd-240):
  $ lxc launch ubuntu:cosmic cosmiclxd
  $ lxd exec cosmiclxd bash
  $ dig github.com A
  
  ;; QUESTION SECTION:
  ;github.com.  IN  A

  ;; Query time: 0 msec
  

  Despite the fact that Cosmic and late has the proper systemd fix,
  Cosmic/Disco/Eoan container can suffer from the bug too if the host is
  Bionic (container uses the host as a DNS resolver).

  So you may face the problem inside Cosmic/Disco/Eoan container, but
  it's still the same Bionic systemd bug.

  [Regression Potential]
  The regression potential for this fix should be very low, as it's a direct 
cherry-pick from upstream systemd. It has seen extensive testing  in both 
upstream and other Ubuntu releases, and was verified for Bionic through 
autopkgtests.

  

  [Original Description]

  It seems that when systemd-resolve cache an non-existent CNAME record
  for a domain, any attempt to resolve A record for the same domain
  fail.

  systemd version the issue has been seen with
  Installed: 237-3ubuntu10.13
  Used distribution

  Distributor ID: Ubuntu
  Description: Ubuntu 18.04.2 LTS
  Release: 18.04
  

[Touch-packages] [Bug 1818527] Re: Stub resolver cache is corrupted

2019-06-14 Thread Heitor Alves de Siqueira
Verified for Bionic:

ubuntu@bionic:~$ dpkg -l | grep systemd
ii  systemd   237-3ubuntu10.23  
amd64system and service manager

ubuntu@bionic:~$ systemd-resolve --flush-caches

ubuntu@bionic:~$ dig +noall +answer github.com CNAME

ubuntu@bionic:~$ dig +noall +answer github.com A
github.com. 18  IN  A   140.82.118.4


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

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

Title:
  Stub resolver cache is corrupted

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  Fix Committed

Bug description:
  [Impact]
  systemd-resolved fails to resolve A records

  [Description]
  When systemd-resolve caches a non-existent CNAME record for a specific 
domain, further attempts at resolving A records for that same domain  fail. 
This has been fixed upstream in v240.

  Upstream commit:
  https://github.com/systemd/systemd/commit/3740146a4cbd

  $ git describe --contains 3740146a4cbd
  v240~839

  $ rmadison systemd --arch amd64
   systemd | 229-4ubuntu4 | xenial  | source, ...
   systemd | 229-4ubuntu21.21 | xenial-security | source, ...
   systemd | 229-4ubuntu21.21 | xenial-updates  | source, ...
   systemd | 237-3ubuntu10| bionic  | source, ...
   systemd | 237-3ubuntu10.19 | bionic-security | source, ...
   systemd | 237-3ubuntu10.21 | bionic-updates  | source, ...
   systemd | 237-3ubuntu10.22 | bionic-proposed | source, ...
   systemd | 239-7ubuntu10| cosmic  | source, ...
   systemd | 239-7ubuntu10.12 | cosmic-security | source, ...
   systemd | 239-7ubuntu10.13 | cosmic-updates  | source, ...
   systemd | 239-7ubuntu10.14 | cosmic-proposed | source, ...
   systemd | 240-6ubuntu5 | disco   | source, ...
   systemd | 240-6ubuntu5.1   | disco-proposed  | source, ...
   systemd | 240-6ubuntu9 | eoan| source, ...

  Despite the package versions above, only Bionic is affected. Cosmic
  already includes a backported fix, and Xenial doesn't seem affected
  due  to resolvconf handling DNS resolution.

  [Test Case]
  Flush resolved's caches and try resolving a non-existent CNAME record. 
Further resolution attempts for the corresponding A record will fail:

  #1
  On a Bionic host:
  $ systemd-resolve --flush-caches
  $ dig github.com CNAME
  
  ;; QUESTION SECTION:
  ;github.com.  IN  CNAME

  ;; Query time: 47 msec
  .

  $ dig github.com A
  
  ;; QUESTION SECTION:
  ;github.com.  IN  A

  ;; Query time: 0 msec
  

  While in reality, if no non-existent CNAME result query has been made
  first:

  $ systemd-resolve --flush-caches
  $ dig github.com
  
  ; QUESTION SECTION:
  ;github.com.  IN  A

  ;; ANSWER SECTION:
  github.com.   59  IN  A   192.30.253.112

  ;; Query time: 51 msec
  

  #2
  On a Bionic host:
  $ systemd-resolve --flush-caches
  $ dig github.com CNAME
  $ dig github.com A

  Build a lxd container with Cosmic/Disco/Eoan (systemd-240):
  $ lxc launch ubuntu:cosmic cosmiclxd
  $ lxd exec cosmiclxd bash
  $ dig github.com A
  
  ;; QUESTION SECTION:
  ;github.com.  IN  A

  ;; Query time: 0 msec
  

  Despite the fact that Cosmic and late has the proper systemd fix,
  Cosmic/Disco/Eoan container can suffer from the bug too if the host is
  Bionic (container uses the host as a DNS resolver).

  So you may face the problem inside Cosmic/Disco/Eoan container, but
  it's still the same Bionic systemd bug.

  [Regression Potential]
  The regression potential for this fix should be very low, as it's a direct 
cherry-pick from upstream systemd. It has seen extensive testing  in both 
upstream and other Ubuntu releases, and was verified for Bionic through 
autopkgtests.

  

  [Original Description]

  It seems that when systemd-resolve cache an non-existent CNAME record
  for a domain, any attempt to resolve A record for the same domain
  fail.

  systemd version the issue has been seen with
  Installed: 237-3ubuntu10.13
  Used distribution

  Distributor ID: Ubuntu
  Description: Ubuntu 18.04.2 LTS
  Release: 18.04
  Codename: bionic

  Expected behaviour you didn't see

  Return A record for a domain when it exists.

  Unexpected behaviour you saw

  Resolution failed.

  Steps to reproduce the problem

  Whait for 1 minutes (github.com TTL for A record)

  Try to resolv github.com CNAME record dig CNAME github.com

  This will return an empty result.

  Then try to resolve github.com A record dig A github.com.

  This will now return empty result unless you restart systemd-resolved
  or wait for cache 

[Touch-packages] [Bug 1803203] Re: Support preferred_lft for IPv6 addresses

2019-06-07 Thread Heitor Alves de Siqueira
@rlaager
I've started a PR discussion on Netplan.io's Github with your proposed changes 
as they seemed the best way forward for now.

I don't expect this to get merged right away, as the maintainers might
want to discuss the changes to the schema in further detail. In any
case, this should at least start a discussion on getting this fixed in
upstream netplan.

https://github.com/CanonicalLtd/netplan/pull/89

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

Title:
  Support preferred_lft for IPv6 addresses

Status in netplan:
  New
Status in netplan.io package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  There doesn't currently seem to be any way to set the preferred_lft of
  an IPv6 address.

  With the "ip" command it might be, for example:

  # ip address add 2001:db8::2/32 dev eth0 preferred_lft 0

  In a systemd unit file it might be:

  [Match]
  Name=eth0

  [Network]
  Address=2001:db8::2/32
  Gateway=2001:db8::1/32
  PreferredLifetime=0

  but I can't find any way to express this with netplan.

  This is commonly used for per-service IP addresses that should never
  be used as source addresses for outgoing traffic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1803203/+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 1818527] Re: Stub resolver cache is corrupted

2019-06-05 Thread Heitor Alves de Siqueira
** Description changed:

+ [Impact]
+ systemd-resolved fails to resolve A records
+ 
+ [Description]
+ When systemd-resolve caches a non-existent CNAME record for a specific 
domain, further attempts at resolving A records for that same domain  fail. 
This has been fixed upstream in v240.
+ 
+ Upstream commit: https://github.com/systemd/systemd/commit/3740146a4cbd
+ 
+ $ git describe --contains 3740146a4cbd
+ v240~839
+ 
+ $ rmadison systemd --arch amd64
+  systemd | 229-4ubuntu4 | xenial  | source, ...
+  systemd | 229-4ubuntu21.21 | xenial-security | source, ...
+  systemd | 229-4ubuntu21.21 | xenial-updates  | source, ...
+  systemd | 237-3ubuntu10| bionic  | source, ...
+  systemd | 237-3ubuntu10.19 | bionic-security | source, ...
+  systemd | 237-3ubuntu10.21 | bionic-updates  | source, ...
+  systemd | 237-3ubuntu10.22 | bionic-proposed | source, ...
+  systemd | 239-7ubuntu10| cosmic  | source, ...
+  systemd | 239-7ubuntu10.12 | cosmic-security | source, ...
+  systemd | 239-7ubuntu10.13 | cosmic-updates  | source, ...
+  systemd | 239-7ubuntu10.14 | cosmic-proposed | source, ...
+  systemd | 240-6ubuntu5 | disco   | source, ...
+  systemd | 240-6ubuntu5.1   | disco-proposed  | source, ...
+  systemd | 240-6ubuntu9 | eoan| source, ...
+ 
+ Despite the package versions above, only Bionic is affected. Cosmic
+ already includes a backported fix, and Xenial doesn't seem affected due
+ to resolvconf handling DNS resolution.
+ 
+ [Test Case]
+ Flush resolved's caches and try resolving a non-existent CNAME record. 
Further resolution attempts for the corresponding A record will fail:
+ 
+ $ systemd-resolve --flush-caches
+ $ dig github.com CNAME
+ $ dig github.com A
+ 
+ [Regression Potential]
+ The regression potential for this fix should be very low, as it's a direct 
cherry-pick from upstream systemd. It has seen extensive testing  in both 
upstream and other Ubuntu releases, and was verified for Bionic through 
autopkgtests.
+ 
+ 
+ 
+ [Original Description]
+ 
  It seems that when systemd-resolve cache an non-existent CNAME record
  for a domain, any attempt to resolve A record for the same domain fail.
  
  systemd version the issue has been seen with
  Installed: 237-3ubuntu10.13
  Used distribution
  
  Distributor ID: Ubuntu
  Description: Ubuntu 18.04.2 LTS
  Release: 18.04
  Codename: bionic
  
  Expected behaviour you didn't see
  
  Return A record for a domain when it exists.
  
  Unexpected behaviour you saw
  
  Resolution failed.
  
  Steps to reproduce the problem
  
  Whait for 1 minutes (github.com TTL for A record)
  
  Try to resolv github.com CNAME record dig CNAME github.com
  
  This will return an empty result.
  
  Then try to resolve github.com A record dig A github.com.
  
  This will now return empty result unless you restart systemd-resolved or
  wait for cache expiration.
  
  At the same time using another DNS will resolve correctly dig A
  github.com @8.8.8.8.
  
  Exemple :
  
  Wait for 1 minutes to let cache expire, then run
  
  dig CNAME github.com
  dig A github.com
  # no result
  dig A github.com @8.8.8.8
  # ;; ANSWER SECTION:
  # github.com. 59  IN  A   192.30.253.113
  # github.com. 59  IN  A   192.30.253.112
  
  PS: Don't forget to restart systemd-resolve, before trying to post an
  answer.
  
  This bug was first reported in github
  https://github.com/systemd/systemd/issues/11789 but systemd version in
  ubuntu is too  old.

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

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

** Changed in: systemd (Ubuntu Xenial)
 Assignee: Heitor Alves de Siqueira (halves) => (unassigned)

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

** Patch added: "lp1818527-bionic.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818527/+attachment/5268921/+files/lp1818527-bionic.debdiff

** Tags added: sts sts-sponsor

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

Title:
  Stub resolver cache is corrupted

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  Invalid
Status in systemd source package in Bionic:
  In Progress

Bug description:
  [Impact]
  systemd-resolved fails to resolve A records

  [Description]
  When systemd-resolve caches a non-existent CNAME record for a specific 
domain, further attempts at resolving A records for that same domain  fail. 
This has been fixed upstream in v240.

  Upstream commit:
  https://github.com/systemd/systemd/commit/3740146a4cbd

  $ git describe --contains 3740146a4cbd
  v240~839

  $ rmadison systemd --arch amd64
   systemd | 229-4ubuntu4 | xe

[Touch-packages] [Bug 1818527] Re: Stub resolver cache is corrupted

2019-06-05 Thread Heitor Alves de Siqueira
** Also affects: systemd (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

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

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

** Changed in: systemd (Ubuntu Bionic)
 Assignee: (unassigned) => Heitor Alves de Siqueira (halves)

** Changed in: systemd (Ubuntu Xenial)
 Assignee: (unassigned) => Heitor Alves de Siqueira (halves)

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

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

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

Title:
  Stub resolver cache is corrupted

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Xenial:
  New
Status in systemd source package in Bionic:
  Confirmed

Bug description:
  It seems that when systemd-resolve cache an non-existent CNAME record
  for a domain, any attempt to resolve A record for the same domain
  fail.

  systemd version the issue has been seen with
  Installed: 237-3ubuntu10.13
  Used distribution

  Distributor ID: Ubuntu
  Description: Ubuntu 18.04.2 LTS
  Release: 18.04
  Codename: bionic

  Expected behaviour you didn't see

  Return A record for a domain when it exists.

  Unexpected behaviour you saw

  Resolution failed.

  Steps to reproduce the problem

  Whait for 1 minutes (github.com TTL for A record)

  Try to resolv github.com CNAME record dig CNAME github.com

  This will return an empty result.

  Then try to resolve github.com A record dig A github.com.

  This will now return empty result unless you restart systemd-resolved
  or wait for cache expiration.

  At the same time using another DNS will resolve correctly dig A
  github.com @8.8.8.8.

  Exemple :

  Wait for 1 minutes to let cache expire, then run

  dig CNAME github.com
  dig A github.com
  # no result
  dig A github.com @8.8.8.8
  # ;; ANSWER SECTION:
  # github.com. 59  IN  A   192.30.253.113
  # github.com. 59  IN  A   192.30.253.112

  PS: Don't forget to restart systemd-resolve, before trying to post an
  answer.

  This bug was first reported in github
  https://github.com/systemd/systemd/issues/11789 but systemd version in
  ubuntu is too  old.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818527/+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 1803203] Re: Support preferred_lft for IPv6 addresses

2019-05-27 Thread Heitor Alves de Siqueira
Some notes for reference:

We might actually have some trouble in expressing the Lifetime of an
Address in the Netplan schema. From the Netplan Reference [0] we can see
that the 'addresses:' field accepts a list of mixed IPv4 and IPv6
addresses. We can't just add a 'lifetime:' field to the schema, because
then we wouldn't have a way to link that value to one of the addresses
in the mixed list. I can see a few different ways to change the
configuration to accommodate the lifetime change:

1) Implement a list of lifetimes, which would "follow" the list of addresses
  (i.e. lifetime[0] corresponds to addresses[0] and so on)

2) Modify the address syntax inside the list to allow an optional lifetime, 
e.g.:
  addresses: [127.0.0.1 (forever), "2001:1::1/64 (0)"]

3) Allow the definition of an address+lifetime mapping and use that in the
'addresses' field, e.g.:
  myaddr:
value: 127.0.0.1
lifetime: 0
  ...
  addresses: [ myaddr, 2001:1::1/64 ]

Option 1 has the obvious problem of matching one lifetime to a list of
multiple addresses. Say we want to specify a lifetime to address number
K in the list, would we need to specify a lifetime for all of them? How
would we "skip" default lifetimes with this approach?

Option 2 has the benefit of being somewhat compatible with the current
schema in the sense that if no lifetime is specified, we can keep the
current behavior. I feel like it would introduce a lot of complexity in
the schema parsing code to sort the addresses from the lifetime though,
and this might not be something that we want in a sensitive code
section.

Option 3 looks very flexible, but I'm not familiar enough with the
schema and its parsing code to estimate the impact that would have. I
think we would need quite a few significant changes, and I'm not really
sure where we would place the 'myaddr' definition in the schema either.

None of the above options feel like a good way to solve the lifetime
problem, but I'm not sure we have an easy way to integrate that into the
current netplan schema. Perhaps someone more experienced with the
Netplan schema/codebase might offer better insight on how to tackle this
issue.

[0] https://netplan.io/reference

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

Title:
  Support preferred_lft for IPv6 addresses

Status in netplan:
  New
Status in netplan.io package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  There doesn't currently seem to be any way to set the preferred_lft of
  an IPv6 address.

  With the "ip" command it might be, for example:

  # ip address add 2001:db8::2/32 dev eth0 preferred_lft 0

  In a systemd unit file it might be:

  [Match]
  Name=eth0

  [Network]
  Address=2001:db8::2/32
  Gateway=2001:db8::1/32
  PreferredLifetime=0

  but I can't find any way to express this with netplan.

  This is commonly used for per-service IP addresses that should never
  be used as source addresses for outgoing traffic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1803203/+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 1820886] Re: Potential inconsistency due to system halt/reboot being allowed when package installation in progress

2019-05-24 Thread Heitor Alves de Siqueira
Verified fix for Xenial:

ubuntu@xenial:~$ systemctl reboot
Operation inhibited by "APT" (PID 1311 "apt", user root), reason is "APT is 
installing or removing packages".
Please retry operation after closing inhibitors and logging out other users.
Alternatively, ignore inhibitors and users with 'systemctl reboot -i'.

ubuntu@xenial:~$ dpkg -l | grep apt
ii  apt  1.2.32 
amd64commandline package manager


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

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

Title:
  Potential inconsistency due to system halt/reboot being allowed when
  package installation in progress

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Xenial:
  Fix Committed
Status in apt source package in Bionic:
  Fix Committed
Status in apt source package in Cosmic:
  Fix Committed
Status in apt source package in Disco:
  Fix Released

Bug description:
  [System]
  Any current Ubuntu Desktop/Server supported release (Trusty, Xenial, Bionic, 
Cosmic).

  [Impact]
  Package installation turns into an inconsistent state if system is rebooted 
in the middle of an apt install/upgrade.

  [Test Case]
  1. User1 at Ubuntu box issues "sudo apt-get upgrade";
  2. User2 at Ubuntu box issues "shutdown -r" or reboots it using the GUI;
  3. System reboots and potentially turns into an inconsistent state.

  [Remarks]
  APT should automatically inhibit system halts/reboots while packages being 
installed/removed. A similar behavior to what is shown by unattended-upgrades.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1820886/+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 1822270] Re: Debconf readline frontend does not show options

2019-05-10 Thread Heitor Alves de Siqueira
Some comments on the autopkgtest regressions:

# Disco
- prometheus-blackbox-exporter and open-isns fail due to package dependency 
problems, unrelated to debconf

- makedumpfile fails with "sudo: /tmp/autopkgtest-run-wrapper: command
not found", which has happened in other previous autopkgtests
(perl/5.28.1-6, file/1:5.35-4, elfutils/0.176-1). This does not seem to
be related to the debconf update

# Cosmic
- murano seems to fail due to a syntax error in python3-murano, preventing dpkg 
from successfully configuring it. It has been failing since before the debconf 
change was introduced

- cacti fails due to "ERROR PHP WARNING: A non-numeric value encountered
in file: /usr/share/cacti/site/poller.php  on line: 652", which is not
related to the debconf changes

- pbuilder is failing due to a missing Eoan script, might be related to
LP: #1825994

- glibc fails due to a timeout on the test suite, and doesn't look
related to our debconf changes

# Bionic
- pbuilder is still failing due to a missing Eoan script, might be related to 
LP: #1825994

- redmine is failing due to not being able to pull some packages for the
test setup

- makedumpfile has been failing since before the debconf changes with
"makedumpfile: ERROR: crash test: kdump is not ready"

- cacti fails due to "Unexpected output in /var/log/cacti/cacti.log:
05/08/2019 19:45:00 - AUTOM8 WARNING: The Network ID: 1 is disabled.  You must 
use the 'force' option to force it's execution."

- open-iscsi is failing since debconf/1.5.66, so it doesn't look to be
caused by our changes

** 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 debconf in Ubuntu.
https://bugs.launchpad.net/bugs/1822270

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  Fix Released
Status in debconf source package in Xenial:
  Fix Committed
Status in debconf source package in Bionic:
  Fix Committed
Status in debconf source package in Cosmic:
  Fix Committed
Status in debconf source package in Disco:
  Fix Committed
Status in debconf source package in Eoan:
  Fix Released
Status in debconf package in Debian:
  Fix Released

Bug description:
  [Impact]
  debconf prompts the user for input before displaying options

  [Description]
  When upgrading packages with apt or dpkg, debconf scripts are ran through 
'run-parts' with the '--report' flag. This causes script output to be handled 
through pipes set up by run-parts, and buffers output from maintainer scripts 
nicely for formatting.

  If debconf makes use of the readline frontend, any prompts will bypass
  the run-parts buffers and be displayed directly to /dev/tty. This
  generally causes the prompt to be displayed before the user gets any
  of the available options for it, and printing will block until the
  user inputs a valid option.

  Upstream commit: https://salsa.debian.org/pkg-
  debconf/debconf/commit/48c5ce38cfd5

  [Test Case]
  1) Deploy a VM through e.g. uvt-kvm
  $ uvt-kvm create disco release=disco

  2) Remove the whiptail package to force the readline frontend in debconf
  root@disco:~# apt remove --purge whiptail -y

  3) Install grub-legacy-ec2 and prepare /boot/grub/menu.lst for an upgrade 
through run-parts
  root@disco:~# apt update && apt install -y grub-legacy-ec2
  root@disco:~# rm -f /boot/grub/menu.lst*
  root@disco:~# touch -d "4 years ago" /boot/grub/menu.lst

  4) Invoke run-parts as in a kernel upgrade (kernel version doesn't matter, we 
just need it to think menu.lst needs an upgrade)
  root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
  ...
  /etc/kernel/postinst.d/x-grub-legacy-ec2:
  debconf: unable to initialize frontend: Dialog
  debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
  debconf: falling back to frontend: Readline
  Searching for GRUB installation directory ... found: /boot/grub
  Searching for default file ... found: /boot/grub/default
  Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
  Searching for splash image ... none found, skipping ...
  What would you like to do about menu.lst?

  The "What would you like to do about menu.lst?" prompt will block
  until the user enter a valid option, even though it's being displayed
  before the available options.

  [Regression Potential]
  We could hit regressions if changing debconf's printing to /dev/tty is 
expected by other programs. The changes are needed only in the readline 
frontend, so that would minimize impact of any possible regressions. The fixes 
will be thoroughly tested with autopkgtest and use-case scenarios.

  # # # #

  [Original Description]
  When upgrading the kernel on a recent Bionic minimal image, the user is 
prompted to resolve a conflict in the file 

[Touch-packages] [Bug 1822270] Re: Debconf readline frontend does not show options

2019-05-10 Thread Heitor Alves de Siqueira
Validated debconf from bionic-proposed according to test case from
description:

root@bionic:~# dpkg -l | grep debconf
ii  debconf 1.5.66ubuntu1   
all  Debian configuration management system

root@bionic:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
...
/etc/kernel/postinst.d/x-grub-legacy-ec2:
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
debconf: falling back to frontend: Readline
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
A new version of /boot/grub/menu.lst is available, but the version installed 
currently has been locally modified.

  1. install the package maintainer's version3. show the differences 
between the versions5. show a 3-way difference between available 
versions  7. start a new shell to examine the situation
  2. keep the local version currently installed  4. show a side-by-side 
difference between the versions  6. do a 3-way merge between available versions 
(experimental)

What would you like to do about menu.lst?

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

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

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  Fix Released
Status in debconf source package in Xenial:
  Fix Committed
Status in debconf source package in Bionic:
  Fix Committed
Status in debconf source package in Cosmic:
  Fix Committed
Status in debconf source package in Disco:
  Fix Committed
Status in debconf source package in Eoan:
  Fix Released
Status in debconf package in Debian:
  Fix Released

Bug description:
  [Impact]
  debconf prompts the user for input before displaying options

  [Description]
  When upgrading packages with apt or dpkg, debconf scripts are ran through 
'run-parts' with the '--report' flag. This causes script output to be handled 
through pipes set up by run-parts, and buffers output from maintainer scripts 
nicely for formatting.

  If debconf makes use of the readline frontend, any prompts will bypass
  the run-parts buffers and be displayed directly to /dev/tty. This
  generally causes the prompt to be displayed before the user gets any
  of the available options for it, and printing will block until the
  user inputs a valid option.

  Upstream commit: https://salsa.debian.org/pkg-
  debconf/debconf/commit/48c5ce38cfd5

  [Test Case]
  1) Deploy a VM through e.g. uvt-kvm
  $ uvt-kvm create disco release=disco

  2) Remove the whiptail package to force the readline frontend in debconf
  root@disco:~# apt remove --purge whiptail -y

  3) Install grub-legacy-ec2 and prepare /boot/grub/menu.lst for an upgrade 
through run-parts
  root@disco:~# apt update && apt install -y grub-legacy-ec2
  root@disco:~# rm -f /boot/grub/menu.lst*
  root@disco:~# touch -d "4 years ago" /boot/grub/menu.lst

  4) Invoke run-parts as in a kernel upgrade (kernel version doesn't matter, we 
just need it to think menu.lst needs an upgrade)
  root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
  ...
  /etc/kernel/postinst.d/x-grub-legacy-ec2:
  debconf: unable to initialize frontend: Dialog
  debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
  debconf: falling back to frontend: Readline
  Searching for GRUB installation directory ... found: /boot/grub
  Searching for default file ... found: /boot/grub/default
  Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
  Searching for splash image ... none found, skipping ...
  What would you like to do about menu.lst?

  The "What would you like to do about menu.lst?" prompt will block
  until the user enter a valid option, even though it's being displayed
  before the available options.

  [Regression Potential]
  We could hit regressions if changing debconf's printing to /dev/tty is 
expected by other programs. The changes are needed only in the readline 
frontend, so that would minimize impact of any possible regressions. The fixes 
will be thoroughly tested with autopkgtest and use-case scenarios.

  # # # #

  [Original Description]
  When upgrading the kernel on a recent Bionic minimal image, the user is 
prompted to resolve a conflict in the file /boot/grub/menu.lst.

  The minimal images do not have dialog/whiptail installed, so debconf
  falls back to using the readline 

[Touch-packages] [Bug 1822270] Re: Debconf readline frontend does not show options

2019-05-10 Thread Heitor Alves de Siqueira
Validated debconf from xenial-proposed according to test case from
description:

root@xenial:~# dpkg -l | grep debconf
ii  debconf  1.5.58ubuntu2  
all  Debian configuration management system

root@xenial:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
...
/etc/kernel/postinst.d/x-grub-legacy-ec2:
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
debconf: falling back to frontend: Readline
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
A new version of /boot/grub/menu.lst is available, but the version installed 
currently has been locally modified.

  1. install the package maintainer's version3. show the differences 
between the versions5. show a 3-way difference between available 
versions  7. start a new shell to examine the situation
  2. keep the local version currently installed  4. show a side-by-side 
difference between the versions  6. do a 3-way merge between available versions 
(experimental)

What would you like to do about menu.lst?

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

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

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  Fix Released
Status in debconf source package in Xenial:
  Fix Committed
Status in debconf source package in Bionic:
  Fix Committed
Status in debconf source package in Cosmic:
  Fix Committed
Status in debconf source package in Disco:
  Fix Committed
Status in debconf source package in Eoan:
  Fix Released
Status in debconf package in Debian:
  Fix Released

Bug description:
  [Impact]
  debconf prompts the user for input before displaying options

  [Description]
  When upgrading packages with apt or dpkg, debconf scripts are ran through 
'run-parts' with the '--report' flag. This causes script output to be handled 
through pipes set up by run-parts, and buffers output from maintainer scripts 
nicely for formatting.

  If debconf makes use of the readline frontend, any prompts will bypass
  the run-parts buffers and be displayed directly to /dev/tty. This
  generally causes the prompt to be displayed before the user gets any
  of the available options for it, and printing will block until the
  user inputs a valid option.

  Upstream commit: https://salsa.debian.org/pkg-
  debconf/debconf/commit/48c5ce38cfd5

  [Test Case]
  1) Deploy a VM through e.g. uvt-kvm
  $ uvt-kvm create disco release=disco

  2) Remove the whiptail package to force the readline frontend in debconf
  root@disco:~# apt remove --purge whiptail -y

  3) Install grub-legacy-ec2 and prepare /boot/grub/menu.lst for an upgrade 
through run-parts
  root@disco:~# apt update && apt install -y grub-legacy-ec2
  root@disco:~# rm -f /boot/grub/menu.lst*
  root@disco:~# touch -d "4 years ago" /boot/grub/menu.lst

  4) Invoke run-parts as in a kernel upgrade (kernel version doesn't matter, we 
just need it to think menu.lst needs an upgrade)
  root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
  ...
  /etc/kernel/postinst.d/x-grub-legacy-ec2:
  debconf: unable to initialize frontend: Dialog
  debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
  debconf: falling back to frontend: Readline
  Searching for GRUB installation directory ... found: /boot/grub
  Searching for default file ... found: /boot/grub/default
  Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
  Searching for splash image ... none found, skipping ...
  What would you like to do about menu.lst?

  The "What would you like to do about menu.lst?" prompt will block
  until the user enter a valid option, even though it's being displayed
  before the available options.

  [Regression Potential]
  We could hit regressions if changing debconf's printing to /dev/tty is 
expected by other programs. The changes are needed only in the readline 
frontend, so that would minimize impact of any possible regressions. The fixes 
will be thoroughly tested with autopkgtest and use-case scenarios.

  # # # #

  [Original Description]
  When upgrading the kernel on a recent Bionic minimal image, the user is 
prompted to resolve a conflict in the file /boot/grub/menu.lst.

  The minimal images do not have dialog/whiptail installed, so debconf
  falls back to using the readline 

[Touch-packages] [Bug 1822270] Re: Debconf readline frontend does not show options

2019-05-08 Thread Heitor Alves de Siqueira
Validated debconf from cosmic-proposed according to test case from
description:

root@cosmic:~# dpkg -l | grep debconf
ii  debconf 1.5.69ubuntu1   all 
 Debian configuration management system

root@cosmic:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
...
/etc/kernel/postinst.d/x-grub-legacy-ec2:
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
debconf: falling back to frontend: Readline
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
A new version of /boot/grub/menu.lst is available, but the version installed 
currently has been locally modified.

  1. install the package maintainer's version3. show the differences 
between the versions5. show a 3-way difference between available 
versions  7. start a new shell to examine the situation
  2. keep the local version currently installed  4. show a side-by-side 
difference between the versions  6. do a 3-way merge between available versions 
(experimental)

What would you like to do about menu.lst?

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

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

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  Fix Released
Status in debconf source package in Xenial:
  Fix Committed
Status in debconf source package in Bionic:
  Fix Committed
Status in debconf source package in Cosmic:
  Fix Committed
Status in debconf source package in Disco:
  Fix Committed
Status in debconf source package in Eoan:
  Fix Released
Status in debconf package in Debian:
  Fix Released

Bug description:
  [Impact]
  debconf prompts the user for input before displaying options

  [Description]
  When upgrading packages with apt or dpkg, debconf scripts are ran through 
'run-parts' with the '--report' flag. This causes script output to be handled 
through pipes set up by run-parts, and buffers output from maintainer scripts 
nicely for formatting.

  If debconf makes use of the readline frontend, any prompts will bypass
  the run-parts buffers and be displayed directly to /dev/tty. This
  generally causes the prompt to be displayed before the user gets any
  of the available options for it, and printing will block until the
  user inputs a valid option.

  Upstream commit: https://salsa.debian.org/pkg-
  debconf/debconf/commit/48c5ce38cfd5

  [Test Case]
  1) Deploy a VM through e.g. uvt-kvm
  $ uvt-kvm create disco release=disco

  2) Remove the whiptail package to force the readline frontend in debconf
  root@disco:~# apt remove --purge whiptail -y

  3) Install grub-legacy-ec2 and prepare /boot/grub/menu.lst for an upgrade 
through run-parts
  root@disco:~# apt update && apt install -y grub-legacy-ec2
  root@disco:~# rm -f /boot/grub/menu.lst*
  root@disco:~# touch -d "4 years ago" /boot/grub/menu.lst

  4) Invoke run-parts as in a kernel upgrade (kernel version doesn't matter, we 
just need it to think menu.lst needs an upgrade)
  root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
  ...
  /etc/kernel/postinst.d/x-grub-legacy-ec2:
  debconf: unable to initialize frontend: Dialog
  debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
  debconf: falling back to frontend: Readline
  Searching for GRUB installation directory ... found: /boot/grub
  Searching for default file ... found: /boot/grub/default
  Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
  Searching for splash image ... none found, skipping ...
  What would you like to do about menu.lst?

  The "What would you like to do about menu.lst?" prompt will block
  until the user enter a valid option, even though it's being displayed
  before the available options.

  [Regression Potential]
  We could hit regressions if changing debconf's printing to /dev/tty is 
expected by other programs. The changes are needed only in the readline 
frontend, so that would minimize impact of any possible regressions. The fixes 
will be thoroughly tested with autopkgtest and use-case scenarios.

  # # # #

  [Original Description]
  When upgrading the kernel on a recent Bionic minimal image, the user is 
prompted to resolve a conflict in the file /boot/grub/menu.lst.

  The minimal images do not have dialog/whiptail installed, so debconf
  falls back to using the readline frontend.


[Touch-packages] [Bug 1822270] Re: Debconf readline frontend does not show options

2019-05-08 Thread Heitor Alves de Siqueira
Validated debconf from disco-proposed according to test case from
description:

root@disco:~# dpkg -l | grep debconf
ii  debconf 1.5.71ubuntu1   all 
 Debian configuration management system

root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
...
/etc/kernel/postinst.d/x-grub-legacy-ec2:
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
debconf: falling back to frontend: Readline
Searching for GRUB installation directory ... found: /boot/grub
Searching for default file ... found: /boot/grub/default
Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
Searching for splash image ... none found, skipping ...
A new version of /boot/grub/menu.lst is available, but the version installed 
currently has been locally modified.

  1. install the package maintainer's version3. show the differences 
between the versions5. show a 3-way difference between available 
versions  7. start a new shell to examine the situation
  2. keep the local version currently installed  4. show a side-by-side 
difference between the versions  6. do a 3-way merge between available versions 
(experimental)

What would you like to do about menu.lst?

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

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

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  Fix Released
Status in debconf source package in Xenial:
  Fix Committed
Status in debconf source package in Bionic:
  Fix Committed
Status in debconf source package in Cosmic:
  Fix Committed
Status in debconf source package in Disco:
  Fix Committed
Status in debconf source package in Eoan:
  Fix Released
Status in debconf package in Debian:
  Fix Released

Bug description:
  [Impact]
  debconf prompts the user for input before displaying options

  [Description]
  When upgrading packages with apt or dpkg, debconf scripts are ran through 
'run-parts' with the '--report' flag. This causes script output to be handled 
through pipes set up by run-parts, and buffers output from maintainer scripts 
nicely for formatting.

  If debconf makes use of the readline frontend, any prompts will bypass
  the run-parts buffers and be displayed directly to /dev/tty. This
  generally causes the prompt to be displayed before the user gets any
  of the available options for it, and printing will block until the
  user inputs a valid option.

  Upstream commit: https://salsa.debian.org/pkg-
  debconf/debconf/commit/48c5ce38cfd5

  [Test Case]
  1) Deploy a VM through e.g. uvt-kvm
  $ uvt-kvm create disco release=disco

  2) Remove the whiptail package to force the readline frontend in debconf
  root@disco:~# apt remove --purge whiptail -y

  3) Install grub-legacy-ec2 and prepare /boot/grub/menu.lst for an upgrade 
through run-parts
  root@disco:~# apt update && apt install -y grub-legacy-ec2
  root@disco:~# rm -f /boot/grub/menu.lst*
  root@disco:~# touch -d "4 years ago" /boot/grub/menu.lst

  4) Invoke run-parts as in a kernel upgrade (kernel version doesn't matter, we 
just need it to think menu.lst needs an upgrade)
  root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
  ...
  /etc/kernel/postinst.d/x-grub-legacy-ec2:
  debconf: unable to initialize frontend: Dialog
  debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
  debconf: falling back to frontend: Readline
  Searching for GRUB installation directory ... found: /boot/grub
  Searching for default file ... found: /boot/grub/default
  Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
  Searching for splash image ... none found, skipping ...
  What would you like to do about menu.lst?

  The "What would you like to do about menu.lst?" prompt will block
  until the user enter a valid option, even though it's being displayed
  before the available options.

  [Regression Potential]
  We could hit regressions if changing debconf's printing to /dev/tty is 
expected by other programs. The changes are needed only in the readline 
frontend, so that would minimize impact of any possible regressions. The fixes 
will be thoroughly tested with autopkgtest and use-case scenarios.

  # # # #

  [Original Description]
  When upgrading the kernel on a recent Bionic minimal image, the user is 
prompted to resolve a conflict in the file /boot/grub/menu.lst.

  The minimal images do not have dialog/whiptail installed, so debconf
  falls back to using the readline frontend.

  

[Touch-packages] [Bug 1822270] Re: Debconf readline frontend does not show options

2019-05-07 Thread Heitor Alves de Siqueira
** Patch added: "lp1822270-cosmic.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+attachment/5262099/+files/lp1822270-cosmic.debdiff

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

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  Fix Released
Status in debconf source package in Xenial:
  Confirmed
Status in debconf source package in Bionic:
  Confirmed
Status in debconf source package in Cosmic:
  Confirmed
Status in debconf source package in Disco:
  Confirmed
Status in debconf source package in Eoan:
  Fix Released
Status in debconf package in Debian:
  Fix Released

Bug description:
  [Impact]
  debconf prompts the user for input before displaying options

  [Description]
  When upgrading packages with apt or dpkg, debconf scripts are ran through 
'run-parts' with the '--report' flag. This causes script output to be handled 
through pipes set up by run-parts, and buffers output from maintainer scripts 
nicely for formatting.

  If debconf makes use of the readline frontend, any prompts will bypass
  the run-parts buffers and be displayed directly to /dev/tty. This
  generally causes the prompt to be displayed before the user gets any
  of the available options for it, and printing will block until the
  user inputs a valid option.

  Upstream commit: https://salsa.debian.org/pkg-
  debconf/debconf/commit/48c5ce38cfd5

  [Test Case]
  1) Deploy a VM through e.g. uvt-kvm
  $ uvt-kvm create disco release=disco

  2) Remove the whiptail package to force the readline frontend in debconf
  root@disco:~# apt remove --purge whiptail -y

  3) Install grub-legacy-ec2 and prepare /boot/grub/menu.lst for an upgrade 
through run-parts
  root@disco:~# apt update && apt install -y grub-legacy-ec2
  root@disco:~# rm -f /boot/grub/menu.lst*
  root@disco:~# touch -d "4 years ago" /boot/grub/menu.lst

  4) Invoke run-parts as in a kernel upgrade (kernel version doesn't matter, we 
just need it to think menu.lst needs an upgrade)
  root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
  ...
  /etc/kernel/postinst.d/x-grub-legacy-ec2:
  debconf: unable to initialize frontend: Dialog
  debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
  debconf: falling back to frontend: Readline
  Searching for GRUB installation directory ... found: /boot/grub
  Searching for default file ... found: /boot/grub/default
  Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
  Searching for splash image ... none found, skipping ...
  What would you like to do about menu.lst?

  The "What would you like to do about menu.lst?" prompt will block
  until the user enter a valid option, even though it's being displayed
  before the available options.

  [Regression Potential]
  We could hit regressions if changing debconf's printing to /dev/tty is 
expected by other programs. The changes are needed only in the readline 
frontend, so that would minimize impact of any possible regressions. The fixes 
will be thoroughly tested with autopkgtest and use-case scenarios.

  # # # #

  [Original Description]
  When upgrading the kernel on a recent Bionic minimal image, the user is 
prompted to resolve a conflict in the file /boot/grub/menu.lst.

  The minimal images do not have dialog/whiptail installed, so debconf
  falls back to using the readline frontend.

  The user sees the prompt: "What would you like to do about menu.lst?"
  but is not presented with the list of options to choose from.

  If a valid option is typed in, debconf will continue processing
  correctly and the list of options  appears on the screen. See also
  https://pastebin.ubuntu.com/p/8xvSn88SKG/

  STEPS TO REPRODUCE:

  Launch the minimal Bionic image with serial 20190212 http://cloud-
  images.ubuntu.com/minimal/releases/bionic/release-20190212/ubuntu-18.04
  -minimal-cloudimg-amd64.img

  for example via multipass and run `apt-get update` and `apt-get dist-
  upgrade`.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+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 1822270] Re: Debconf readline frontend does not show options

2019-05-07 Thread Heitor Alves de Siqueira
** Patch added: "lp1822270-bionic.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+attachment/5262100/+files/lp1822270-bionic.debdiff

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

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  Fix Released
Status in debconf source package in Xenial:
  Confirmed
Status in debconf source package in Bionic:
  Confirmed
Status in debconf source package in Cosmic:
  Confirmed
Status in debconf source package in Disco:
  Confirmed
Status in debconf source package in Eoan:
  Fix Released
Status in debconf package in Debian:
  Fix Released

Bug description:
  [Impact]
  debconf prompts the user for input before displaying options

  [Description]
  When upgrading packages with apt or dpkg, debconf scripts are ran through 
'run-parts' with the '--report' flag. This causes script output to be handled 
through pipes set up by run-parts, and buffers output from maintainer scripts 
nicely for formatting.

  If debconf makes use of the readline frontend, any prompts will bypass
  the run-parts buffers and be displayed directly to /dev/tty. This
  generally causes the prompt to be displayed before the user gets any
  of the available options for it, and printing will block until the
  user inputs a valid option.

  Upstream commit: https://salsa.debian.org/pkg-
  debconf/debconf/commit/48c5ce38cfd5

  [Test Case]
  1) Deploy a VM through e.g. uvt-kvm
  $ uvt-kvm create disco release=disco

  2) Remove the whiptail package to force the readline frontend in debconf
  root@disco:~# apt remove --purge whiptail -y

  3) Install grub-legacy-ec2 and prepare /boot/grub/menu.lst for an upgrade 
through run-parts
  root@disco:~# apt update && apt install -y grub-legacy-ec2
  root@disco:~# rm -f /boot/grub/menu.lst*
  root@disco:~# touch -d "4 years ago" /boot/grub/menu.lst

  4) Invoke run-parts as in a kernel upgrade (kernel version doesn't matter, we 
just need it to think menu.lst needs an upgrade)
  root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
  ...
  /etc/kernel/postinst.d/x-grub-legacy-ec2:
  debconf: unable to initialize frontend: Dialog
  debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
  debconf: falling back to frontend: Readline
  Searching for GRUB installation directory ... found: /boot/grub
  Searching for default file ... found: /boot/grub/default
  Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
  Searching for splash image ... none found, skipping ...
  What would you like to do about menu.lst?

  The "What would you like to do about menu.lst?" prompt will block
  until the user enter a valid option, even though it's being displayed
  before the available options.

  [Regression Potential]
  We could hit regressions if changing debconf's printing to /dev/tty is 
expected by other programs. The changes are needed only in the readline 
frontend, so that would minimize impact of any possible regressions. The fixes 
will be thoroughly tested with autopkgtest and use-case scenarios.

  # # # #

  [Original Description]
  When upgrading the kernel on a recent Bionic minimal image, the user is 
prompted to resolve a conflict in the file /boot/grub/menu.lst.

  The minimal images do not have dialog/whiptail installed, so debconf
  falls back to using the readline frontend.

  The user sees the prompt: "What would you like to do about menu.lst?"
  but is not presented with the list of options to choose from.

  If a valid option is typed in, debconf will continue processing
  correctly and the list of options  appears on the screen. See also
  https://pastebin.ubuntu.com/p/8xvSn88SKG/

  STEPS TO REPRODUCE:

  Launch the minimal Bionic image with serial 20190212 http://cloud-
  images.ubuntu.com/minimal/releases/bionic/release-20190212/ubuntu-18.04
  -minimal-cloudimg-amd64.img

  for example via multipass and run `apt-get update` and `apt-get dist-
  upgrade`.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+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 1822270] Re: Debconf readline frontend does not show options

2019-05-07 Thread Heitor Alves de Siqueira
** Patch added: "lp1822270-xenial.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+attachment/5262101/+files/lp1822270-xenial.debdiff

** Tags added: sts-sponsor

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

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  Fix Released
Status in debconf source package in Xenial:
  Confirmed
Status in debconf source package in Bionic:
  Confirmed
Status in debconf source package in Cosmic:
  Confirmed
Status in debconf source package in Disco:
  Confirmed
Status in debconf source package in Eoan:
  Fix Released
Status in debconf package in Debian:
  Fix Released

Bug description:
  [Impact]
  debconf prompts the user for input before displaying options

  [Description]
  When upgrading packages with apt or dpkg, debconf scripts are ran through 
'run-parts' with the '--report' flag. This causes script output to be handled 
through pipes set up by run-parts, and buffers output from maintainer scripts 
nicely for formatting.

  If debconf makes use of the readline frontend, any prompts will bypass
  the run-parts buffers and be displayed directly to /dev/tty. This
  generally causes the prompt to be displayed before the user gets any
  of the available options for it, and printing will block until the
  user inputs a valid option.

  Upstream commit: https://salsa.debian.org/pkg-
  debconf/debconf/commit/48c5ce38cfd5

  [Test Case]
  1) Deploy a VM through e.g. uvt-kvm
  $ uvt-kvm create disco release=disco

  2) Remove the whiptail package to force the readline frontend in debconf
  root@disco:~# apt remove --purge whiptail -y

  3) Install grub-legacy-ec2 and prepare /boot/grub/menu.lst for an upgrade 
through run-parts
  root@disco:~# apt update && apt install -y grub-legacy-ec2
  root@disco:~# rm -f /boot/grub/menu.lst*
  root@disco:~# touch -d "4 years ago" /boot/grub/menu.lst

  4) Invoke run-parts as in a kernel upgrade (kernel version doesn't matter, we 
just need it to think menu.lst needs an upgrade)
  root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
  ...
  /etc/kernel/postinst.d/x-grub-legacy-ec2:
  debconf: unable to initialize frontend: Dialog
  debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
  debconf: falling back to frontend: Readline
  Searching for GRUB installation directory ... found: /boot/grub
  Searching for default file ... found: /boot/grub/default
  Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
  Searching for splash image ... none found, skipping ...
  What would you like to do about menu.lst?

  The "What would you like to do about menu.lst?" prompt will block
  until the user enter a valid option, even though it's being displayed
  before the available options.

  [Regression Potential]
  We could hit regressions if changing debconf's printing to /dev/tty is 
expected by other programs. The changes are needed only in the readline 
frontend, so that would minimize impact of any possible regressions. The fixes 
will be thoroughly tested with autopkgtest and use-case scenarios.

  # # # #

  [Original Description]
  When upgrading the kernel on a recent Bionic minimal image, the user is 
prompted to resolve a conflict in the file /boot/grub/menu.lst.

  The minimal images do not have dialog/whiptail installed, so debconf
  falls back to using the readline frontend.

  The user sees the prompt: "What would you like to do about menu.lst?"
  but is not presented with the list of options to choose from.

  If a valid option is typed in, debconf will continue processing
  correctly and the list of options  appears on the screen. See also
  https://pastebin.ubuntu.com/p/8xvSn88SKG/

  STEPS TO REPRODUCE:

  Launch the minimal Bionic image with serial 20190212 http://cloud-
  images.ubuntu.com/minimal/releases/bionic/release-20190212/ubuntu-18.04
  -minimal-cloudimg-amd64.img

  for example via multipass and run `apt-get update` and `apt-get dist-
  upgrade`.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+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 1822270] Re: Debconf readline frontend does not show options

2019-05-07 Thread Heitor Alves de Siqueira
** Patch added: "lp1822270-disco.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+attachment/5262098/+files/lp1822270-disco.debdiff

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

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  Fix Released
Status in debconf source package in Xenial:
  Confirmed
Status in debconf source package in Bionic:
  Confirmed
Status in debconf source package in Cosmic:
  Confirmed
Status in debconf source package in Disco:
  Confirmed
Status in debconf source package in Eoan:
  Fix Released
Status in debconf package in Debian:
  Fix Released

Bug description:
  [Impact]
  debconf prompts the user for input before displaying options

  [Description]
  When upgrading packages with apt or dpkg, debconf scripts are ran through 
'run-parts' with the '--report' flag. This causes script output to be handled 
through pipes set up by run-parts, and buffers output from maintainer scripts 
nicely for formatting.

  If debconf makes use of the readline frontend, any prompts will bypass
  the run-parts buffers and be displayed directly to /dev/tty. This
  generally causes the prompt to be displayed before the user gets any
  of the available options for it, and printing will block until the
  user inputs a valid option.

  Upstream commit: https://salsa.debian.org/pkg-
  debconf/debconf/commit/48c5ce38cfd5

  [Test Case]
  1) Deploy a VM through e.g. uvt-kvm
  $ uvt-kvm create disco release=disco

  2) Remove the whiptail package to force the readline frontend in debconf
  root@disco:~# apt remove --purge whiptail -y

  3) Install grub-legacy-ec2 and prepare /boot/grub/menu.lst for an upgrade 
through run-parts
  root@disco:~# apt update && apt install -y grub-legacy-ec2
  root@disco:~# rm -f /boot/grub/menu.lst*
  root@disco:~# touch -d "4 years ago" /boot/grub/menu.lst

  4) Invoke run-parts as in a kernel upgrade (kernel version doesn't matter, we 
just need it to think menu.lst needs an upgrade)
  root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
  ...
  /etc/kernel/postinst.d/x-grub-legacy-ec2:
  debconf: unable to initialize frontend: Dialog
  debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
  debconf: falling back to frontend: Readline
  Searching for GRUB installation directory ... found: /boot/grub
  Searching for default file ... found: /boot/grub/default
  Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
  Searching for splash image ... none found, skipping ...
  What would you like to do about menu.lst?

  The "What would you like to do about menu.lst?" prompt will block
  until the user enter a valid option, even though it's being displayed
  before the available options.

  [Regression Potential]
  We could hit regressions if changing debconf's printing to /dev/tty is 
expected by other programs. The changes are needed only in the readline 
frontend, so that would minimize impact of any possible regressions. The fixes 
will be thoroughly tested with autopkgtest and use-case scenarios.

  # # # #

  [Original Description]
  When upgrading the kernel on a recent Bionic minimal image, the user is 
prompted to resolve a conflict in the file /boot/grub/menu.lst.

  The minimal images do not have dialog/whiptail installed, so debconf
  falls back to using the readline frontend.

  The user sees the prompt: "What would you like to do about menu.lst?"
  but is not presented with the list of options to choose from.

  If a valid option is typed in, debconf will continue processing
  correctly and the list of options  appears on the screen. See also
  https://pastebin.ubuntu.com/p/8xvSn88SKG/

  STEPS TO REPRODUCE:

  Launch the minimal Bionic image with serial 20190212 http://cloud-
  images.ubuntu.com/minimal/releases/bionic/release-20190212/ubuntu-18.04
  -minimal-cloudimg-amd64.img

  for example via multipass and run `apt-get update` and `apt-get dist-
  upgrade`.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+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 1822270] Re: Debconf readline frontend does not show options

2019-05-06 Thread Heitor Alves de Siqueira
** Description changed:

  [Impact]
  debconf prompts the user for input before displaying options
  
  [Description]
  When upgrading packages with apt or dpkg, debconf scripts are ran through 
'run-parts' with the '--report' flag. This causes script output to be handled 
through pipes set up by run-parts, and buffers output from maintainer scripts 
nicely for formatting.
  
  If debconf makes use of the readline frontend, any prompts will bypass
  the run-parts buffers and be displayed directly to /dev/tty. This
  generally causes the prompt to be displayed before the user gets any of
  the available options for it, and printing will block until the user
  inputs a valid option.
+ 
+ Upstream commit: https://salsa.debian.org/pkg-
+ debconf/debconf/commit/48c5ce38cfd5
  
  [Test Case]
  1) Deploy a VM through e.g. uvt-kvm
  $ uvt-kvm create disco release=disco
  
  2) Remove the whiptail package to force the readline frontend in debconf
  root@disco:~# apt remove --purge whiptail -y
  
  3) Install grub-legacy-ec2 and prepare /boot/grub/menu.lst for an upgrade 
through run-parts
  root@disco:~# apt update && apt install -y grub-legacy-ec2
  root@disco:~# rm -f /boot/grub/menu.lst*
  root@disco:~# touch -d "4 years ago" /boot/grub/menu.lst
  
  4) Invoke run-parts as in a kernel upgrade (kernel version doesn't matter, we 
just need it to think menu.lst needs an upgrade)
  root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
  ...
  /etc/kernel/postinst.d/x-grub-legacy-ec2:
  debconf: unable to initialize frontend: Dialog
  debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
  debconf: falling back to frontend: Readline
  Searching for GRUB installation directory ... found: /boot/grub
  Searching for default file ... found: /boot/grub/default
  Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
  Searching for splash image ... none found, skipping ...
- What would you like to do about menu.lst? 
+ What would you like to do about menu.lst?
  
  The "What would you like to do about menu.lst?" prompt will block until
  the user enter a valid option, even though it's being displayed before
  the available options.
  
  [Regression Potential]
  We could hit regressions if changing debconf's printing to /dev/tty is 
expected by other programs. The changes are needed only in the readline 
frontend, so that would minimize impact of any possible regressions. The fixes 
will be thoroughly tested with autopkgtest and use-case scenarios.
  
  # # # #
  
  [Original Description]
  When upgrading the kernel on a recent Bionic minimal image, the user is 
prompted to resolve a conflict in the file /boot/grub/menu.lst.
  
  The minimal images do not have dialog/whiptail installed, so debconf
  falls back to using the readline frontend.
  
  The user sees the prompt: "What would you like to do about menu.lst?"
  but is not presented with the list of options to choose from.
  
  If a valid option is typed in, debconf will continue processing
  correctly and the list of options  appears on the screen. See also
  https://pastebin.ubuntu.com/p/8xvSn88SKG/
  
  STEPS TO REPRODUCE:
  
  Launch the minimal Bionic image with serial 20190212 http://cloud-
  images.ubuntu.com/minimal/releases/bionic/release-20190212/ubuntu-18.04
  -minimal-cloudimg-amd64.img
  
  for example via multipass and run `apt-get update` and `apt-get dist-
  upgrade`.

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

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  Confirmed
Status in debconf source package in Xenial:
  Confirmed
Status in debconf source package in Bionic:
  Confirmed
Status in debconf source package in Cosmic:
  Confirmed
Status in debconf source package in Disco:
  Confirmed
Status in debconf source package in Eoan:
  Confirmed
Status in debconf package in Debian:
  Fix Committed

Bug description:
  [Impact]
  debconf prompts the user for input before displaying options

  [Description]
  When upgrading packages with apt or dpkg, debconf scripts are ran through 
'run-parts' with the '--report' flag. This causes script output to be handled 
through pipes set up by run-parts, and buffers output from maintainer scripts 
nicely for formatting.

  If debconf makes use of the readline frontend, any prompts will bypass
  the run-parts buffers and be displayed directly to /dev/tty. This
  generally causes the prompt to be displayed before the user gets any
  of the available options for it, and printing will block until the
  user inputs a valid option.

  Upstream commit: https://salsa.debian.org/pkg-
  debconf/debconf/commit/48c5ce38cfd5

  [Test Case]
  1) Deploy a VM through e.g. uvt-kvm
  $ uvt-kvm create 

[Touch-packages] [Bug 1822270] Re: Debconf readline frontend does not show options

2019-04-29 Thread Heitor Alves de Siqueira
** Bug watch added: Debian Bug tracker #928182
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928182

** Also affects: debconf (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928182
   Importance: Unknown
   Status: Unknown

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

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  Confirmed
Status in debconf source package in Xenial:
  Confirmed
Status in debconf source package in Bionic:
  Confirmed
Status in debconf source package in Cosmic:
  Confirmed
Status in debconf source package in Disco:
  Confirmed
Status in debconf source package in Eoan:
  Confirmed
Status in debconf package in Debian:
  Unknown

Bug description:
  [Impact]
  debconf prompts the user for input before displaying options

  [Description]
  When upgrading packages with apt or dpkg, debconf scripts are ran through 
'run-parts' with the '--report' flag. This causes script output to be handled 
through pipes set up by run-parts, and buffers output from maintainer scripts 
nicely for formatting.

  If debconf makes use of the readline frontend, any prompts will bypass
  the run-parts buffers and be displayed directly to /dev/tty. This
  generally causes the prompt to be displayed before the user gets any
  of the available options for it, and printing will block until the
  user inputs a valid option.

  [Test Case]
  1) Deploy a VM through e.g. uvt-kvm
  $ uvt-kvm create disco release=disco

  2) Remove the whiptail package to force the readline frontend in debconf
  root@disco:~# apt remove --purge whiptail -y

  3) Install grub-legacy-ec2 and prepare /boot/grub/menu.lst for an upgrade 
through run-parts
  root@disco:~# apt update && apt install -y grub-legacy-ec2
  root@disco:~# rm -f /boot/grub/menu.lst*
  root@disco:~# touch -d "4 years ago" /boot/grub/menu.lst

  4) Invoke run-parts as in a kernel upgrade (kernel version doesn't matter, we 
just need it to think menu.lst needs an upgrade)
  root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
  ...
  /etc/kernel/postinst.d/x-grub-legacy-ec2:
  debconf: unable to initialize frontend: Dialog
  debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
  debconf: falling back to frontend: Readline
  Searching for GRUB installation directory ... found: /boot/grub
  Searching for default file ... found: /boot/grub/default
  Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
  Searching for splash image ... none found, skipping ...
  What would you like to do about menu.lst? 

  The "What would you like to do about menu.lst?" prompt will block
  until the user enter a valid option, even though it's being displayed
  before the available options.

  [Regression Potential]
  We could hit regressions if changing debconf's printing to /dev/tty is 
expected by other programs. The changes are needed only in the readline 
frontend, so that would minimize impact of any possible regressions. The fixes 
will be thoroughly tested with autopkgtest and use-case scenarios.

  # # # #

  [Original Description]
  When upgrading the kernel on a recent Bionic minimal image, the user is 
prompted to resolve a conflict in the file /boot/grub/menu.lst.

  The minimal images do not have dialog/whiptail installed, so debconf
  falls back to using the readline frontend.

  The user sees the prompt: "What would you like to do about menu.lst?"
  but is not presented with the list of options to choose from.

  If a valid option is typed in, debconf will continue processing
  correctly and the list of options  appears on the screen. See also
  https://pastebin.ubuntu.com/p/8xvSn88SKG/

  STEPS TO REPRODUCE:

  Launch the minimal Bionic image with serial 20190212 http://cloud-
  images.ubuntu.com/minimal/releases/bionic/release-20190212/ubuntu-18.04
  -minimal-cloudimg-amd64.img

  for example via multipass and run `apt-get update` and `apt-get dist-
  upgrade`.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+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 1822270] Re: Debconf readline frontend does not show options

2019-04-24 Thread Heitor Alves de Siqueira
** Tags added: sts

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

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  Confirmed
Status in debconf source package in Xenial:
  Confirmed
Status in debconf source package in Bionic:
  Confirmed
Status in debconf source package in Cosmic:
  Confirmed
Status in debconf source package in Disco:
  Confirmed
Status in debconf source package in Eoan:
  Confirmed

Bug description:
  [Impact]
  debconf prompts the user for input before displaying options

  [Description]
  When upgrading packages with apt or dpkg, debconf scripts are ran through 
'run-parts' with the '--report' flag. This causes script output to be handled 
through pipes set up by run-parts, and buffers output from maintainer scripts 
nicely for formatting.

  If debconf makes use of the readline frontend, any prompts will bypass
  the run-parts buffers and be displayed directly to /dev/tty. This
  generally causes the prompt to be displayed before the user gets any
  of the available options for it, and printing will block until the
  user inputs a valid option.

  [Test Case]
  1) Deploy a VM through e.g. uvt-kvm
  $ uvt-kvm create disco release=disco

  2) Remove the whiptail package to force the readline frontend in debconf
  root@disco:~# apt remove --purge whiptail -y

  3) Install grub-legacy-ec2 and prepare /boot/grub/menu.lst for an upgrade 
through run-parts
  root@disco:~# apt update && apt install -y grub-legacy-ec2
  root@disco:~# rm -f /boot/grub/menu.lst*
  root@disco:~# touch -d "4 years ago" /boot/grub/menu.lst

  4) Invoke run-parts as in a kernel upgrade (kernel version doesn't matter, we 
just need it to think menu.lst needs an upgrade)
  root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
  ...
  /etc/kernel/postinst.d/x-grub-legacy-ec2:
  debconf: unable to initialize frontend: Dialog
  debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
  debconf: falling back to frontend: Readline
  Searching for GRUB installation directory ... found: /boot/grub
  Searching for default file ... found: /boot/grub/default
  Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
  Searching for splash image ... none found, skipping ...
  What would you like to do about menu.lst? 

  The "What would you like to do about menu.lst?" prompt will block
  until the user enter a valid option, even though it's being displayed
  before the available options.

  [Regression Potential]
  We could hit regressions if changing debconf's printing to /dev/tty is 
expected by other programs. The changes are needed only in the readline 
frontend, so that would minimize impact of any possible regressions. The fixes 
will be thoroughly tested with autopkgtest and use-case scenarios.

  # # # #

  [Original Description]
  When upgrading the kernel on a recent Bionic minimal image, the user is 
prompted to resolve a conflict in the file /boot/grub/menu.lst.

  The minimal images do not have dialog/whiptail installed, so debconf
  falls back to using the readline frontend.

  The user sees the prompt: "What would you like to do about menu.lst?"
  but is not presented with the list of options to choose from.

  If a valid option is typed in, debconf will continue processing
  correctly and the list of options  appears on the screen. See also
  https://pastebin.ubuntu.com/p/8xvSn88SKG/

  STEPS TO REPRODUCE:

  Launch the minimal Bionic image with serial 20190212 http://cloud-
  images.ubuntu.com/minimal/releases/bionic/release-20190212/ubuntu-18.04
  -minimal-cloudimg-amd64.img

  for example via multipass and run `apt-get update` and `apt-get dist-
  upgrade`.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+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 1822270] Re: Debconf readline frontend does not show options

2019-04-23 Thread Heitor Alves de Siqueira
** Description changed:

- AFFECTED RELEASE:
+ [Impact]
+ debconf prompts the user for input before displaying options
  
- Bionic
+ [Description]
+ When upgrading packages with apt or dpkg, debconf scripts are ran through 
'run-parts' with the '--report' flag. This causes script output to be handled 
through pipes set up by run-parts, and buffers output from maintainer scripts 
nicely for formatting.
  
- PACKAGE VERSION:
+ If debconf makes use of the readline frontend, any prompts will bypass
+ the run-parts buffers and be displayed directly to /dev/tty. This
+ generally causes the prompt to be displayed before the user gets any of
+ the available options for it, and printing will block until the user
+ inputs a valid option.
  
- debconf - 1.5.66
+ [Test Case]
+ 1) Deploy a VM through e.g. uvt-kvm
+ $ uvt-kvm create disco release=disco
  
- DESCRIPTION:
+ 2) Remove the whiptail package to force the readline frontend in debconf
+ root@disco:~# apt remove --purge whiptail -y
  
- When upgrading the kernel on a recent Bionic minimal image, the user is
- prompted to resolve a conflict in the file /boot/grub/menu.lst.
+ 3) Install grub-legacy-ec2 and prepare /boot/grub/menu.lst for an upgrade 
through run-parts
+ root@disco:~# apt update && apt install -y grub-legacy-ec2
+ root@disco:~# rm -f /boot/grub/menu.lst*
+ root@disco:~# touch -d "4 years ago" /boot/grub/menu.lst
+ 
+ 4) Invoke run-parts as in a kernel upgrade (kernel version doesn't matter, we 
just need it to think menu.lst needs an upgrade)
+ root@disco:~# run-parts --exit-on-error --arg=5.0.0 /etc/kernel/postinst.d 
--report
+ ...
+ /etc/kernel/postinst.d/x-grub-legacy-ec2:
+ debconf: unable to initialize frontend: Dialog
+ debconf: (No usable dialog-like program is installed, so the dialog based 
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 
76.)
+ debconf: falling back to frontend: Readline
+ Searching for GRUB installation directory ... found: /boot/grub
+ Searching for default file ... found: /boot/grub/default
+ Testing for an existing GRUB menu.lst file ... found: /boot/grub/menu.lst
+ Searching for splash image ... none found, skipping ...
+ What would you like to do about menu.lst? 
+ 
+ The "What would you like to do about menu.lst?" prompt will block until
+ the user enter a valid option, even though it's being displayed before
+ the available options.
+ 
+ [Regression Potential]
+ We could hit regressions if changing debconf's printing to /dev/tty is 
expected by other programs. The changes are needed only in the readline 
frontend, so that would minimize impact of any possible regressions. The fixes 
will be thoroughly tested with autopkgtest and use-case scenarios.
+ 
+ # # # #
+ 
+ [Original Description]
+ When upgrading the kernel on a recent Bionic minimal image, the user is 
prompted to resolve a conflict in the file /boot/grub/menu.lst.
  
  The minimal images do not have dialog/whiptail installed, so debconf
  falls back to using the readline frontend.
  
  The user sees the prompt: "What would you like to do about menu.lst?"
  but is not presented with the list of options to choose from.
  
  If a valid option is typed in, debconf will continue processing
  correctly and the list of options  appears on the screen. See also
  https://pastebin.ubuntu.com/p/8xvSn88SKG/
  
  STEPS TO REPRODUCE:
  
  Launch the minimal Bionic image with serial 20190212 http://cloud-
  images.ubuntu.com/minimal/releases/bionic/release-20190212/ubuntu-18.04
  -minimal-cloudimg-amd64.img
  
  for example via multipass and run `apt-get update` and `apt-get dist-
  upgrade`.

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

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  Confirmed
Status in debconf source package in Xenial:
  Confirmed
Status in debconf source package in Bionic:
  Confirmed
Status in debconf source package in Cosmic:
  Confirmed
Status in debconf source package in Disco:
  Confirmed
Status in debconf source package in Eoan:
  Confirmed

Bug description:
  [Impact]
  debconf prompts the user for input before displaying options

  [Description]
  When upgrading packages with apt or dpkg, debconf scripts are ran through 
'run-parts' with the '--report' flag. This causes script output to be handled 
through pipes set up by run-parts, and buffers output from maintainer scripts 
nicely for formatting.

  If debconf makes use of the readline frontend, any prompts will bypass
  the run-parts buffers and be displayed directly to /dev/tty. This
  generally causes the prompt to be displayed before the user gets any
  of the available options for it, and printing will block until the
  user inputs a valid option.

  [Test Case]
  1) Deploy a VM through e.g. uvt-kvm
  $ uvt-kvm create disco release=disco

  2) Remove the whiptail package to 

[Touch-packages] [Bug 1822270] Re: Debconf readline frontend does not show options

2019-04-23 Thread Heitor Alves de Siqueira
** Changed in: debconf (Ubuntu Xenial)
   Status: New => Confirmed

** Changed in: debconf (Ubuntu Disco)
   Importance: Undecided => Medium

** Changed in: debconf (Ubuntu Disco)
   Importance: Medium => High

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

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

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

** Changed in: debconf (Ubuntu Eoan)
 Assignee: (unassigned) => Heitor Alves de Siqueira (halves)

** Changed in: debconf (Ubuntu Disco)
 Assignee: (unassigned) => Heitor Alves de Siqueira (halves)

** Changed in: debconf (Ubuntu Cosmic)
 Assignee: (unassigned) => Heitor Alves de Siqueira (halves)

** Changed in: debconf (Ubuntu Bionic)
 Assignee: (unassigned) => Heitor Alves de Siqueira (halves)

** Changed in: debconf (Ubuntu Xenial)
 Assignee: (unassigned) => Heitor Alves de Siqueira (halves)

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

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  Confirmed
Status in debconf source package in Xenial:
  Confirmed
Status in debconf source package in Bionic:
  Confirmed
Status in debconf source package in Cosmic:
  Confirmed
Status in debconf source package in Disco:
  Confirmed
Status in debconf source package in Eoan:
  Confirmed

Bug description:
  AFFECTED RELEASE:

  Bionic

  PACKAGE VERSION:

  debconf - 1.5.66

  DESCRIPTION:

  When upgrading the kernel on a recent Bionic minimal image, the user
  is prompted to resolve a conflict in the file /boot/grub/menu.lst.

  The minimal images do not have dialog/whiptail installed, so debconf
  falls back to using the readline frontend.

  The user sees the prompt: "What would you like to do about menu.lst?"
  but is not presented with the list of options to choose from.

  If a valid option is typed in, debconf will continue processing
  correctly and the list of options  appears on the screen. See also
  https://pastebin.ubuntu.com/p/8xvSn88SKG/

  STEPS TO REPRODUCE:

  Launch the minimal Bionic image with serial 20190212 http://cloud-
  images.ubuntu.com/minimal/releases/bionic/release-20190212/ubuntu-18.04
  -minimal-cloudimg-amd64.img

  for example via multipass and run `apt-get update` and `apt-get dist-
  upgrade`.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+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 1822270] Re: Debconf readline frontend does not show options

2019-04-23 Thread Heitor Alves de Siqueira
** Also affects: debconf (Ubuntu Eoan)
   Importance: High
   Status: Confirmed

** Also affects: debconf (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

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

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

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

** Changed in: debconf (Ubuntu Disco)
   Status: New => Confirmed

** Changed in: debconf (Ubuntu Cosmic)
   Status: New => Confirmed

** Changed in: debconf (Ubuntu Bionic)
   Status: New => Confirmed

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

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  Confirmed
Status in debconf source package in Xenial:
  New
Status in debconf source package in Bionic:
  Confirmed
Status in debconf source package in Cosmic:
  Confirmed
Status in debconf source package in Disco:
  Confirmed
Status in debconf source package in Eoan:
  Confirmed

Bug description:
  AFFECTED RELEASE:

  Bionic

  PACKAGE VERSION:

  debconf - 1.5.66

  DESCRIPTION:

  When upgrading the kernel on a recent Bionic minimal image, the user
  is prompted to resolve a conflict in the file /boot/grub/menu.lst.

  The minimal images do not have dialog/whiptail installed, so debconf
  falls back to using the readline frontend.

  The user sees the prompt: "What would you like to do about menu.lst?"
  but is not presented with the list of options to choose from.

  If a valid option is typed in, debconf will continue processing
  correctly and the list of options  appears on the screen. See also
  https://pastebin.ubuntu.com/p/8xvSn88SKG/

  STEPS TO REPRODUCE:

  Launch the minimal Bionic image with serial 20190212 http://cloud-
  images.ubuntu.com/minimal/releases/bionic/release-20190212/ubuntu-18.04
  -minimal-cloudimg-amd64.img

  for example via multipass and run `apt-get update` and `apt-get dist-
  upgrade`.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+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 1821343] Re: slapd process failure is not detected by systemd

2019-04-22 Thread Heitor Alves de Siqueira
There's a failing autopkgtest for gnupg2 that flagged this openldap
update for cosmic, but openldap looks fine.

Checking autopkgtest logs for gnupg2 [0], the tests were failing before
the openldap update, and it's not related to this fix. The culprit seems
to be a dependency problem with wine/libwine [1].

[0] http://autopkgtest.ubuntu.com/packages/g/gnupg2/cosmic/amd64
[1] 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/g/gnupg2/20190416_135202_50915@/log.gz

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

Title:
  slapd process failure is not detected by systemd

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Cosmic:
  Fix Committed
Status in openldap package in Debian:
  New

Bug description:
  [Impact]
  Systemd service reports slapd as active, even though it may have failed

  [Description]
  The slapd package for OpenLDAP is shipped with a SysV-style init script 
(/etc/init.d/slapd). Systemd automatically converts this to a systemd service 
by generating the unit file using the systemd-sysv-generator(8) utility. The 
generated unit file contains Type=forking and RemainAfterExit=yes directives.

  If the slapd daemon process exits due to some failure (e.g., it
  receives a SIGTERM or SIGKILL), the failure is not detected properly
  by systemd. The service is still reported as active even though the
  child (daemon) process has exited with a signal.

  We can easily fix this by including a proper systemd service file for
  slapd in the openldap package. Since the init.d script already does
  most of the necessary work (parsing configs, setting up PID files,
  etc.), we don't need anything complicated for the systemd unit file.
  Just making sure that RemainAfterExit is set to "no" makes the systemd
  service behave in the expected way.

  [Test Case]
  1) Deploy a disco container
  $ lxc launch images:ubuntu/disco disco

  2) Install slapd
  ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y

  3) Verify that slapd is running with the auto-generated service
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago
   Docs: man:systemd-sysv-generator(8)
    Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
  Tasks: 3 (limit: 4915)
     Memory: 712.6M
     CGroup: /system.slice/slapd.service
     └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u 
openldap -F /etc/ldap/slapd.d

  4) SIGKILL the slapd process (PID is displayed in systemctl status output)
  ubuntu@disco:~$ sudo kill -9 1109

  5) Check if systemd service lists slapd as still active, even though it was 
terminated
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago
   Docs: man:systemd-sysv-generator(8)
    Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)

  6) Check if systemd has loaded both
  /run/systemd/generator.late/slapd.service &
  /usr/lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf

  $ systemctl cat slapd

  [Regression Potential]
  The regression potential for this fix should be very low, if we keep the new 
systemd unit file close to the one generated by systemd-sysv-generator(8). The 
only significant change would be the RemainAfterExit directive, and this should 
make the slapd service behave like a "normal" forking service. Nonetheless, 
we'll perform scripted test runs to make sure no regressions arise.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+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 1821343] Re: slapd process failure is not detected by systemd

2019-04-22 Thread Heitor Alves de Siqueira
Verified according to test case in description for xenial:

root@xenial:~# dpkg -l | grep slapd
ii  slapd2.4.42+dfsg-2ubuntu3.5 
amd64OpenLDAP server (slapd)

root@xenial:~# systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access 
Protocol)
   Loaded: loaded (/etc/init.d/slapd; bad; vendor preset: enabled)
  Drop-In: /lib/systemd/system/slapd.service.d
   └─slapd-remain-after-exit.conf
   Active: active (running) since Mon 2019-04-22 20:23:10 UTC; 14s ago
 Docs: man:systemd-sysv-generator(8)
   CGroup: /system.slice/slapd.service
   └─5920 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap 
-F /etc/ldap/slapd.d

root@xenial:~# kill -9 5920

root@xenial:~# systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access 
Protocol)
   Loaded: loaded (/etc/init.d/slapd; bad; vendor preset: enabled)
  Drop-In: /lib/systemd/system/slapd.service.d
   └─slapd-remain-after-exit.conf
   Active: inactive (dead) since Mon 2019-04-22 20:23:30 UTC; 1s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 5989 ExecStop=/etc/init.d/slapd stop (code=exited, status=0/SUCCESS)

root@xenial:~# systemctl cat slapd
# /run/systemd/generator.late/slapd.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/slapd
Description=LSB: OpenLDAP standalone server (Lightweight Directory Access 
Protocol)
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
Before=shutdown.target
After=remote-fs.target
After=network-online.target
After=systemd-journald-dev-log.socket
Wants=network-online.target
Conflicts=shutdown.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
ExecStart=/etc/init.d/slapd start
ExecStop=/etc/init.d/slapd stop

# /lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf
[Service]
Type=forking
RemainAfterExit=no

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

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

Title:
  slapd process failure is not detected by systemd

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Cosmic:
  Fix Committed
Status in openldap package in Debian:
  New

Bug description:
  [Impact]
  Systemd service reports slapd as active, even though it may have failed

  [Description]
  The slapd package for OpenLDAP is shipped with a SysV-style init script 
(/etc/init.d/slapd). Systemd automatically converts this to a systemd service 
by generating the unit file using the systemd-sysv-generator(8) utility. The 
generated unit file contains Type=forking and RemainAfterExit=yes directives.

  If the slapd daemon process exits due to some failure (e.g., it
  receives a SIGTERM or SIGKILL), the failure is not detected properly
  by systemd. The service is still reported as active even though the
  child (daemon) process has exited with a signal.

  We can easily fix this by including a proper systemd service file for
  slapd in the openldap package. Since the init.d script already does
  most of the necessary work (parsing configs, setting up PID files,
  etc.), we don't need anything complicated for the systemd unit file.
  Just making sure that RemainAfterExit is set to "no" makes the systemd
  service behave in the expected way.

  [Test Case]
  1) Deploy a disco container
  $ lxc launch images:ubuntu/disco disco

  2) Install slapd
  ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y

  3) Verify that slapd is running with the auto-generated service
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago
   Docs: man:systemd-sysv-generator(8)
    Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
  Tasks: 3 (limit: 4915)
     Memory: 712.6M
     CGroup: /system.slice/slapd.service
     └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u 
openldap -F /etc/ldap/slapd.d

  4) SIGKILL the slapd process (PID is displayed in systemctl status output)
  ubuntu@disco:~$ sudo kill -9 1109

  5) Check if systemd service lists slapd as still active, even though it was 
terminated
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access 

[Touch-packages] [Bug 1821343] Re: slapd process failure is not detected by systemd

2019-04-22 Thread Heitor Alves de Siqueira
Verified according to test case in description for bionic:

root@bionic:~# dpkg -l | grep slapd
ii  slapd2.4.45+dfsg-1ubuntu1.2amd64
OpenLDAP server (slapd)

root@bionic:~# systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access 
Protocol)
   Loaded: loaded (/etc/init.d/slapd; generated)
  Drop-In: /lib/systemd/system/slapd.service.d
   └─slapd-remain-after-exit.conf
   Active: active (running) since Mon 2019-04-22 20:15:10 UTC; 4min 23s ago
 Docs: man:systemd-sysv-generator(8)
Tasks: 3 (limit: 4915)
   CGroup: /system.slice/slapd.service
   └─907 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap 
-F /etc/ldap/slapd.d

root@bionic:~# kill -9 907

root@bionic:~# systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access 
Protocol)
   Loaded: loaded (/etc/init.d/slapd; generated)
  Drop-In: /lib/systemd/system/slapd.service.d
   └─slapd-remain-after-exit.conf
   Active: inactive (dead) since Mon 2019-04-22 20:19:40 UTC; 1s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 1011 ExecStop=/etc/init.d/slapd stop (code=exited, status=0/SUCCESS)

root@bionic:~# systemctl cat slapd
# /run/systemd/generator.late/slapd.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/slapd
Description=LSB: OpenLDAP standalone server (Lightweight Directory Access 
Protocol)
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=remote-fs.target
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/slapd start
ExecStop=/etc/init.d/slapd stop

# /lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf
[Service]
Type=forking
RemainAfterExit=no

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

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

Title:
  slapd process failure is not detected by systemd

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Cosmic:
  Fix Committed
Status in openldap package in Debian:
  New

Bug description:
  [Impact]
  Systemd service reports slapd as active, even though it may have failed

  [Description]
  The slapd package for OpenLDAP is shipped with a SysV-style init script 
(/etc/init.d/slapd). Systemd automatically converts this to a systemd service 
by generating the unit file using the systemd-sysv-generator(8) utility. The 
generated unit file contains Type=forking and RemainAfterExit=yes directives.

  If the slapd daemon process exits due to some failure (e.g., it
  receives a SIGTERM or SIGKILL), the failure is not detected properly
  by systemd. The service is still reported as active even though the
  child (daemon) process has exited with a signal.

  We can easily fix this by including a proper systemd service file for
  slapd in the openldap package. Since the init.d script already does
  most of the necessary work (parsing configs, setting up PID files,
  etc.), we don't need anything complicated for the systemd unit file.
  Just making sure that RemainAfterExit is set to "no" makes the systemd
  service behave in the expected way.

  [Test Case]
  1) Deploy a disco container
  $ lxc launch images:ubuntu/disco disco

  2) Install slapd
  ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y

  3) Verify that slapd is running with the auto-generated service
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago
   Docs: man:systemd-sysv-generator(8)
    Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
  Tasks: 3 (limit: 4915)
     Memory: 712.6M
     CGroup: /system.slice/slapd.service
     └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u 
openldap -F /etc/ldap/slapd.d

  4) SIGKILL the slapd process (PID is displayed in systemctl status output)
  ubuntu@disco:~$ sudo kill -9 1109

  5) Check if systemd service lists slapd as still active, even though it was 
terminated
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 

[Touch-packages] [Bug 1821343] Re: slapd process failure is not detected by systemd

2019-04-22 Thread Heitor Alves de Siqueira
Verified according to test case in description for cosmic:

root@cosmic:~# dpkg -l | grep slapd
ii  slapd  2.4.46+dfsg-5ubuntu1.2 amd64 
   OpenLDAP server (slapd)

root@cosmic:~# systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access 
Protocol)
   Loaded: loaded (/etc/init.d/slapd; generated)
  Drop-In: /lib/systemd/system/slapd.service.d
   └─slapd-remain-after-exit.conf
   Active: active (running) since Mon 2019-04-22 20:15:01 UTC; 19s ago
 Docs: man:systemd-sysv-generator(8)
Tasks: 3 (limit: 4915)
   Memory: 612.7M
   CGroup: /system.slice/slapd.service
   └─2061 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u openldap 
-F /etc/ldap/slapd.d

root@cosmic:~# kill -9 2061

root@cosmic:~# systemctl status slapd
● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory Access 
Protocol)
   Loaded: loaded (/etc/init.d/slapd; generated)
  Drop-In: /lib/systemd/system/slapd.service.d
   └─slapd-remain-after-exit.conf
   Active: inactive (dead) since Mon 2019-04-22 20:15:40 UTC; 4s ago
 Docs: man:systemd-sysv-generator(8)
  Process: 2145 ExecStop=/etc/init.d/slapd stop (code=exited, status=0/SUCCESS)

root@cosmic:~# systemctl cat slapd
# /run/systemd/generator.late/slapd.service
# Automatically generated by systemd-sysv-generator

[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/slapd
Description=LSB: OpenLDAP standalone server (Lightweight Directory Access 
Protocol)
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=remote-fs.target
After=network-online.target
Wants=network-online.target

[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/slapd start
ExecStop=/etc/init.d/slapd stop

# /lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf
[Service]
Type=forking
RemainAfterExit=no


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

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

Title:
  slapd process failure is not detected by systemd

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  Fix Committed
Status in openldap source package in Bionic:
  Fix Committed
Status in openldap source package in Cosmic:
  Fix Committed
Status in openldap package in Debian:
  New

Bug description:
  [Impact]
  Systemd service reports slapd as active, even though it may have failed

  [Description]
  The slapd package for OpenLDAP is shipped with a SysV-style init script 
(/etc/init.d/slapd). Systemd automatically converts this to a systemd service 
by generating the unit file using the systemd-sysv-generator(8) utility. The 
generated unit file contains Type=forking and RemainAfterExit=yes directives.

  If the slapd daemon process exits due to some failure (e.g., it
  receives a SIGTERM or SIGKILL), the failure is not detected properly
  by systemd. The service is still reported as active even though the
  child (daemon) process has exited with a signal.

  We can easily fix this by including a proper systemd service file for
  slapd in the openldap package. Since the init.d script already does
  most of the necessary work (parsing configs, setting up PID files,
  etc.), we don't need anything complicated for the systemd unit file.
  Just making sure that RemainAfterExit is set to "no" makes the systemd
  service behave in the expected way.

  [Test Case]
  1) Deploy a disco container
  $ lxc launch images:ubuntu/disco disco

  2) Install slapd
  ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y

  3) Verify that slapd is running with the auto-generated service
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago
   Docs: man:systemd-sysv-generator(8)
    Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
  Tasks: 3 (limit: 4915)
     Memory: 712.6M
     CGroup: /system.slice/slapd.service
     └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u 
openldap -F /etc/ldap/slapd.d

  4) SIGKILL the slapd process (PID is displayed in systemctl status output)
  ubuntu@disco:~$ sudo kill -9 1109

  5) Check if systemd service lists slapd as still active, even though it was 
terminated
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (exited) since Fri 

[Touch-packages] [Bug 1821343] Re: slapd process failure is not detected by systemd

2019-04-10 Thread Heitor Alves de Siqueira
** Patch added: "lp1821343-bionic.debdiff"
   
https://bugs.launchpad.net/debian/+source/openldap/+bug/1821343/+attachment/5254687/+files/lp1821343-bionic.debdiff

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

Title:
  slapd process failure is not detected by systemd

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  Confirmed
Status in openldap source package in Bionic:
  Confirmed
Status in openldap source package in Cosmic:
  Confirmed
Status in openldap package in Debian:
  New

Bug description:
  [Impact]
  Systemd service reports slapd as active, even though it may have failed

  [Description]
  The slapd package for OpenLDAP is shipped with a SysV-style init script 
(/etc/init.d/slapd). Systemd automatically converts this to a systemd service 
by generating the unit file using the systemd-sysv-generator(8) utility. The 
generated unit file contains Type=forking and RemainAfterExit=yes directives.

  If the slapd daemon process exits due to some failure (e.g., it
  receives a SIGTERM or SIGKILL), the failure is not detected properly
  by systemd. The service is still reported as active even though the
  child (daemon) process has exited with a signal.

  We can easily fix this by including a proper systemd service file for
  slapd in the openldap package. Since the init.d script already does
  most of the necessary work (parsing configs, setting up PID files,
  etc.), we don't need anything complicated for the systemd unit file.
  Just making sure that RemainAfterExit is set to "no" makes the systemd
  service behave in the expected way.

  [Test Case]
  1) Deploy a disco container
  $ lxc launch images:ubuntu/disco disco

  2) Install slapd
  ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y

  3) Verify that slapd is running with the auto-generated service
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago
   Docs: man:systemd-sysv-generator(8)
    Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
  Tasks: 3 (limit: 4915)
     Memory: 712.6M
     CGroup: /system.slice/slapd.service
     └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u 
openldap -F /etc/ldap/slapd.d

  4) SIGKILL the slapd process (PID is displayed in systemctl status output)
  ubuntu@disco:~$ sudo kill -9 1109

  5) Check if systemd service lists slapd as still active, even though it was 
terminated
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago
   Docs: man:systemd-sysv-generator(8)
    Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)

  6) Check if systemd has loaded both
  /run/systemd/generator.late/slapd.service &
  /usr/lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf

  $ systemctl cat slapd

  [Regression Potential]
  The regression potential for this fix should be very low, if we keep the new 
systemd unit file close to the one generated by systemd-sysv-generator(8). The 
only significant change would be the RemainAfterExit directive, and this should 
make the slapd service behave like a "normal" forking service. Nonetheless, 
we'll perform scripted test runs to make sure no regressions arise.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+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 1821343] Re: slapd process failure is not detected by systemd

2019-04-10 Thread Heitor Alves de Siqueira
** Patch added: "lp1821343-cosmic.debdiff"
   
https://bugs.launchpad.net/debian/+source/openldap/+bug/1821343/+attachment/5254686/+files/lp1821343-cosmic.debdiff

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

Title:
  slapd process failure is not detected by systemd

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  Confirmed
Status in openldap source package in Bionic:
  Confirmed
Status in openldap source package in Cosmic:
  Confirmed
Status in openldap package in Debian:
  New

Bug description:
  [Impact]
  Systemd service reports slapd as active, even though it may have failed

  [Description]
  The slapd package for OpenLDAP is shipped with a SysV-style init script 
(/etc/init.d/slapd). Systemd automatically converts this to a systemd service 
by generating the unit file using the systemd-sysv-generator(8) utility. The 
generated unit file contains Type=forking and RemainAfterExit=yes directives.

  If the slapd daemon process exits due to some failure (e.g., it
  receives a SIGTERM or SIGKILL), the failure is not detected properly
  by systemd. The service is still reported as active even though the
  child (daemon) process has exited with a signal.

  We can easily fix this by including a proper systemd service file for
  slapd in the openldap package. Since the init.d script already does
  most of the necessary work (parsing configs, setting up PID files,
  etc.), we don't need anything complicated for the systemd unit file.
  Just making sure that RemainAfterExit is set to "no" makes the systemd
  service behave in the expected way.

  [Test Case]
  1) Deploy a disco container
  $ lxc launch images:ubuntu/disco disco

  2) Install slapd
  ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y

  3) Verify that slapd is running with the auto-generated service
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago
   Docs: man:systemd-sysv-generator(8)
    Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
  Tasks: 3 (limit: 4915)
     Memory: 712.6M
     CGroup: /system.slice/slapd.service
     └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u 
openldap -F /etc/ldap/slapd.d

  4) SIGKILL the slapd process (PID is displayed in systemctl status output)
  ubuntu@disco:~$ sudo kill -9 1109

  5) Check if systemd service lists slapd as still active, even though it was 
terminated
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago
   Docs: man:systemd-sysv-generator(8)
    Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)

  6) Check if systemd has loaded both
  /run/systemd/generator.late/slapd.service &
  /usr/lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf

  $ systemctl cat slapd

  [Regression Potential]
  The regression potential for this fix should be very low, if we keep the new 
systemd unit file close to the one generated by systemd-sysv-generator(8). The 
only significant change would be the RemainAfterExit directive, and this should 
make the slapd service behave like a "normal" forking service. Nonetheless, 
we'll perform scripted test runs to make sure no regressions arise.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+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 1821343] Re: slapd process failure is not detected by systemd

2019-04-10 Thread Heitor Alves de Siqueira
** Patch added: "lp1821343-xenial.debdiff"
   
https://bugs.launchpad.net/debian/+source/openldap/+bug/1821343/+attachment/5254688/+files/lp1821343-xenial.debdiff

** Patch removed: "lp1821343-disco.debdiff"
   
https://bugs.launchpad.net/debian/+source/openldap/+bug/1821343/+attachment/5254240/+files/lp1821343-disco.debdiff

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

Title:
  slapd process failure is not detected by systemd

Status in openldap package in Ubuntu:
  Fix Released
Status in openldap source package in Xenial:
  Confirmed
Status in openldap source package in Bionic:
  Confirmed
Status in openldap source package in Cosmic:
  Confirmed
Status in openldap package in Debian:
  New

Bug description:
  [Impact]
  Systemd service reports slapd as active, even though it may have failed

  [Description]
  The slapd package for OpenLDAP is shipped with a SysV-style init script 
(/etc/init.d/slapd). Systemd automatically converts this to a systemd service 
by generating the unit file using the systemd-sysv-generator(8) utility. The 
generated unit file contains Type=forking and RemainAfterExit=yes directives.

  If the slapd daemon process exits due to some failure (e.g., it
  receives a SIGTERM or SIGKILL), the failure is not detected properly
  by systemd. The service is still reported as active even though the
  child (daemon) process has exited with a signal.

  We can easily fix this by including a proper systemd service file for
  slapd in the openldap package. Since the init.d script already does
  most of the necessary work (parsing configs, setting up PID files,
  etc.), we don't need anything complicated for the systemd unit file.
  Just making sure that RemainAfterExit is set to "no" makes the systemd
  service behave in the expected way.

  [Test Case]
  1) Deploy a disco container
  $ lxc launch images:ubuntu/disco disco

  2) Install slapd
  ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y

  3) Verify that slapd is running with the auto-generated service
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago
   Docs: man:systemd-sysv-generator(8)
    Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
  Tasks: 3 (limit: 4915)
     Memory: 712.6M
     CGroup: /system.slice/slapd.service
     └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u 
openldap -F /etc/ldap/slapd.d

  4) SIGKILL the slapd process (PID is displayed in systemctl status output)
  ubuntu@disco:~$ sudo kill -9 1109

  5) Check if systemd service lists slapd as still active, even though it was 
terminated
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago
   Docs: man:systemd-sysv-generator(8)
    Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)

  6) Check if systemd has loaded both
  /run/systemd/generator.late/slapd.service &
  /usr/lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf

  $ systemctl cat slapd

  [Regression Potential]
  The regression potential for this fix should be very low, if we keep the new 
systemd unit file close to the one generated by systemd-sysv-generator(8). The 
only significant change would be the RemainAfterExit directive, and this should 
make the slapd service behave like a "normal" forking service. Nonetheless, 
we'll perform scripted test runs to make sure no regressions arise.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+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 1821343] Re: slapd process failure is not detected by systemd

2019-04-09 Thread Heitor Alves de Siqueira
debdiff v2 with fixed author information

** Patch added: "v2-lp1821343-disco.debdiff"
   
https://bugs.launchpad.net/debian/+source/openldap/+bug/1821343/+attachment/5254440/+files/v2-lp1821343-disco.debdiff

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

Title:
  slapd process failure is not detected by systemd

Status in openldap package in Ubuntu:
  Confirmed
Status in openldap source package in Xenial:
  Confirmed
Status in openldap source package in Bionic:
  Confirmed
Status in openldap source package in Cosmic:
  Confirmed
Status in openldap package in Debian:
  New

Bug description:
  [Impact]
  Systemd service reports slapd as active, even though it may have failed

  [Description]
  The slapd package for OpenLDAP is shipped with a SysV-style init script 
(/etc/init.d/slapd). Systemd automatically converts this to a systemd service 
by generating the unit file using the systemd-sysv-generator(8) utility. The 
generated unit file contains Type=forking and RemainAfterExit=yes directives.

  If the slapd daemon process exits due to some failure (e.g., it
  receives a SIGTERM or SIGKILL), the failure is not detected properly
  by systemd. The service is still reported as active even though the
  child (daemon) process has exited with a signal.

  We can easily fix this by including a proper systemd service file for
  slapd in the openldap package. Since the init.d script already does
  most of the necessary work (parsing configs, setting up PID files,
  etc.), we don't need anything complicated for the systemd unit file.
  Just making sure that RemainAfterExit is set to "no" makes the systemd
  service behave in the expected way.

  [Test Case]
  1) Deploy a disco container
  $ lxc launch images:ubuntu/disco disco

  2) Install slapd
  ubuntu@disco:~$ sudo apt update && sudo apt install slapd -y

  3) Verify that slapd is running with the auto-generated service
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (running) since Fri 2019-03-22 11:51:22 UTC; 40min ago
   Docs: man:systemd-sysv-generator(8)
    Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)
  Tasks: 3 (limit: 4915)
     Memory: 712.6M
     CGroup: /system.slice/slapd.service
     └─1109 /usr/sbin/slapd -h ldap:/// ldapi:/// -g openldap -u 
openldap -F /etc/ldap/slapd.d

  4) SIGKILL the slapd process (PID is displayed in systemctl status output)
  ubuntu@disco:~$ sudo kill -9 1109

  5) Check if systemd service lists slapd as still active, even though it was 
terminated
  ubuntu@disco:~$ systemctl status slapd
  ● slapd.service - LSB: OpenLDAP standalone server (Lightweight Directory 
Access Protocol)
     Loaded: loaded (/etc/init.d/slapd; generated)
     Active: active (exited) since Fri 2019-03-22 11:51:22 UTC; 42min ago
   Docs: man:systemd-sysv-generator(8)
    Process: 1103 ExecStart=/etc/init.d/slapd start (code=exited, 
status=0/SUCCESS)

  6) Check if systemd has loaded both
  /run/systemd/generator.late/slapd.service &
  /usr/lib/systemd/system/slapd.service.d/slapd-remain-after-exit.conf

  $ systemctl cat slapd

  [Regression Potential]
  The regression potential for this fix should be very low, if we keep the new 
systemd unit file close to the one generated by systemd-sysv-generator(8). The 
only significant change would be the RemainAfterExit directive, and this should 
make the slapd service behave like a "normal" forking service. Nonetheless, 
we'll perform scripted test runs to make sure no regressions arise.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/1821343/+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