[Touch-packages] [Bug 1644996] Re: logrotate config uses syslog group

2020-06-01 Thread WGH
At least one cloud provider builds its Ubuntu 18.04 images without
rsyslog.

https://github.com/scaleway/image-ubuntu/issues/138

** Bug watch added: github.com/scaleway/image-ubuntu/issues #138
   https://github.com/scaleway/image-ubuntu/issues/138

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

Title:
  logrotate config uses syslog group

Status in logrotate package in Ubuntu:
  Fix Released
Status in logrotate source package in Bionic:
  New
Status in logrotate source package in Cosmic:
  New

Bug description:
  The default logrotate config uses the "syslog" group.

  > # use the syslog group by default, since this is the owning group
  > # of /var/log/syslog.
  > su root syslog

  This is not correct anymore since 16.04, because:

  1. "syslog" group doesn't exist on a stock Ubuntu 16.04 system, it only gets 
installed via rsyslog
  2. The owning group is actually "adm".

  This results in logrotate terminating with the following error during
  cron.daily run:

  
  run-parts -v /etc/cron.daily
  run-parts: executing /etc/cron.daily/logrotate
  error: /etc/logrotate.conf:7 unknown group 'syslog'

  And can be fixed by changing syslog to adm group.

  This is not present when rsyslog is installed, but only because that package 
creates the syslog group. This is a common bug in lighter environments, like 
Docker, where syslog-ng is a common choice instead of rsyslog, like in this 
issue: 
  https://github.com/phusion/baseimage-docker/issues/338

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/logrotate/+bug/1644996/+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 1874142] Re: lvm2-lvmlocking.service incorrectly uses nonexistent option --lock-opt autowait

2020-04-22 Thread WGH
https://www.redhat.com/archives/lvm-devel/2020-April/msg00017.html fixed
upstream, but still affects both Ubuntu 18.04 and 20.04
(/lib/systemd/system/lvm2-lvmlocking.service and
/lib/systemd/system/lvmlocks.service correspondingly)

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

Title:
  lvm2-lvmlocking.service incorrectly uses nonexistent option --lock-opt
  autowait

Status in lvm2 package in Ubuntu:
  New

Bug description:
  The lvm2-lvmlocking.service systemd unit installed by lvm2-lockd
  package has the following line:

  # start lockspaces and wait for them to finish starting
  ExecStart=@SBINDIR@/lvm vgchange --lock-start --lock-opt autowait

  This is unfortunately wrong: the autowait option was dropped in this
  commit: https://www.redhat.com/archives/lvm-
  devel/2015-July/msg00091.html, and attempting to specify it causes the
  opposite effect: no waiting is done at all.

  It should've said --lock-opt auto.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1874142/+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 1874142] [NEW] lvm2-lvmlocking.service incorrectly uses nonexistent option --lock-opt autowait

2020-04-21 Thread WGH
Public bug reported:

The lvm2-lvmlocking.service systemd unit installed by lvm2-lockd package
has the following line:

# start lockspaces and wait for them to finish starting
ExecStart=@SBINDIR@/lvm vgchange --lock-start --lock-opt autowait

This is unfortunately wrong: the autowait option was dropped in this
commit: https://www.redhat.com/archives/lvm-
devel/2015-July/msg00091.html, and attempting to specify it causes the
opposite effect: no waiting is done at all.

It should've said --lock-opt auto.

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

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

Title:
  lvm2-lvmlocking.service incorrectly uses nonexistent option --lock-opt
  autowait

Status in lvm2 package in Ubuntu:
  New

Bug description:
  The lvm2-lvmlocking.service systemd unit installed by lvm2-lockd
  package has the following line:

  # start lockspaces and wait for them to finish starting
  ExecStart=@SBINDIR@/lvm vgchange --lock-start --lock-opt autowait

  This is unfortunately wrong: the autowait option was dropped in this
  commit: https://www.redhat.com/archives/lvm-
  devel/2015-July/msg00091.html, and attempting to specify it causes the
  opposite effect: no waiting is done at all.

  It should've said --lock-opt auto.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lvm2/+bug/1874142/+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