Still seeing this in bionic 18.04.3 with the following kernel and procps
package.
ii procps 2:3.3.12-3ubuntu1.2
amd64/proc file system utilities
kernel 5.4.0-62-generic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded
Public bug reported:
When attempting to craft a command to query and/or restart all services
with name 'something-*-else', such as 'neutron-*-agent' to match
[neutron-l3-agent, neutron-openvswitch-agent, and neutron-dhcp-agent],
I've found that no services are returned from globs in the middle of
This affects bionic openstack cloud environments when os-*-hostname is
configured for keystone, and the keystone entry is deleted temporarily
from upstream dns, or the upstream dns fails providing no record for the
lookup of keystone.endpoint.domain.com.
We have to then flush all caches across the
Public bug reported:
The certificate /usr/share/ca-
certificates/mozilla/Go_Daddy_Class_2_CA.crt in package ca-certificates
is conflicting with /etc/ssl/certs/UbuntuOne-Go_Daddy_Class_2_CA.pem
from package python-ubuntu-sso-client.
This results in the postinst trigger for ca-certificates to remov
perhaps a proper fix is for ubuntu-sso-client to release a new python-
ubuntu-sso-client package in bionic that doesn't include this UbuntuOne-
Go_Daddy_Class_2_CA.pem now that ca-certificates package has the CA.
However, I'd still like to see duplicate certs not causing ca-
certificates.crt to be
re: init-system-helpers, I noticed the oddity of the init script on a
systemd system as well and found that there's a systemd hack in /lib/lsb
/init-functions.d/40-systemd that allows for multi-startup
compatibility. I believe invoke-rc.d should check systemd
"enabled/disabled" state instead of ju
>From a high level, it appears that invoke-rc.d script used for
compatibility falls back to checking for /etc/rcX.d symlinks for a
"policy" check if there is no $POLICYHELPER installed. Perhaps the
actual shortcoming is not having the policy-rc.d installed to prefer
systemd over init.d on Xenial.
Can we get this backported to trusty?
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to dbus in Ubuntu.
https://bugs.launchpad.net/bugs/1591411
Title:
systemd-logind must be restarted every ~1000 SSH logins to prevent a
~25
** Tags added: canonical-bootstack canonical-is
--
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/1591411
Title:
systemd-logind must be restarted every ~1000 SSH logins to pr
Trusty versions of packages affected (I see there is a systemd update
229-4ubuntu19. Does this include the backported fixes from v230/v231
mentioned in comment #4?):
ii dbus 1.10.6-1ubuntu3.1
amd64simple interprocess messaging system
Relevant package revisions for comment #50:
bcache-tools 1.0.8-2build1
snapd2.45.1+18.04.2
systemd 237-3ubuntu10.41
udev 237-3ubuntu10.41
and snaps:
Name Version
I'm having similar issues to this bug and those described by Dmitrii in
https://bugs.launchpad.net/charm-ceph-osd/+bug/1883585 specifically
comment #2 and the last comment.
It appears that if I run 'udevadm trigger --subsystem-match=block', I
get my by-dname devices for bcaches, but if I run udeva
Adding Bootstack to watch this bug, as we are taking ownership of charm-
iscsi-connector which would be ideal to test within lxd confinement, but
requires VM or metal for functional tests.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is sub
13 matches
Mail list logo
