[Touch-packages] [Bug 2055397] Re: netplan/systemd-networkd: route metric not applied to routes to the local subnet
** Description changed: + [SRU TEMPLATE] + + [DESCRIPTION] + Cloud-init introduced a feature to configure policy routing on AWS EC2 instances with multiple NICs in https://github.com/canonical/cloud-init/commit/0ca5f31043e2d98eab31a43d9dde9bdaef1435cb targeting v24.1. Cloud-init generates the following netplan config: ``` $ cat /etc/netplan/50-cloud-init.yaml network: - ethernets: - ens5: - dhcp4: true - dhcp4-overrides: - route-metric: 100 - dhcp6: true - dhcp6-overrides: *id001 - match: - macaddress: 0a:c8:ab:90:c2:fb - set-name: ens5 - ens6: - dhcp4: true - dhcp4-overrides: - route-metric: 200 - use-routes: true - dhcp6: false - match: - macaddress: 0a:c6:55:a1:dc:3b - routes: - - table: 101 - to: 0.0.0.0/0 - via: 192.168.0.1 - - table: 101 - to: 192.168.0.0/20 - routing-policy: - - from: 192.168.10.212 - table: 101 - set-name: ens6 - version: 2 + ethernets: + ens5: + dhcp4: true + dhcp4-overrides: + route-metric: 100 + dhcp6: true + dhcp6-overrides: *id001 + match: + macaddress: 0a:c8:ab:90:c2:fb + set-name: ens5 + ens6: + dhcp4: true + dhcp4-overrides: + route-metric: 200 + use-routes: true + dhcp6: false + match: + macaddress: 0a:c6:55:a1:dc:3b + routes: + - table: 101 + to: 0.0.0.0/0 + via: 192.168.0.1 + - table: 101 + to: 192.168.0.0/20 + routing-policy: + - from: 192.168.10.212 + table: 101 + set-name: ens6 + version: 2 ``` Which renders the following systemd-networkd config files: ``` $ cat 10-netplan-ens5.link [Match] MACAddress=0a:c8:ab:90:c2:fb [Link] Name=ens5 WakeOnLan=off - $ cat 10-netplan-ens5.network [Match] MACAddress=0a:c8:ab:90:c2:fb Name=ens5 [Network] DHCP=yes LinkLocalAddressing=ipv6 [DHCP] RouteMetric=100 UseMTU=true - $ cat 10-netplan-ens6.link [Match] MACAddress=0a:c6:55:a1:dc:3b [Link] Name=ens6 WakeOnLan=off - $ cat 10-netplan-ens6.network [Match] MACAddress=0a:c6:55:a1:dc:3b Name=ens6 [Network] DHCP=ipv4 LinkLocalAddressing=ipv6 [Route] Destination=0.0.0.0/0 Gateway=192.168.0.1 Table=101 [Route] Destination=192.168.0.0/20 Scope=link Table=101 [RoutingPolicyRule] From=192.168.10.212 Table=101 [DHCP] RouteMetric=200 UseMTU=true ``` Which configures the instance with the following state in Ubuntu Focal: ``` $ ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 - link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 - inet 127.0.0.1/8 scope host lo -valid_lft forever preferred_lft forever - inet6 ::1/128 scope host -valid_lft forever preferred_lft forever + link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 + inet 127.0.0.1/8 scope host lo + valid_lft forever preferred_lft forever + inet6 ::1/128 scope host + valid_lft forever preferred_lft forever 2: ens5: mtu 9001 qdisc mq state UP group default qlen 1000 - link/ether 0a:c8:ab:90:c2:fb brd ff:ff:ff:ff:ff:ff - inet 192.168.12.94/20 brd 192.168.15.255 scope global dynamic ens5 -valid_lft 2087sec preferred_lft 2087sec - inet6 2a05:d012:ea0:c500:6d12:2b20:5fef:a502/128 scope global dynamic noprefixroute -valid_lft 440sec preferred_lft 130sec - inet6 fe80::8c8:abff:fe90:c2fb/64 scope link -valid_lft forever preferred_lft forever + link/ether 0a:c8:ab:90:c2:fb brd ff:ff:ff:ff:ff:ff + inet 192.168.12.94/20 brd 192.168.15.255 scope global dynamic ens5 + valid_lft 2087sec preferred_lft 2087sec + inet6 2a05:d012:ea0:c500:6d12:2b20:5fef:a502/128 scope global dynamic noprefixroute + valid_lft 440sec preferred_lft 130sec + inet6 fe80::8c8:abff:fe90:c2fb/64 scope link + valid_lft forever preferred_lft forever 3: ens6: mtu 9001 qdisc mq state UP group default qlen 1000 - link/ether 0a:c6:55:a1:dc:3b brd ff:ff:ff:ff:ff:ff - inet 192.168.10.212/20 brd 192.168.15.255 scope global dynamic ens6 -valid_lft 2083sec preferred_lft 2083sec - inet6 fe80::8c6:55ff:fea1:dc3b/64 scope link -valid_lft forever preferred_lft forever - + link/ether 0a:c6:55:a1:dc:3b brd ff:ff:ff:ff:ff:ff + inet 192.168.10.212/20 brd 192.168.15.255 scope global dynamic ens6 +
[Touch-packages] [Bug 1761341] Re: lsb_release crashed with ValueError in (): could not convert string to float: '6.06 LTS'
@mwhudson yes, I am working on the debdiffs and once ready I'll attach
them here.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lsb in Ubuntu.
https://bugs.launchpad.net/bugs/1761341
Title:
lsb_release crashed with ValueError in (): could not convert
string to float: '6.06 LTS'
Status in lsb package in Ubuntu:
Fix Released
Status in lsb source package in Bionic:
Confirmed
Status in lsb source package in Focal:
Confirmed
Status in lsb source package in Jammy:
Confirmed
Bug description:
[Description]
In some cases lsb_release script can crash with the following trace :
Traceback (most recent call last):
File "/usr/bin/lsb_release", line 95, in
main()
File "/usr/bin/lsb_release", line 59, in main
distinfo = lsb_release.get_distro_information()
File "/usr/lib/python3/dist-packages/lsb_release.py", line 356, in
get_distro_information
distinfo = guess_debian_release()
File "/usr/lib/python3/dist-packages/lsb_release.py", line 246, in
guess_debian_release
get_distro_info(distinfo['ID'])
File "/usr/lib/python3/dist-packages/lsb_release.py", line 48, in
get_distro_info
RELEASES_ORDER.sort(key=lambda n: float(n[0]))
File "/usr/lib/python3/dist-packages/lsb_release.py", line 48, in
RELEASES_ORDER.sort(key=lambda n: float(n[0]))
ValueError: could not convert string to float: '6.06 LTS
The root cause of this is that function get_distro_info() while parsing
the '/usr/share/distro-info/ubuntu.csv' and expects to find a float at the
beginning of each line, instead it find a string ("6.06 LTS").
There is a fix for this bug upstream:
https://salsa.debian.org/debian/lsb/-/commit/4b36f9d31c00233ea20415542633729ab3799e61
and is already in kinetic.
[Test Case]
The easier way to reproduce this bug is to hack
/usr/share/pyshared/lsb_release.py file
change the get_distro_info definition from
def get_distro_info(origin='Debian'):
to
def get_distro_info(origin='Ubuntu'):
and run
$ lsb_release
Traceback (most recent call last):
File "/usr/bin/lsb_release", line 25, in
import lsb_release
File "/usr/lib/python3/dist-packages/lsb_release.py", line 58, in
get_distro_info()
File "/usr/lib/python3/dist-packages/lsb_release.py", line 48, in
get_distro_info
RELEASES_ORDER.sort(key=lambda n: float(n[0]))
File "/usr/lib/python3/dist-packages/lsb_release.py", line 48, in
RELEASES_ORDER.sort(key=lambda n: float(n[0]))
ValueError: could not convert string to float: '6.06 LTS'
A detailed analysis on how this bug can happen in a real life scenario
can be found in comment #3.
[Regression Potential]
The fix changes the way get_distro_info function parses the csv file and
instead of expecting
a float at the beginning of the line, it now expects a string and isolates
the numerical part.
The regression potential is small and would affect the behavior of
lsb_release executable.
[Other]
Debian bug : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980566
Fix :
https://salsa.debian.org/debian/lsb/-/commit/4b36f9d31c00233ea20415542633729ab3799e61
Affected releases : Jammy, Focal, Bionic
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1761341/+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 1761341] Re: lsb_release crashed with ValueError in (): could not convert string to float: '6.06 LTS'
Here is a more detailed analysis of how the bug can occur (analysis
based on the focal sources).
lsb_release.py crashes in get_distro_info() function, while parsing
'/usr/share/distro-info/ubuntu.csv' file on the 4th line because of the
'6.06 LTS'. get_distro_info() expects a float (6.06) but finds a string (6.06
LTS).
How do we end up in this code path:
For the crash to occur, get_distro_info should be called with arg 'Ubuntu',
get_distro_info('Ubuntu').
If we grep lsb source package, we can see that get_distro_info is called only in
two places.
The first in lsb_release.py:58 with no arguments and the second in
lsb_release.py:288
in function
guess_debian_release():
...get_distro_info(distinfo['ID'])
The function guess_debian_release() is only called from
get_distro_information(), lsb_release.py:393.
If we look into this function, it initially calls get_os_release(), which is
reading the
'/usr/lib/os-release' file and returns a dictionary with the file contents.
After this, the only way to call guess_debian_release() is to pass through the
guard
on line 397:
```if key not in lsbinfo:```
For this condition to be true, the /usr/lib/os-release should be empty or
contain unexpected keys.
** Description changed:
- satana@satana:~$ lsb_release
- LSB Version:
core-9.20170808ubuntu1-noarch:printing-9.20170808ubuntu1-noarch:security-9.20170808ubuntu1-noarch
- satana@satana:~$ snap list
- Name VersionRev Tracking Developer Notes
- core 16-2.32.1 4327 stablecanonical core
- satana@satana:~$
+ [Description]
- ProblemType: Crash
- DistroRelease: Ubuntu 18.04
- Package: lsb-release 9.20170808ubuntu1 [modified:
usr/share/pyshared/lsb_release.py]
- ProcVersionSignature: Ubuntu 4.15.0-14.15-generic 4.15.15
- Uname: Linux 4.15.0-14-generic x86_64
- ApportVersion: 2.20.9-0ubuntu2
- Architecture: amd64
- Date: Wed Mar 28 15:36:11 2018
- ExecutablePath: /usr/bin/lsb_release
- InstallationDate: Installed on 2016-09-15 (566 days ago)
- InstallationMedia: Ubuntu 14.04.1 LTS "Trusty Tahr" - Release amd64
(20140722.2)
- InterpreterPath: /usr/bin/python3.6
- PackageArchitecture: all
- ProcCmdline: /usr/bin/python3 -Es /usr/bin/lsb_release -i -s
- Python3Details: /usr/bin/python3.6, Python 3.6.5, python3-minimal, 3.6.5-2
- PythonArgs: ['/usr/bin/lsb_release', '-i', '-s']
- PythonDetails: /usr/bin/python2.7, Python 2.7.14+, python-minimal, 2.7.14-4
- SourcePackage: lsb
- Title: lsb_release crashed with ValueError in (): could not convert
string to float: '6.06 LTS'
- UpgradeStatus: No upgrade log present (probably fresh install)
- UserGroups:
+ In some cases lsb_release script can crash with the following trace :
+
+ Traceback (most recent call last):
+ File "/usr/bin/lsb_release", line 95, in
+ main()
+ File "/usr/bin/lsb_release", line 59, in main
+ distinfo = lsb_release.get_distro_information()
+ File "/usr/lib/python3/dist-packages/lsb_release.py", line 356, in
+ get_distro_information
+ distinfo = guess_debian_release()
+ File "/usr/lib/python3/dist-packages/lsb_release.py", line 246, in
+ guess_debian_release
+ get_distro_info(distinfo['ID'])
+ File "/usr/lib/python3/dist-packages/lsb_release.py", line 48, in
+ get_distro_info
+ RELEASES_ORDER.sort(key=lambda n: float(n[0]))
+ File "/usr/lib/python3/dist-packages/lsb_release.py", line 48, in
+ RELEASES_ORDER.sort(key=lambda n: float(n[0]))
+ ValueError: could not convert string to float: '6.06 LTS
+
+
+ The root cause of this is that function get_distro_info() while parsing
+ the '/usr/share/distro-info/ubuntu.csv' and expects to find a float at the
+ beginning of each line, instead it find a string ("6.06 LTS").
+
+ There is a fix for this bug upstream:
+
https://salsa.debian.org/debian/lsb/-/commit/4b36f9d31c00233ea20415542633729ab3799e61
+ and is already in kinetic.
+
+ [Test Case]
+
+ The easier way to reproduce this bug is to hack
/usr/share/pyshared/lsb_release.py file
+ change the get_distro_info definition from
+ def get_distro_info(origin='Debian'):
+ to
+ def get_distro_info(origin='Ubuntu'):
+ and run
+ $ lsb_release
+ Traceback (most recent call last):
+ File "/usr/bin/lsb_release", line 25, in
+ import lsb_release
+ File "/usr/lib/python3/dist-packages/lsb_release.py", line 58, in
+ get_distro_info()
+ File "/usr/lib/python3/dist-packages/lsb_release.py", line 48, in
get_distro_info
+ RELEASES_ORDER.sort(key=lambda n: float(n[0]))
+ File "/usr/lib/python3/dist-packages/lsb_release.py", line 48, in
+ RELEASES_ORDER.sort(key=lambda n: float(n[0]))
+ ValueError: could not convert string to float: '6.06 LTS'
+
+
+ [Regression Potential]
+
+ The fix changes the way get_distro_info function parses the csv file and
instead of expecting
+ a float at the beginning of the line, it now expects a string and isolates
the numerical part.
+
+ The regression potential is small and would affect the behavior of
+ lsb_release executable.
+
+
+ [Other]
+
+ Debian bug :
[Touch-packages] [Bug 1987642] [NEW] Chile is delaying the DST by one week for 2022
Public bug reported: Chile is delaying the start of Daylight Saving Time (DST) by one week this year [1],[2]. DST timezone in Chile will start on midnight of September 11th; and will end on April 1st, 2023. Debian's 2022c-1 and 2022b-1 versions of tzdata contain the fix for this. Upstream commit : https://github.com/eggert/tz/commit/711b46f8fc4e8a3d5caf7d4820562d6cdfe9d769 We need to fix this in all or releases back to Xenial. [1] https://www.interior.gob.cl/noticias/2022/08/09/comunicado-el-proximo-sabado-10-de-septiembre-los-relojes-se-deben-adelantar-una-hora/ [2] https://www.timeanddate.com/news/time/chile-dst-delay-2022.html#:~:text=Chile%20is%20delaying%20the%20start,financial%20district%20in%20Chile%27s%20capital. ** Affects: tzdata (Ubuntu) Importance: High Status: New ** Affects: tzdata (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: tzdata (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: tzdata (Ubuntu Focal) Importance: Undecided Status: New ** Affects: tzdata (Ubuntu Jammy) Importance: Undecided Status: New ** Affects: tzdata (Ubuntu Kinetic) Importance: High Status: New ** Changed in: tzdata (Ubuntu) Importance: Undecided => High ** Also affects: tzdata (Ubuntu Kinetic) Importance: High Status: New ** Also affects: tzdata (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: tzdata (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: tzdata (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: tzdata (Ubuntu Jammy) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tzdata in Ubuntu. https://bugs.launchpad.net/bugs/1987642 Title: Chile is delaying the DST by one week for 2022 Status in tzdata package in Ubuntu: New Status in tzdata source package in Xenial: New Status in tzdata source package in Bionic: New Status in tzdata source package in Focal: New Status in tzdata source package in Jammy: New Status in tzdata source package in Kinetic: New Bug description: Chile is delaying the start of Daylight Saving Time (DST) by one week this year [1],[2]. DST timezone in Chile will start on midnight of September 11th; and will end on April 1st, 2023. Debian's 2022c-1 and 2022b-1 versions of tzdata contain the fix for this. Upstream commit : https://github.com/eggert/tz/commit/711b46f8fc4e8a3d5caf7d4820562d6cdfe9d769 We need to fix this in all or releases back to Xenial. [1] https://www.interior.gob.cl/noticias/2022/08/09/comunicado-el-proximo-sabado-10-de-septiembre-los-relojes-se-deben-adelantar-una-hora/ [2] https://www.timeanddate.com/news/time/chile-dst-delay-2022.html#:~:text=Chile%20is%20delaying%20the%20start,financial%20district%20in%20Chile%27s%20capital. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1987642/+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 1917780] Re: initramfs-tools does not include fsck binaries in the initrd if all mount pass are 0
#VERIFICATION BIONIC On a bionic machine that has PASSNO set to 0 for all entries, installed initramfs-tools from -proposed. # lsinitramfs /boot/initrd.img-5.9.0-rc5+ | grep fsck sbin/fsck.ext4 sbin/fsck sbin/e2fsck fsck utilities are included. ** Tags removed: verification-needed verification-needed-bionic verification-needed-focal verification-needed-groovy ** Tags added: verification-done verification-done-bionic verification-done-focal verification-done-groovy -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1917780 Title: initramfs-tools does not include fsck binaries in the initrd if all mount pass are 0 Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Bionic: Fix Committed Status in initramfs-tools source package in Focal: Fix Committed Status in initramfs-tools source package in Groovy: Fix Committed Bug description: [Impact] * initramfs-tools does not include fsck in initrd if MNT_PASS equals zero in the fstab entries. This has lead to the following situation : when dropping to initramfs shell during boot due to fs errors, we are not able to run fsck manually because it is not included in initrd. fsck should be included regardless of the MNT_PASS value. [Test Plan] * change /etc/fstab with PASSNO set to 0 for all entries * update-initramfs -u * lsinitramfs that is just generated * observe that it includes fsck utilities for the filesystems in /etc/fstab. I.e. fsck.ext4 e2fsck must exist [Where problems could occur] * The initramfs size will increase slightly upon upgrade, for the same initramfs-tools default options & kernel. However, one can control and remove fsck binaries (or include more of them) by setting FSTYPE variable in the initramfs settings. [scope] this is required for b/f/g this is fixed already in h and i [other info] debian MR is open: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/49 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1917780/+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 1917780] Re: initramfs-tools does not include fsck binaries in the initrd if all mount pass are 0
#VERIFICATION GROOVY On a groovy machine that has PASSNO set to 0 for all entries, installed initramfs-tools from -proposed. # lsinitramfs /boot/initrd.img-5.8.0-50-generic | grep fsck usr/sbin/e2fsck usr/sbin/fsck usr/sbin/fsck.ext4 fsck utilities are included. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1917780 Title: initramfs-tools does not include fsck binaries in the initrd if all mount pass are 0 Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Bionic: Fix Committed Status in initramfs-tools source package in Focal: Fix Committed Status in initramfs-tools source package in Groovy: Fix Committed Bug description: [Impact] * initramfs-tools does not include fsck in initrd if MNT_PASS equals zero in the fstab entries. This has lead to the following situation : when dropping to initramfs shell during boot due to fs errors, we are not able to run fsck manually because it is not included in initrd. fsck should be included regardless of the MNT_PASS value. [Test Plan] * change /etc/fstab with PASSNO set to 0 for all entries * update-initramfs -u * lsinitramfs that is just generated * observe that it includes fsck utilities for the filesystems in /etc/fstab. I.e. fsck.ext4 e2fsck must exist [Where problems could occur] * The initramfs size will increase slightly upon upgrade, for the same initramfs-tools default options & kernel. However, one can control and remove fsck binaries (or include more of them) by setting FSTYPE variable in the initramfs settings. [scope] this is required for b/f/g this is fixed already in h and i [other info] debian MR is open: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/49 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1917780/+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 1917780] Re: initramfs-tools does not include fsck binaries in the initrd if all mount pass are 0
#VERIFICATION FOCAL On a focal machine that has PASSNO set to 0 for all entries, installed initramfs-tools from -proposed. # lsinitramfs /boot/initrd.img-5.4.0-72-generic | grep fsck usr/sbin/e2fsck usr/sbin/fsck usr/sbin/fsck.ext4 fsck utilities are included. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1917780 Title: initramfs-tools does not include fsck binaries in the initrd if all mount pass are 0 Status in initramfs-tools package in Ubuntu: Fix Released Status in initramfs-tools source package in Bionic: Fix Committed Status in initramfs-tools source package in Focal: Fix Committed Status in initramfs-tools source package in Groovy: Fix Committed Bug description: [Impact] * initramfs-tools does not include fsck in initrd if MNT_PASS equals zero in the fstab entries. This has lead to the following situation : when dropping to initramfs shell during boot due to fs errors, we are not able to run fsck manually because it is not included in initrd. fsck should be included regardless of the MNT_PASS value. [Test Plan] * change /etc/fstab with PASSNO set to 0 for all entries * update-initramfs -u * lsinitramfs that is just generated * observe that it includes fsck utilities for the filesystems in /etc/fstab. I.e. fsck.ext4 e2fsck must exist [Where problems could occur] * The initramfs size will increase slightly upon upgrade, for the same initramfs-tools default options & kernel. However, one can control and remove fsck binaries (or include more of them) by setting FSTYPE variable in the initramfs settings. [scope] this is required for b/f/g this is fixed already in h and i [other info] debian MR is open: https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/49 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1917780/+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 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
Further verification that shows the non-zero return value of shutdown command, when it fails to schedule a reboot and takes no action. For Bionic : # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1 -r "REBOOT!" Failed to set wall message, ignoring: Refusing activation, D-Bus is shutting down. Failed to call ScheduleShutdown in logind, no action will be taken: Refusing activation, D-Bus is shutting down. root@bionic:~# echo $? 1 For Focal : # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1 -r "REBOOT!" root@focal:/home/jo# shutdown +1 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, no action will be taken: Connection timed out root@focal:/home/jo# echo $? 1 For Groovy : # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, no action will be taken: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) root@groovy:/home/jo# echo $? 1 -- 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/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Groovy: Fix Committed Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST PLAN] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. After this patch is applied the shutdown command does not reboot immediately if it fails to schedule the shutdown. Instead it does nothing and returns a non zero return code that can be checked by calling scripts or users. [WHERE PROBLEM COULD OCCUR] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it, so the largest regression potential is any existing users (human or programmatic) that are requesting a scheduled shutdown but not checking the return value for error. Any other regression would likely result in the system incorrectly not rebooted, or incorrectly scheduled for reboot. [OTHER] This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+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 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Description changed: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST PLAN] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. + After this patch is applied the shutdown command does not reboot immediately if it fails to schedule the shutdown. Instead it does nothing + and returns a non zero return code that can be checked by calling scripts or users. + [WHERE PROBLEM COULD OCCUR] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it, so the largest regression potential is any existing users (human or programmatic) that are requesting a scheduled shutdown but not checking the return value for error. Any other regression would likely result in the system incorrectly not rebooted, or incorrectly scheduled for reboot. [OTHER] This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 -- 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/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Groovy: Fix Committed Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST PLAN] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. After this patch is applied the shutdown command does not reboot immediately if it fails to schedule the shutdown. Instead it does nothing and returns a non zero return code that can be checked by calling scripts or users. [WHERE PROBLEM COULD OCCUR] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes
[Touch-packages] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
# VERIFICATION GROOVY Installed systemd from -proposed : # dpkg -l | grep systemd ii libnss-resolve:amd64 246.6-1ubuntu1.2 amd64nss module to resolve names via systemd-resolved ii libnss-systemd:amd64 246.6-1ubuntu1.2 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 246.6-1ubuntu1.2 amd64system and service manager - PAM module ii libsystemd-dev:amd64 246.6-1ubuntu1.2 amd64systemd utility library - development files ii libsystemd0:amd64 246.6-1ubuntu1.2 amd64systemd utility library ii systemd246.6-1ubuntu1.2 amd64system and service manager ii systemd-container 246.6-1ubuntu1.2 amd64systemd container/nspawn tools ii systemd-journal-remote 246.6-1ubuntu1.2 amd64tools for sending and receiving remote journal logs ii systemd-sysv 246.6-1ubuntu1.2 amd64system and service manager - SysV links ii systemd-tests 246.6-1ubuntu1.2 amd64tests for systemd ii systemd-timesyncd 246.6-1ubuntu1.2 amd64minimalistic service to synchronize local time with NTP servers Following test plan from description # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1 -r "REBOOT!" Failed to set wall message, ignoring: Connection timed out Failed to call ScheduleShutdown in logind, no action will be taken: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Machine does not reboot as expected. ** Tags removed: verification-needed verification-needed-groovy ** Tags added: verification-done verification-done-groovy -- 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/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Groovy: Fix Committed Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST PLAN] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [WHERE PROBLEM COULD OCCUR] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it, so the largest regression potential is any existing users (human or programmatic) that are requesting a scheduled shutdown but not checking the return value for error. Any other regression would likely result in the system incorrectly not rebooted, or incorrectly scheduled for reboot. [OTHER] This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To
[Touch-packages] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
# VERIFICATION FOCAL Installed systemd from -proposed : # dpkg -l | grep systemd ii libnss-resolve:amd64 245.4-4ubuntu3.5 amd64nss module to resolve names via systemd-resolved ii libnss-systemd:amd64 245.4-4ubuntu3.5 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 245.4-4ubuntu3.5 amd64system and service manager - PAM module ii libsystemd-dev:amd64 245.4-4ubuntu3.5 amd64systemd utility library - development files ii libsystemd0:amd64 245.4-4ubuntu3.5 amd64systemd utility library ii networkd-dispatcher2.0.1-1 all Dispatcher service for systemd-networkd connection status changes ii systemd245.4-4ubuntu3.5 amd64system and service manager ii systemd-container 245.4-4ubuntu3.5 amd64systemd container/nspawn tools ii systemd-journal-remote 245.4-4ubuntu3.5 amd64tools for sending and receiving remote journal logs ii systemd-sysv 245.4-4ubuntu3.5 amd64system and service manager - SysV links ii systemd-tests 245.4-4ubuntu3.5 amd64tests for systemd ii systemd-timesyncd 245.4-4ubuntu3.5 amd64minimalistic service to synchronize local time with NTP servers Following test plan from description # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1 -r "REBOOT!" Failed to set wall message, ignoring: Connection timed out Failed to call ScheduleShutdown in logind, no action will be taken: Connection timed out Machine does not reboot as expected. ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- 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/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Groovy: Fix Committed Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST PLAN] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [WHERE PROBLEM COULD OCCUR] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it, so the largest regression potential is any existing users (human or programmatic) that are requesting a scheduled shutdown but not checking the return value for error. Any other regression would likely result in the system incorrectly not rebooted, or incorrectly scheduled for reboot. [OTHER] This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about
[Touch-packages] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
# VERIFICATION BIONIC Installed systemd from -proposed : # dpkg -l | grep systemd ii libnss-resolve:amd64 237-3ubuntu10.45 amd64nss module to resolve names via systemd-resolved ii libnss-systemd:amd64 237-3ubuntu10.45 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 237-3ubuntu10.45 amd64system and service manager - PAM module ii libsystemd-dev:amd64 237-3ubuntu10.45 amd64systemd utility library - development files ii libsystemd0:amd64 237-3ubuntu10.45 amd64systemd utility library ii networkd-dispatcher1.7-0ubuntu3.3 all Dispatcher service for systemd-networkd connection status changes ii python3-systemd234-1build1 amd64Python 3 bindings for systemd ii systemd237-3ubuntu10.45 amd64system and service manager ii systemd-container 237-3ubuntu10.45 amd64systemd container/nspawn tools ii systemd-journal-remote 237-3ubuntu10.45 amd64tools for sending and receiving remote journal logs ii systemd-sysv 237-3ubuntu10.45 amd64system and service manager - SysV links ii systemd-tests 237-3ubuntu10.45 amd64tests for systemd Following test plan from description # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1 -r "REBOOT!" Failed to set wall message, ignoring: Refusing activation, D-Bus is shutting down. Failed to call ScheduleShutdown in logind, no action will be taken: Refusing activation, D-Bus is shutting down. Machine does not reboot as expected. ** 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/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Groovy: Fix Committed Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST PLAN] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [WHERE PROBLEM COULD OCCUR] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it, so the largest regression potential is any existing users (human or programmatic) that are requesting a scheduled shutdown but not checking the return value for error. Any other regression would likely result in the system incorrectly not rebooted, or incorrectly scheduled for reboot. [OTHER] This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235
[Touch-packages] [Bug 1917780] [NEW] initramfs-tools does not include fsck in initrd if mount pass is 0
Public bug reported: initramfs-tools does not include fsck in initrd if MNT_PASS equals zero in the fstab entries. This has lead to the following situation : when dropping to initramfs shell during boot due to fs errors, we are not able to run fsck manually because it is not included in initrd. fsck should be included regardless of the MNT_PASS value. ** Affects: initramfs-tools (Ubuntu) Importance: Medium Status: Confirmed ** Changed in: initramfs-tools (Ubuntu) Status: New => Confirmed ** Changed in: initramfs-tools (Ubuntu) Importance: Undecided => Medium -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1917780 Title: initramfs-tools does not include fsck in initrd if mount pass is 0 Status in initramfs-tools package in Ubuntu: Confirmed Bug description: initramfs-tools does not include fsck in initrd if MNT_PASS equals zero in the fstab entries. This has lead to the following situation : when dropping to initramfs shell during boot due to fs errors, we are not able to run fsck manually because it is not included in initrd. fsck should be included regardless of the MNT_PASS value. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1917780/+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 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Tags removed: sts-sponsors-ddstreet ** Description changed: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. + [SCOPE] + + This is already in H, need backporting to B,G,F. + + Ubuntu-hirsute commits : + + https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/? + h=ubuntu-hirsute=ce31df6711a8e112cff929ed3bbdcd194f876270 + + https://git.launchpad.net/~ubuntu-core- + dev/ubuntu/+source/systemd/commit/?h=ubuntu- + hirsute=ec1130fece7ca66273773119775e51045a74122c + + Debian commits : + + https://salsa.debian.org/systemd- + team/systemd/-/commit/ce31df6711a8e112cff929ed3bbdcd194f876270 + + https://salsa.debian.org/systemd- + team/systemd/-/commit/ec1130fece7ca66273773119775e51045a74122c + [OTHER] - - This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 ** Description changed: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [SCOPE] This is already in H, need backporting to B,G,F. Ubuntu-hirsute commits : - https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/? - h=ubuntu-hirsute=ce31df6711a8e112cff929ed3bbdcd194f876270 +
[Touch-packages] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
Debdiff for Focal. ** Patch added: "lp1911187_focal.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+attachment/5466203/+files/lp1911187_focal.debdiff ** Changed in: systemd (Ubuntu Bionic) Status: New => Confirmed ** Changed in: systemd (Ubuntu Focal) Status: New => Confirmed ** Changed in: systemd (Ubuntu Groovy) Status: New => Confirmed ** Tags added: sts-sponsors -- 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/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Groovy: Confirmed Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [OTHER] This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+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 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
Debdiff for Groovy. ** Patch added: "lp1911187_groovy.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+attachment/5466201/+files/lp1911187_groovy.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/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Groovy: Confirmed Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [OTHER] This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+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 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
Debdiff for Bionic. ** Patch added: "lp1911187_bionic.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+attachment/5466200/+files/lp1911187_bionic.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/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Groovy: Confirmed Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [OTHER] This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+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 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
Debdiff for Focal. ** Patch added: "lp1911187_focal.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+attachment/5466202/+files/lp1911187_focal.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/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Groovy: Confirmed Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [OTHER] This is now fixed in H, currently affects B,G,F. Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+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 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
This is addressed in Debian and has been downstreamed to Hirsute. The following debdiffs are to SRU it for B,G,F. ** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Groovy) Importance: Undecided => Medium ** Description changed: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. - Originally, if logind is not available (call to logind bus fails + Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [OTHER] + This is now fixed in H, currently affects B,G,F. + Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 -- 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/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Bionic: Confirmed Status in systemd source package in Focal: Confirmed Status in systemd source package in Groovy: Confirmed Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour
[Touch-packages] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Description changed: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] - The patch has minimal regression potential since it just takes no action - ( instead of shutting down ) when bus_call_method fails. + This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. + Originally, if logind is not available (call to logind bus fails + https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) + it proceeds with immediate shutdown. + This patch changes this behaviour and instead of shutting down it does nothing. + The actual regression potential is a user asking for a reboot and not getting it. + Other than that the changes in the code are very small and simple and unlikely to break anything. [OTHER] - Debian bug reports : + Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 -- 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/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Confirmed Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] This patch changes the behaviour of scheduled reboot in case logind or dbus has failed. Originally, if logind is not available (call to logind bus fails https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L319) it proceeds with immediate shutdown. This patch changes this behaviour and instead of shutting down it does nothing. The actual regression potential is a user asking for a reboot and not getting it. Other than that the changes in the code are very small and simple and unlikely to break anything. [OTHER] Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to :
[Touch-packages] [Bug 1911187] Re: scheduled reboot reboots immediately if dbus or logind is not available
** Description changed: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. - There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and + There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. - [REGRESSION POTENTIAL] The patch has minimal regression potential since it just takes no action ( instead of shutting down ) when bus_call_method fails. [OTHER] + Debian bug reports : + https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 + https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 + Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 -- 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/1911187 Title: scheduled reboot reboots immediately if dbus or logind is not available Status in systemd package in Ubuntu: Confirmed Bug description: [IMPACT] When, for whatever reason, logind or dbus is not available scheduled reboot reboots the machine immediately. From the sources it seems that this is intended : https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318 However, I report this as a bug since this is against the logic of a scheduled reboot; if someone schedules a reboot they want the system to reboot at the specified time not immediately. There has been a discussion upstream ( https://github.com/systemd/systemd/issues/17575 ) and a PR ( https://github.com/systemd/systemd/pull/18010 ). Upstream community is not willing to accept the patch but debian is. I open this bug to to pull the patch into Ubuntu once it lands in debian. [TEST CASE] The simpler reproducer is to disable dbus to imitate the real world case. # systemctl stop dbus.service # systemctl stop dbus.socket # shutdown +1140 -r "REBOOT!" Failed to set wall message, ignoring: Failed to activate service 'org.freedesktop.login1': timed out (service_start_timeout=25000ms) Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown: Connection timed out Connection to groovy closed by remote host. Connection to groovy closed. [REGRESSION POTENTIAL] The patch has minimal regression potential since it just takes no action ( instead of shutting down ) when bus_call_method fails. [OTHER] Debian bug reports : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931235 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960042 Upstream issue : https://github.com/systemd/systemd/issues/17575 PR : https://github.com/systemd/systemd/pull/18010 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+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 1911187] [NEW] scheduled reboot reboots immediately if dbus or logind is not available
Public bug reported:
[IMPACT]
When, for whatever reason, logind or dbus is not available scheduled reboot
reboots the machine immediately.
>From the sources it seems that this is intended :
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318
However, I report this as a bug since this is against the logic of a scheduled
reboot; if someone schedules a reboot they want the system to reboot at the
specified time not immediately.
There has been a discussion upstream (
https://github.com/systemd/systemd/issues/17575 ) and
a PR ( https://github.com/systemd/systemd/pull/18010 ).
Upstream community is not willing to accept the patch but debian is.
I open this bug to to pull the patch into Ubuntu once it lands in debian.
[TEST CASE]
The simpler reproducer is to disable dbus to imitate the real world
case.
# systemctl stop dbus.service
# systemctl stop dbus.socket
# shutdown +1140 -r "REBOOT!"
Failed to set wall message, ignoring: Failed to activate service
'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
Failed to call ScheduleShutdown in logind, proceeding with immediate shutdown:
Connection timed out
Connection to groovy closed by remote host.
Connection to groovy closed.
[REGRESSION POTENTIAL]
The patch has minimal regression potential since it just takes no action
( instead of shutting down ) when bus_call_method fails.
[OTHER]
Upstream issue : https://github.com/systemd/systemd/issues/17575
PR : https://github.com/systemd/systemd/pull/18010
** Affects: systemd (Ubuntu)
Importance: Medium
Assignee: Ioanna Alifieraki (joalif)
Status: Confirmed
** Tags: sts
** Tags added: sts
** Changed in: systemd (Ubuntu)
Status: New => Confirmed
** Changed in: systemd (Ubuntu)
Importance: Undecided => Medium
** Changed in: systemd (Ubuntu)
Assignee: (unassigned) => Ioanna Alifieraki (joalif)
--
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/1911187
Title:
scheduled reboot reboots immediately if dbus or logind is not
available
Status in systemd package in Ubuntu:
Confirmed
Bug description:
[IMPACT]
When, for whatever reason, logind or dbus is not available scheduled reboot
reboots the machine immediately.
From the sources it seems that this is intended :
https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl-logind.c#L318
However, I report this as a bug since this is against the logic of a
scheduled reboot; if someone schedules a reboot they want the system to reboot
at the specified time not immediately.
There has been a discussion upstream (
https://github.com/systemd/systemd/issues/17575 ) and
a PR ( https://github.com/systemd/systemd/pull/18010 ).
Upstream community is not willing to accept the patch but debian is.
I open this bug to to pull the patch into Ubuntu once it lands in debian.
[TEST CASE]
The simpler reproducer is to disable dbus to imitate the real world
case.
# systemctl stop dbus.service
# systemctl stop dbus.socket
# shutdown +1140 -r "REBOOT!"
Failed to set wall message, ignoring: Failed to activate service
'org.freedesktop.login1': timed out (service_start_timeout=25000ms)
Failed to call ScheduleShutdown in logind, proceeding with immediate
shutdown: Connection timed out
Connection to groovy closed by remote host.
Connection to groovy closed.
[REGRESSION POTENTIAL]
The patch has minimal regression potential since it just takes no
action ( instead of shutting down ) when bus_call_method fails.
[OTHER]
Upstream issue : https://github.com/systemd/systemd/issues/17575
PR : https://github.com/systemd/systemd/pull/18010
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1911187/+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 1861177] Re: seccomp_rule_add is very slow
# autopkgtest regression in EOAN There is an autopkgtest regression in EOAN on ppc64el for systemd package. The regression is caused by the 'upstream' test. As it's shown here http://autopkgtest.ubuntu.com/packages/s/systemd/eoan/ppc64el this test has always been failing since systemd version 240-6ubuntu5 and can be ignored. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: Invalid Status in libseccomp package in Ubuntu: Fix Released Status in libseccomp source package in Xenial: Fix Committed Status in libseccomp source package in Bionic: Fix Committed Status in libseccomp source package in Eoan: Fix Committed Status in libseccomp source package in Focal: Fix Committed Status in libseccomp source package in Groovy: Fix Released Bug description: [IMPACT] There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 Upstream issue : https://github.com/seccomp/libseccomp/issues/153 Upstream fix : https://github.com/seccomp/libseccomp/pull/180/ [Test Case] For this test case we use Docker on Ubuntu Groovy (20.10) : --> Current libseccomp version #dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3 amd64high level interface to Linux seccomp filter ## pull ubuntu image # docker pull ubuntu ## create a container # docker run --name test_seccomp -it 74435f89ab78 /bin/bash ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m10,319s user 0m0,018s sys 0m0,033s --> Patched libseccomp version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu4 amd64high level interface to Linux seccomp filter # docker start test_seccomp ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m3,650s user 0m0,025s sys 0m0,028s [Regression Potential] The first of the 2 patches cleans up the code that adds rules to a single filter without changing the logic of the code. The second patch introduces the idea of shadow transactions. On a successful transaction commit the old transaction checkpoint is preserved and is brought up to date with the current filter. The next time a new transaction starts, it checks is the a shadow transaction exist and if so the shadow is used instead of creating a new checkpoint from scratch [1]. This is the patch that mitigates the performance regression. Any potential regression will involve the parts of the code that add rules to filters and/or the code that creates and checks the shadow transactions. [Other] Affected releases : Groovy, Focal, Eoan, Bionic, Xenial. [1] https://github.com/seccomp/libseccomp/pull/180/commits/bc3a6c0453b0350ee43e4925482f705a2fbf5a4d To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1861177] Re: seccomp_rule_add is very slow
#VERIFICATION EOAN ---> Old version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3.19.10.2amd64 high level interface to Linux seccomp filter # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done MAX TIME : 9.374s ---> New version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3.19.10.3 amd64 high level interface to Linux seccomp filter # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done MAX TIME : 2.009s ** Tags removed: verification-needed-eoan ** Tags added: verification-done-eoan -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: Invalid Status in libseccomp package in Ubuntu: Fix Released Status in libseccomp source package in Xenial: Fix Committed Status in libseccomp source package in Bionic: Fix Committed Status in libseccomp source package in Eoan: Fix Committed Status in libseccomp source package in Focal: Fix Committed Status in libseccomp source package in Groovy: Fix Released Bug description: [IMPACT] There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 Upstream issue : https://github.com/seccomp/libseccomp/issues/153 Upstream fix : https://github.com/seccomp/libseccomp/pull/180/ [Test Case] For this test case we use Docker on Ubuntu Groovy (20.10) : --> Current libseccomp version #dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3 amd64high level interface to Linux seccomp filter ## pull ubuntu image # docker pull ubuntu ## create a container # docker run --name test_seccomp -it 74435f89ab78 /bin/bash ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m10,319s user 0m0,018s sys 0m0,033s --> Patched libseccomp version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu4 amd64high level interface to Linux seccomp filter # docker start test_seccomp ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m3,650s user 0m0,025s sys 0m0,028s [Regression Potential] The first of the 2 patches cleans up the code that adds rules to a single filter without changing the logic of the code. The second patch introduces the idea of shadow transactions. On a successful transaction commit the old transaction checkpoint is preserved and is brought up to date with the current filter. The next time a new transaction starts, it checks is the a shadow transaction exist and if so the shadow is used instead of creating a new checkpoint from scratch [1]. This is the patch that mitigates the performance regression. Any potential regression will involve the parts of the code that add rules to filters and/or the code that creates and checks the shadow transactions. [Other] Affected releases : Groovy, Focal, Eoan, Bionic, Xenial. [1] https://github.com/seccomp/libseccomp/pull/180/commits/bc3a6c0453b0350ee43e4925482f705a2fbf5a4d To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1861177] Re: seccomp_rule_add is very slow
#VERIFICATION BIONIC ---> Old version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3.18.04.2 amd64 high level interface to Linux seccomp filter # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done MAX TIME : 8.148s ---> New version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3.18.04.3 amd64 high level interface to Linux seccomp filter # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done MAX TIME : 2.713s ** 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 libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: Invalid Status in libseccomp package in Ubuntu: Fix Released Status in libseccomp source package in Xenial: Fix Committed Status in libseccomp source package in Bionic: Fix Committed Status in libseccomp source package in Eoan: Fix Committed Status in libseccomp source package in Focal: Fix Committed Status in libseccomp source package in Groovy: Fix Released Bug description: [IMPACT] There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 Upstream issue : https://github.com/seccomp/libseccomp/issues/153 Upstream fix : https://github.com/seccomp/libseccomp/pull/180/ [Test Case] For this test case we use Docker on Ubuntu Groovy (20.10) : --> Current libseccomp version #dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3 amd64high level interface to Linux seccomp filter ## pull ubuntu image # docker pull ubuntu ## create a container # docker run --name test_seccomp -it 74435f89ab78 /bin/bash ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m10,319s user 0m0,018s sys 0m0,033s --> Patched libseccomp version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu4 amd64high level interface to Linux seccomp filter # docker start test_seccomp ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m3,650s user 0m0,025s sys 0m0,028s [Regression Potential] The first of the 2 patches cleans up the code that adds rules to a single filter without changing the logic of the code. The second patch introduces the idea of shadow transactions. On a successful transaction commit the old transaction checkpoint is preserved and is brought up to date with the current filter. The next time a new transaction starts, it checks is the a shadow transaction exist and if so the shadow is used instead of creating a new checkpoint from scratch [1]. This is the patch that mitigates the performance regression. Any potential regression will involve the parts of the code that add rules to filters and/or the code that creates and checks the shadow transactions. [Other] Affected releases : Groovy, Focal, Eoan, Bionic, Xenial. [1] https://github.com/seccomp/libseccomp/pull/180/commits/bc3a6c0453b0350ee43e4925482f705a2fbf5a4d To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1861177] Re: seccomp_rule_add is very slow
#VERIFICATION FOCAL ---> Old version # dpkg -l | grep libseccomp ii libseccomp2:amd642.4.3-1ubuntu3.20.04.2 amd64high level interface to Linux seccomp filter # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done MAX TIME : 10.176s ---> New version # dpkg -l | grep libseccomp ii libseccomp2:amd642.4.3-1ubuntu3.20.04.3 amd64high level interface to Linux seccomp filter # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done MAX TIME : 3.161s ** Tags removed: verification-needed-focal ** Tags added: verification-done-focal -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: Invalid Status in libseccomp package in Ubuntu: Fix Released Status in libseccomp source package in Xenial: Fix Committed Status in libseccomp source package in Bionic: Fix Committed Status in libseccomp source package in Eoan: Fix Committed Status in libseccomp source package in Focal: Fix Committed Status in libseccomp source package in Groovy: Fix Released Bug description: [IMPACT] There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 Upstream issue : https://github.com/seccomp/libseccomp/issues/153 Upstream fix : https://github.com/seccomp/libseccomp/pull/180/ [Test Case] For this test case we use Docker on Ubuntu Groovy (20.10) : --> Current libseccomp version #dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3 amd64high level interface to Linux seccomp filter ## pull ubuntu image # docker pull ubuntu ## create a container # docker run --name test_seccomp -it 74435f89ab78 /bin/bash ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m10,319s user 0m0,018s sys 0m0,033s --> Patched libseccomp version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu4 amd64high level interface to Linux seccomp filter # docker start test_seccomp ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m3,650s user 0m0,025s sys 0m0,028s [Regression Potential] The first of the 2 patches cleans up the code that adds rules to a single filter without changing the logic of the code. The second patch introduces the idea of shadow transactions. On a successful transaction commit the old transaction checkpoint is preserved and is brought up to date with the current filter. The next time a new transaction starts, it checks is the a shadow transaction exist and if so the shadow is used instead of creating a new checkpoint from scratch [1]. This is the patch that mitigates the performance regression. Any potential regression will involve the parts of the code that add rules to filters and/or the code that creates and checks the shadow transactions. [Other] Affected releases : Groovy, Focal, Eoan, Bionic, Xenial. [1] https://github.com/seccomp/libseccomp/pull/180/commits/bc3a6c0453b0350ee43e4925482f705a2fbf5a4d To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1861177] Re: seccomp_rule_add is very slow
#VERIFICATION XENIAL ---> Old version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3.16.04.2 amd64high level interface to Linux seccomp filte # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done MAX TIME : 8.923s ---> New version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3.16.04.3 amd64high level interface to Linux seccomp filter # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done MAX TIME : 3.270s ** 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 libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: Invalid Status in libseccomp package in Ubuntu: Fix Released Status in libseccomp source package in Xenial: Fix Committed Status in libseccomp source package in Bionic: Fix Committed Status in libseccomp source package in Eoan: Fix Committed Status in libseccomp source package in Focal: Fix Committed Status in libseccomp source package in Groovy: Fix Released Bug description: [IMPACT] There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 Upstream issue : https://github.com/seccomp/libseccomp/issues/153 Upstream fix : https://github.com/seccomp/libseccomp/pull/180/ [Test Case] For this test case we use Docker on Ubuntu Groovy (20.10) : --> Current libseccomp version #dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3 amd64high level interface to Linux seccomp filter ## pull ubuntu image # docker pull ubuntu ## create a container # docker run --name test_seccomp -it 74435f89ab78 /bin/bash ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m10,319s user 0m0,018s sys 0m0,033s --> Patched libseccomp version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu4 amd64high level interface to Linux seccomp filter # docker start test_seccomp ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m3,650s user 0m0,025s sys 0m0,028s [Regression Potential] The first of the 2 patches cleans up the code that adds rules to a single filter without changing the logic of the code. The second patch introduces the idea of shadow transactions. On a successful transaction commit the old transaction checkpoint is preserved and is brought up to date with the current filter. The next time a new transaction starts, it checks is the a shadow transaction exist and if so the shadow is used instead of creating a new checkpoint from scratch [1]. This is the patch that mitigates the performance regression. Any potential regression will involve the parts of the code that add rules to filters and/or the code that creates and checks the shadow transactions. [Other] Affected releases : Groovy, Focal, Eoan, Bionic, Xenial. [1] https://github.com/seccomp/libseccomp/pull/180/commits/bc3a6c0453b0350ee43e4925482f705a2fbf5a4d To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1861177] Re: seccomp_rule_add is very slow
Currently, there are autopkgtest regressions on Groovy for the docker.io package : https://people.canonical.com/~ubuntu-archive/proposed-migration/groovy/update_excuses.html#libseccomp These regressions are not due to the new libseccomp (can be reproduced with previous libseccomp version). They are due to a bug in cloud-init when in lxd container, where 'cloud-init status' status returns error. See bug https://bugs.launchpad.net/ubuntu/+source/cloud- init/+bug/1886531 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: Invalid Status in libseccomp package in Ubuntu: In Progress Status in libseccomp source package in Xenial: In Progress Status in libseccomp source package in Bionic: In Progress Status in libseccomp source package in Eoan: In Progress Status in libseccomp source package in Focal: In Progress Status in libseccomp source package in Groovy: In Progress Bug description: [IMPACT] There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 Upstream issue : https://github.com/seccomp/libseccomp/issues/153 Upstream fix : https://github.com/seccomp/libseccomp/pull/180/ [Test Case] For this test case we use Docker on Ubuntu Groovy (20.10) : --> Current libseccomp version #dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3 amd64high level interface to Linux seccomp filter ## pull ubuntu image # docker pull ubuntu ## create a container # docker run --name test_seccomp -it 74435f89ab78 /bin/bash ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m10,319s user 0m0,018s sys 0m0,033s --> Patched libseccomp version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu4 amd64high level interface to Linux seccomp filter # docker start test_seccomp ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m3,650s user 0m0,025s sys 0m0,028s [Regression Potential] The first of the 2 patches cleans up the code that adds rules to a single filter without changing the logic of the code. The second patch introduces the idea of shadow transactions. On a successful transaction commit the old transaction checkpoint is preserved and is brought up to date with the current filter. The next time a new transaction starts, it checks is the a shadow transaction exist and if so the shadow is used instead of creating a new checkpoint from scratch [1]. This is the patch that mitigates the performance regression. Any potential regression will involve the parts of the code that add rules to filters and/or the code that creates and checks the shadow transactions. [Other] Affected releases : Groovy, Focal, Eoan, Bionic, Xenial. [1] https://github.com/seccomp/libseccomp/pull/180/commits/bc3a6c0453b0350ee43e4925482f705a2fbf5a4d To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1861177] Re: seccomp_rule_add is very slow
Debdiff for Xenial. ** Patch added: "lp1861177_xenial.debdiff" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1861177/+attachment/5388142/+files/lp1861177_xenial.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: Invalid Status in libseccomp package in Ubuntu: In Progress Status in libseccomp source package in Xenial: In Progress Status in libseccomp source package in Bionic: In Progress Status in libseccomp source package in Eoan: In Progress Status in libseccomp source package in Focal: In Progress Status in libseccomp source package in Groovy: In Progress Bug description: [IMPACT] There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 Upstream issue : https://github.com/seccomp/libseccomp/issues/153 Upstream fix : https://github.com/seccomp/libseccomp/pull/180/ [Test Case] For this test case we use Docker on Ubuntu Groovy (20.10) : --> Current libseccomp version #dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3 amd64high level interface to Linux seccomp filter ## pull ubuntu image # docker pull ubuntu ## create a container # docker run --name test_seccomp -it 74435f89ab78 /bin/bash ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m10,319s user 0m0,018s sys 0m0,033s --> Patched libseccomp version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu4 amd64high level interface to Linux seccomp filter # docker start test_seccomp ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m3,650s user 0m0,025s sys 0m0,028s [Regression Potential] The first of the 2 patches cleans up the code that adds rules to a single filter without changing the logic of the code. The second patch introduces the idea of shadow transactions. On a successful transaction commit the old transaction checkpoint is preserved and is brought up to date with the current filter. The next time a new transaction starts, it checks is the a shadow transaction exist and if so the shadow is used instead of creating a new checkpoint from scratch [1]. This is the patch that mitigates the performance regression. Any potential regression will involve the parts of the code that add rules to filters and/or the code that creates and checks the shadow transactions. [Other] Affected releases : Groovy, Focal, Eoan, Bionic, Xenial. [1] https://github.com/seccomp/libseccomp/pull/180/commits/bc3a6c0453b0350ee43e4925482f705a2fbf5a4d To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1861177] Re: seccomp_rule_add is very slow
Debdiff for Bionic. ** Patch added: "lp1861177_bionic.debdiff" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1861177/+attachment/5388141/+files/lp1861177_bionic.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: Invalid Status in libseccomp package in Ubuntu: In Progress Status in libseccomp source package in Xenial: In Progress Status in libseccomp source package in Bionic: In Progress Status in libseccomp source package in Eoan: In Progress Status in libseccomp source package in Focal: In Progress Status in libseccomp source package in Groovy: In Progress Bug description: [IMPACT] There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 Upstream issue : https://github.com/seccomp/libseccomp/issues/153 Upstream fix : https://github.com/seccomp/libseccomp/pull/180/ [Test Case] For this test case we use Docker on Ubuntu Groovy (20.10) : --> Current libseccomp version #dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3 amd64high level interface to Linux seccomp filter ## pull ubuntu image # docker pull ubuntu ## create a container # docker run --name test_seccomp -it 74435f89ab78 /bin/bash ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m10,319s user 0m0,018s sys 0m0,033s --> Patched libseccomp version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu4 amd64high level interface to Linux seccomp filter # docker start test_seccomp ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m3,650s user 0m0,025s sys 0m0,028s [Regression Potential] The first of the 2 patches cleans up the code that adds rules to a single filter without changing the logic of the code. The second patch introduces the idea of shadow transactions. On a successful transaction commit the old transaction checkpoint is preserved and is brought up to date with the current filter. The next time a new transaction starts, it checks is the a shadow transaction exist and if so the shadow is used instead of creating a new checkpoint from scratch [1]. This is the patch that mitigates the performance regression. Any potential regression will involve the parts of the code that add rules to filters and/or the code that creates and checks the shadow transactions. [Other] Affected releases : Groovy, Focal, Eoan, Bionic, Xenial. [1] https://github.com/seccomp/libseccomp/pull/180/commits/bc3a6c0453b0350ee43e4925482f705a2fbf5a4d To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1861177] Re: seccomp_rule_add is very slow
Debdiff for Focal. ** Patch added: "lp1861177_focal.debdiff" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1861177/+attachment/5388139/+files/lp1861177_focal.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: Invalid Status in libseccomp package in Ubuntu: In Progress Status in libseccomp source package in Xenial: In Progress Status in libseccomp source package in Bionic: In Progress Status in libseccomp source package in Eoan: In Progress Status in libseccomp source package in Focal: In Progress Status in libseccomp source package in Groovy: In Progress Bug description: [IMPACT] There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 Upstream issue : https://github.com/seccomp/libseccomp/issues/153 Upstream fix : https://github.com/seccomp/libseccomp/pull/180/ [Test Case] For this test case we use Docker on Ubuntu Groovy (20.10) : --> Current libseccomp version #dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3 amd64high level interface to Linux seccomp filter ## pull ubuntu image # docker pull ubuntu ## create a container # docker run --name test_seccomp -it 74435f89ab78 /bin/bash ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m10,319s user 0m0,018s sys 0m0,033s --> Patched libseccomp version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu4 amd64high level interface to Linux seccomp filter # docker start test_seccomp ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m3,650s user 0m0,025s sys 0m0,028s [Regression Potential] The first of the 2 patches cleans up the code that adds rules to a single filter without changing the logic of the code. The second patch introduces the idea of shadow transactions. On a successful transaction commit the old transaction checkpoint is preserved and is brought up to date with the current filter. The next time a new transaction starts, it checks is the a shadow transaction exist and if so the shadow is used instead of creating a new checkpoint from scratch [1]. This is the patch that mitigates the performance regression. Any potential regression will involve the parts of the code that add rules to filters and/or the code that creates and checks the shadow transactions. [Other] Affected releases : Groovy, Focal, Eoan, Bionic, Xenial. [1] https://github.com/seccomp/libseccomp/pull/180/commits/bc3a6c0453b0350ee43e4925482f705a2fbf5a4d To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1861177] Re: seccomp_rule_add is very slow
Debdiff for Eoan. ** Patch added: "lp1861177_eoan.debdiff" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1861177/+attachment/5388140/+files/lp1861177_eoan.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: Invalid Status in libseccomp package in Ubuntu: In Progress Status in libseccomp source package in Xenial: In Progress Status in libseccomp source package in Bionic: In Progress Status in libseccomp source package in Eoan: In Progress Status in libseccomp source package in Focal: In Progress Status in libseccomp source package in Groovy: In Progress Bug description: [IMPACT] There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 Upstream issue : https://github.com/seccomp/libseccomp/issues/153 Upstream fix : https://github.com/seccomp/libseccomp/pull/180/ [Test Case] For this test case we use Docker on Ubuntu Groovy (20.10) : --> Current libseccomp version #dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu3 amd64high level interface to Linux seccomp filter ## pull ubuntu image # docker pull ubuntu ## create a container # docker run --name test_seccomp -it 74435f89ab78 /bin/bash ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m10,319s user 0m0,018s sys 0m0,033s --> Patched libseccomp version # dpkg -l | grep libseccomp ii libseccomp2:amd64 2.4.3-1ubuntu4 amd64high level interface to Linux seccomp filter # docker start test_seccomp ## run test case # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done ... MAX TIME : real 0m3,650s user 0m0,025s sys 0m0,028s [Regression Potential] The first of the 2 patches cleans up the code that adds rules to a single filter without changing the logic of the code. The second patch introduces the idea of shadow transactions. On a successful transaction commit the old transaction checkpoint is preserved and is brought up to date with the current filter. The next time a new transaction starts, it checks is the a shadow transaction exist and if so the shadow is used instead of creating a new checkpoint from scratch [1]. This is the patch that mitigates the performance regression. Any potential regression will involve the parts of the code that add rules to filters and/or the code that creates and checks the shadow transactions. [Other] Affected releases : Groovy, Focal, Eoan, Bionic, Xenial. [1] https://github.com/seccomp/libseccomp/pull/180/commits/bc3a6c0453b0350ee43e4925482f705a2fbf5a4d To manage notifications about this bug go to: https://bugs.launchpad.net/snapd/+bug/1861177/+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 1861177] Re: seccomp_rule_add is very slow
Debdiff for Groovy. Currently, there is an ongoing sru of libseccomp for F,E,B and X stuck in proposed. Once it is released in updates, I'll sru this one for F,E,B and X. ** Description changed: - There is a known and patched issue with version 2.4 of libseccomp where - certain operations have a large performance regression. This is causing - some packages that use libseccomp such as container orchestration - systems to occasionally time out or otherwise fail under certain - workloads. + [IMPACT] + There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 + + Upstream issue : https://github.com/seccomp/libseccomp/issues/153 + Upstream fix : https://github.com/seccomp/libseccomp/pull/180/ + + [Test Case] + + For this test case we use Docker on Ubuntu Groovy (20.10) : + + --> Current libseccomp version + #dpkg -l | grep libseccomp + ii libseccomp2:amd64 2.4.3-1ubuntu3 amd64high level interface to Linux seccomp filter + + ## pull ubuntu image + # docker pull ubuntu + ## create a container + # docker run --name test_seccomp -it 74435f89ab78 /bin/bash + + ## run test case + # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done + ... + MAX TIME : + real 0m10,319s + user 0m0,018s + sys 0m0,033s + + + --> Patched libseccomp version + + # dpkg -l | grep libseccomp + ii libseccomp2:amd64 2.4.3-1ubuntu4 amd64high level interface to Linux seccomp filter + + # docker start test_seccomp + ## run test case + # for i in `seq 1 40`; do (time sudo docker exec test_seccomp true &); done + ... + MAX TIME : + real 0m3,650s + user 0m0,025s + sys 0m0,028s + + [Regression Potential] + + The first of the 2 patches cleans up the code that adds rules to a + single filter without changing the logic of the code. The second patch + introduces the idea of shadow transactions. On a successful transaction + commit the old transaction checkpoint is preserved and is brought up to + date with the current filter. The next time a new transaction starts, it + checks is the a shadow transaction exist and if so the shadow is used + instead of creating a new checkpoint from scratch [1]. This is the patch + that mitigates the performance regression. Any potential regression will + involve the parts of the code that add rules to filters and/or the code + that creates and checks the shadow transactions. + + + [Other] + + Affected releases : Groovy, Focal, Eoan, Bionic, Xenial. + + [1] + https://github.com/seccomp/libseccomp/pull/180/commits/bc3a6c0453b0350ee43e4925482f705a2fbf5a4d ** Patch added: "lp1861177_groovy.debdiff" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1861177/+attachment/5386079/+files/lp1861177_groovy.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1861177 Title: seccomp_rule_add is very slow Status in snapd: Invalid Status in libseccomp package in Ubuntu: In Progress Status in libseccomp source package in Xenial: In Progress Status in libseccomp source package in Bionic: In Progress Status in libseccomp source package in Eoan: In Progress Status in libseccomp source package in Focal: In Progress Status in libseccomp source package in Groovy: In Progress Bug description: [IMPACT] There is a known and patched issue with version 2.4 of libseccomp where certain operations have a large performance regression. This is causing some packages that use libseccomp such as container orchestration systems to occasionally time out or otherwise fail under certain workloads. Please consider porting the patch into the various Ubuntu versions that have version 2.4 of libseccomp and into the backports. The performance patch from version 2.5 (yet to be released) applies cleanly on top of the 2.4 branch of libseccomp. For more information, and for a copy of the patch (which can also be cherry picked from the upstream libseccomp repos) see the similar Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913 Upstream issue : https://github.com/seccomp/libseccomp/issues/153 Upstream fix :
[Touch-packages] [Bug 1861177] Re: seccomp_rule_add is very slow
** Also affects: libseccomp (Ubuntu Focal)
Importance: Undecided
Status: New
** Also affects: libseccomp (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: libseccomp (Ubuntu Groovy)
Importance: Medium
Status: In Progress
** Also affects: libseccomp (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: libseccomp (Ubuntu Eoan)
Importance: Undecided
Status: New
** Changed in: libseccomp (Ubuntu Focal)
Status: New => In Progress
** Changed in: libseccomp (Ubuntu Eoan)
Status: New => In Progress
** Changed in: libseccomp (Ubuntu Bionic)
Status: New => In Progress
** Changed in: libseccomp (Ubuntu Xenial)
Status: New => In Progress
** Changed in: libseccomp (Ubuntu Focal)
Importance: Undecided => Medium
** Changed in: libseccomp (Ubuntu Eoan)
Importance: Undecided => Medium
** Changed in: libseccomp (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: libseccomp (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: libseccomp (Ubuntu Xenial)
Assignee: (unassigned) => Ioanna Alifieraki (joalif)
** Changed in: libseccomp (Ubuntu Bionic)
Assignee: (unassigned) => Ioanna Alifieraki (joalif)
** Changed in: libseccomp (Ubuntu Eoan)
Assignee: (unassigned) => Ioanna Alifieraki (joalif)
** Changed in: libseccomp (Ubuntu Focal)
Assignee: (unassigned) => Ioanna Alifieraki (joalif)
** Changed in: libseccomp (Ubuntu Groovy)
Assignee: (unassigned) => Ioanna Alifieraki (joalif)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1861177
Title:
seccomp_rule_add is very slow
Status in snapd:
Invalid
Status in libseccomp package in Ubuntu:
In Progress
Status in libseccomp source package in Xenial:
In Progress
Status in libseccomp source package in Bionic:
In Progress
Status in libseccomp source package in Eoan:
In Progress
Status in libseccomp source package in Focal:
In Progress
Status in libseccomp source package in Groovy:
In Progress
Bug description:
There is a known and patched issue with version 2.4 of libseccomp
where certain operations have a large performance regression. This is
causing some packages that use libseccomp such as container
orchestration systems to occasionally time out or otherwise fail under
certain workloads.
Please consider porting the patch into the various Ubuntu versions
that have version 2.4 of libseccomp and into the backports. The
performance patch from version 2.5 (yet to be released) applies
cleanly on top of the 2.4 branch of libseccomp.
For more information, and for a copy of the patch (which can also be
cherry picked from the upstream libseccomp repos) see the similar
Debian issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=943913
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1861177/+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 1860548] Re: systemd crashes when logging long message
RE-VERIFICATION ON BIONIC Installed systemd from -proposed : # dpkg -l | grep systemd ii libnss-systemd:amd64 237-3ubuntu10.39 amd64nss module providing dynamic user and group name resolution ii libpam-systemd:amd64 237-3ubuntu10.39 amd64system and service manager - PAM module ii libsystemd0:amd64 237-3ubuntu10.39 amd64systemd utility library ii python3-systemd 234-1build1 amd64Python 3 bindings for systemd ii systemd 237-3ubuntu10.39 amd64system and service manager ii systemd-sysv 237-3ubuntu10.39 amd64system and service manager - SysV links Following the reproducer described in the [Test Case] section of the bug description : # systemd-run --scope apt-get -q -y -o DPkg::Options::=--force-confold -o DPkg::Options::=--force-confdef --allow-unauthenticated install acl adduser amd64-microcode apt base-files base-passwd bash bash-completion bind9-host binfmt-support binutils-common binutils-x86-64-linux-gnu bsdmainutils bsdutils busybox-initramfs busybox-static bzip2 ca-certificates console-setup console-setup-linux coreutils cpio cpp cpp-7 crda cron curl dash dbus dctrl-tools debconf debconf-i18n debianutils dictionaries-common diffutils dirmngr distro-info-data dmeventd dmsetup dnsmasq-base dnsutils dpkg e2fslibs e2fsprogs ed eject fakeroot fdisk file findutils friendly-recovery gawk gcc-7-base gcc-8-base gettext-base gir1.2-glib-2.0 gnupg gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm gpgv grep groff-base grub-common grub-pc grub-pc-bin grub2-common gzip hostname info init init-system-helpers initramfs-tools initramfs-tools-bin initramfs-tools-core install-info intel-microcode iproute2 iptables iputils-ping iputils-tracepath irqbalance isc-dhcp-client isc-dhcp-common iso-codes iw keyboard-configuration keyutils klibc-utils kmod krb5-locales krb5-user language-pack-en language-pack-en-base language-pack-gnome-en language-pack-gnome-en-base less libaccountsservice0 libacl1 libapparmor1 libargon2-0 libasan4 libasn1-8-heimdal libassuan0 libatm1 libatomic1 libattr1 libaudit-common libaudit1 libbinutils libblkid1 libbsd0 libbz2-1.0 libc-bin libc-dev-bin libc6 libc6-dev libcap-ng0 libcap2 libcap2-bin libcc1-0 libcilkrts5 libcom-err2 libcryptsetup12 libcurl3-gnutls libcurl4 libdb5.3 libdbus-1-3 libdebconfclient0 libdevmapper-event1.02.1 libdevmapper1.02.1 libdpkg-perl libdrm-common libdrm2 libdumbnet1 libedit2 libelf1 libestr0 libevent-2.1-6 libexpat1 libexpat1-dev libext2fs2 libfakeroot libfastjson4 libfdisk1 libffi6 libfreetype6 libfribidi0 libfuse2 libgc1c2 libgcc-7-dev libgcc1 libgcrypt20 libgdbm-compat4 libgeoip1 libgirepository-1.0-1 libglib2.0-0 libglib2.0-data libgmp10 libgnutls30 libgomp1 libgpg-error0 libgpm2 libgssapi-krb5-2 libgssapi3-heimdal libgssrpc4 libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal libhogweed4 libhx509-5-heimdal libitm1 libjs-jquery libjs-sphinxdoc libjs-underscore libk5crypto3 libkadm5clnt-mit11 libkadm5srv-mit11 libkdb5-9 libkeyutils1 libkmod2 libkrb5-26-heimdal libkrb5-3 libkrb5support0 libksba8 libldap-2.4-2 libldap-common liblocale-gettext-perl liblsan0 liblz4-1 liblzma5 libmagic-mgc libmagic1 libmnl0 libmount1 libmpc3 libmpdec2 libmpfr6 libmpx2 libmspack0 libncurses5 libncursesw5 libnetfilter-conntrack3 libnettle6 libnewt0.52 libnfnetlink0 libnfsidmap2 libnghttp2-14 libnl-3-200 libnl-genl-3-200 libnorm1 libnpth0 libnss-systemd libnuma1 libp11-kit0 libpam-cap libpam-krb5 libpam-modules libpam-modules-bin libpam-runtime libpam-systemd libpam0g libparted2 libpcap0.8 libpci3 libpcre3 libpgm-5.2-0 libpipeline1 libplymouth4 libpng16-16 libpolkit-gobject-1-0 libpopt0 libpsl5 libpython-all-dev libpython-dev libpython-stdlib libpython2.7 libpython2.7-dev libpython2.7-minimal Command terminates successfully without aborting. ** 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/1860548 Title: systemd crashes when logging long message Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Released Bug description: [Impact] Systemd crashes when logging very long messages. This regression was introduced with upstream commit d054f0a4d451 [1] due to xsprintf. Commits e68eedbbdc98 [2] and 574432f889ce [3]
[Touch-packages] [Bug 1860548] Re: systemd crashes when logging long message
VERIFICATION ON BIONIC Installed systemd from -proposed : # dpkg -l | grep systemd ii libnss-systemd:amd64 237-3ubuntu10.34 amd64nss module providing dynamic user and group name resolution ii libsystemd0:amd64 237-3ubuntu10.34 amd64systemd utility library ii python3-systemd 234-1build1 amd64Python 3 bindings for systemd ii systemd 237-3ubuntu10.34 amd64system and service manager ii systemd-sysv 237-3ubuntu10.34 amd64system and service manager - SysV links Following the reproducer described in the [Test Case] section of the bug description : # systemd-run --scope apt-get -q -y -o DPkg::Options::=--force-confold -o DPkg::Options::=--force-confdef --allow-unauthenticated install acl adduser amd64-microcode apt base-files base-passwd bash bash-completion bind9-host binfmt-support binutils-common binutils-x86-64-linux-gnu bsdmainutils bsdutils busybox-initramfs busybox-static bzip2 ca-certificates console-setup console-setup-linux coreutils cpio cpp cpp-7 crda cron curl dash dbus dctrl-tools debconf debconf-i18n debianutils dictionaries-common diffutils dirmngr distro-info-data dmeventd dmsetup dnsmasq-base dnsutils dpkg e2fslibs e2fsprogs ed eject fakeroot fdisk file findutils friendly-recovery gawk gcc-7-base gcc-8-base gettext-base gir1.2-glib-2.0 gnupg gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm gpgv grep groff-base grub-common grub-pc grub-pc-bin grub2-common gzip hostname info init init-system-helpers initramfs-tools initramfs-tools-bin initramfs-tools-core install-info intel-microcode iproute2 iptables iputils-ping iputils-tracepath irqbalance isc-dhcp-client isc-dhcp-common iso-codes iw keyboard-configuration keyutils klibc-utils kmod krb5-locales krb5-user language-pack-en language-pack-en-base language-pack-gnome-en language-pack-gnome-en-base less libaccountsservice0 libacl1 libapparmor1 libargon2-0 libasan4 libasn1-8-heimdal libassuan0 libatm1 libatomic1 libattr1 libaudit-common libaudit1 libbinutils libblkid1 libbsd0 libbz2-1.0 libc-bin libc-dev-bin libc6 libc6-dev libcap-ng0 libcap2 libcap2-bin libcc1-0 libcilkrts5 libcom-err2 libcryptsetup12 libcurl3-gnutls libcurl4 libdb5.3 libdbus-1-3 libdebconfclient0 libdevmapper-event1.02.1 libdevmapper1.02.1 libdpkg-perl libdrm-common libdrm2 libdumbnet1 libedit2 libelf1 libestr0 libevent-2.1-6 libexpat1 libexpat1-dev libext2fs2 libfakeroot libfastjson4 libfdisk1 libffi6 libfreetype6 libfribidi0 libfuse2 libgc1c2 libgcc-7-dev libgcc1 libgcrypt20 libgdbm-compat4 libgeoip1 libgirepository-1.0-1 libglib2.0-0 libglib2.0-data libgmp10 libgnutls30 libgomp1 libgpg-error0 libgpm2 libgssapi-krb5-2 libgssapi3-heimdal libgssrpc4 libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal libhogweed4 libhx509-5-heimdal libitm1 libjs-jquery libjs-sphinxdoc libjs-underscore libk5crypto3 libkadm5clnt-mit11 libkadm5srv-mit11 libkdb5-9 libkeyutils1 libkmod2 libkrb5-26-heimdal libkrb5-3 libkrb5support0 libksba8 libldap-2.4-2 libldap-common liblocale-gettext-perl liblsan0 liblz4-1 liblzma5 libmagic-mgc libmagic1 libmnl0 libmount1 libmpc3 libmpdec2 libmpfr6 libmpx2 libmspack0 libncurses5 libncursesw5 libnetfilter-conntrack3 libnettle6 libnewt0.52 libnfnetlink0 libnfsidmap2 libnghttp2-14 libnl-3-200 libnl-genl-3-200 libnorm1 libnpth0 libnss-systemd libnuma1 libp11-kit0 libpam-cap libpam-krb5 libpam-modules libpam-modules-bin libpam-runtime libpam-systemd libpam0g libparted2 libpcap0.8 libpci3 libpcre3 libpgm-5.2-0 libpipeline1 libplymouth4 libpng16-16 libpolkit-gobject-1-0 libpopt0 libpsl5 libpython-all-dev libpython-dev libpython-stdlib libpython2.7 libpython2.7-dev libpython2.7-minimal Command terminates successfully without aborting. ** Tags removed: verification-needed-bionic ** Tags added: verification-done-bionic ** 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/1860548 Title: systemd crashes when logging long message Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Released Bug description: [Impact] Systemd crashes when logging very long messages. This regression was introduced with upstream commit d054f0a4d451 [1] due to xsprintf. Commits e68eedbbdc98 [2] and 574432f889ce [3] replace some uses of xsprintf with snprintf and fix it. [Test Case] # systemd-run --scope apt-get -q -y -o
[Touch-packages] [Bug 1860548] Re: systemd crashes when logging long message
** Patch added: "debdiff for bionic" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1860548/+attachment/5322196/+files/lp1860548_bionic.debdiff ** Tags added: sts sts-sponsor-ddstreet -- 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/1860548 Title: systemd crashes when logging long message Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Confirmed Status in systemd source package in Disco: Fix Released Status in systemd source package in Eoan: Fix Released Bug description: [Description] Systemd crashes when logging very long messages. This regression was introduced with upstream commit d054f0a4d451 [1] due to xsprintf. Commits e68eedbbdc98 [2] and 574432f889ce [3] replace some uses of xsprintf with snprintf and fix it. [Test Case] # systemd-run --scope apt-get -q -y -o DPkg::Options::=--force-confold -o DPkg::Options::=--force-confdef --allow-unauthenticated install acl adduser amd64-microcode apt base-files base-passwd bash bash- completion bind9-host binfmt-support binutils-common binutils-x86-64 -linux-gnu bsdmainutils bsdutils busybox-initramfs busybox-static bzip2 ca-certificates console-setup console-setup-linux coreutils cpio cpp cpp-7 crda cron curl dash dbus dctrl-tools debconf debconf-i18n debianutils dictionaries-common diffutils dirmngr distro-info-data dmeventd dmsetup dnsmasq-base dnsutils dpkg e2fslibs e2fsprogs ed eject fakeroot fdisk file findutils friendly-recovery gawk gcc-7-base gcc-8-base gettext-base gir1.2-glib-2.0 gnupg gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks-client gpg-wks-server gpgconf gpgsm gpgv grep groff-base grub-common grub-pc grub-pc-bin grub2-common gzip hostname info init init-system-helpers initramfs-tools initramfs-tools-bin initramfs-tools-core install-info intel-microcode iproute2 iptables iputils-ping iputils-tracepath irqbalance isc-dhcp-client isc-dhcp- common iso-codes iw keyboard-configuration keyutils klibc-utils kmod krb5-locales krb5-user language-pack-en language-pack-en-base language-pack-gnome-en language-pack-gnome-en-base less libaccountsservice0 libacl1 libapparmor1 libargon2-0 libasan4 libasn1-8-heimdal libassuan0 libatm1 libatomic1 libattr1 libaudit- common libaudit1 libbinutils libblkid1 libbsd0 libbz2-1.0 libc-bin libc-dev-bin libc6 libc6-dev libcap-ng0 libcap2 libcap2-bin libcc1-0 libcilkrts5 libcom-err2 libcryptsetup12 libcurl3-gnutls libcurl4 libdb5.3 libdbus-1-3 libdebconfclient0 libdevmapper-event1.02.1 libdevmapper1.02.1 libdpkg-perl libdrm-common libdrm2 libdumbnet1 libedit2 libelf1 libestr0 libevent-2.1-6 libexpat1 libexpat1-dev libext2fs2 libfakeroot libfastjson4 libfdisk1 libffi6 libfreetype6 libfribidi0 libfuse2 libgc1c2 libgcc-7-dev libgcc1 libgcrypt20 libgdbm-compat4 libgeoip1 libgirepository-1.0-1 libglib2.0-0 libglib2.0-data libgmp10 libgnutls30 libgomp1 libgpg-error0 libgpm2 libgssapi-krb5-2 libgssapi3-heimdal libgssrpc4 libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal libhogweed4 libhx509-5-heimdal libitm1 libjs-jquery libjs-sphinxdoc libjs- underscore libk5crypto3 libkadm5clnt-mit11 libkadm5srv-mit11 libkdb5-9 libkeyutils1 libkmod2 libkrb5-26-heimdal libkrb5-3 libkrb5support0 libksba8 libldap-2.4-2 libldap-common liblocale-gettext-perl liblsan0 liblz4-1 liblzma5 libmagic-mgc libmagic1 libmnl0 libmount1 libmpc3 libmpdec2 libmpfr6 libmpx2 libmspack0 libncurses5 libncursesw5 libnetfilter-conntrack3 libnettle6 libnewt0.52 libnfnetlink0 libnfsidmap2 libnghttp2-14 libnl-3-200 libnl-genl-3-200 libnorm1 libnpth0 libnss-systemd libnuma1 libp11-kit0 libpam-cap libpam-krb5 libpam-modules libpam-modules-bin libpam-runtime libpam-systemd libpam0g libparted2 libpcap0.8 libpci3 libpcre3 libpgm-5.2-0 libpipeline1 libplymouth4 libpng16-16 libpolkit-gobject-1-0 libpopt0 libpsl5 libpython-all-dev libpython-dev libpython-stdlib libpython2.7 libpython2.7-dev libpython2.7-minimal # tail -f /var/log/syslog ... Jan 22 12:50:33 bionic-kernel systemd[1]: Assertion 'xsprintf: buf[] must be big enough' failed at ../src/core/job.c:803, function job_log_status_message(). Aborting. Broadcast message from systemd-journald@bionic-kernel (Wed 2020-01-22 12:50:33 UTC): systemd[1]: Caught , dumped core as pid 14620. Broadcast message from systemd-journald@bionic-kernel (Wed 2020-01-22 12:50:33 UTC): systemd[1]: Freezing execution. Jan 22 12:50:33 bionic-kernel systemd[1]: Caught , dumped core as pid 14620. Jan 22 12:50:33 bionic-kernel systemd[1]: Freezing execution. [Regression Potential] The patches replace xsprintf with snprintf and the regression potential is small. [Other] Only Bionic is affected. [1] https://github.com/systemd/systemd/issues/4534 [2]
[Touch-packages] [Bug 1860548] [NEW] systemd crashes when logging long message
Public bug reported: [Description] Systemd crashes when logging very long messages. This regression was introduced with upstream commit d054f0a4d451 [1] due to xsprintf. Commits e68eedbbdc98 [2] and 574432f889ce [3] replace some uses of xsprintf with snprintf and fix it. [Test Case] # systemd-run --scope apt-get -q -y -o DPkg::Options::=--force-confold -o DPkg::Options::=--force-confdef --allow-unauthenticated install acl adduser amd64-microcode apt base-files base-passwd bash bash-completion bind9-host binfmt-support binutils-common binutils-x86-64-linux-gnu bsdmainutils bsdutils busybox-initramfs busybox-static bzip2 ca- certificates console-setup console-setup-linux coreutils cpio cpp cpp-7 crda cron curl dash dbus dctrl-tools debconf debconf-i18n debianutils dictionaries-common diffutils dirmngr distro-info-data dmeventd dmsetup dnsmasq-base dnsutils dpkg e2fslibs e2fsprogs ed eject fakeroot fdisk file findutils friendly-recovery gawk gcc-7-base gcc-8-base gettext-base gir1.2-glib-2.0 gnupg gnupg-l10n gnupg-utils gpg gpg-agent gpg-wks- client gpg-wks-server gpgconf gpgsm gpgv grep groff-base grub-common grub-pc grub-pc-bin grub2-common gzip hostname info init init-system- helpers initramfs-tools initramfs-tools-bin initramfs-tools-core install-info intel-microcode iproute2 iptables iputils-ping iputils- tracepath irqbalance isc-dhcp-client isc-dhcp-common iso-codes iw keyboard-configuration keyutils klibc-utils kmod krb5-locales krb5-user language-pack-en language-pack-en-base language-pack-gnome-en language- pack-gnome-en-base less libaccountsservice0 libacl1 libapparmor1 libargon2-0 libasan4 libasn1-8-heimdal libassuan0 libatm1 libatomic1 libattr1 libaudit-common libaudit1 libbinutils libblkid1 libbsd0 libbz2-1.0 libc-bin libc-dev-bin libc6 libc6-dev libcap-ng0 libcap2 libcap2-bin libcc1-0 libcilkrts5 libcom-err2 libcryptsetup12 libcurl3-gnutls libcurl4 libdb5.3 libdbus-1-3 libdebconfclient0 libdevmapper-event1.02.1 libdevmapper1.02.1 libdpkg-perl libdrm-common libdrm2 libdumbnet1 libedit2 libelf1 libestr0 libevent-2.1-6 libexpat1 libexpat1-dev libext2fs2 libfakeroot libfastjson4 libfdisk1 libffi6 libfreetype6 libfribidi0 libfuse2 libgc1c2 libgcc-7-dev libgcc1 libgcrypt20 libgdbm-compat4 libgeoip1 libgirepository-1.0-1 libglib2.0-0 libglib2.0-data libgmp10 libgnutls30 libgomp1 libgpg-error0 libgpm2 libgssapi-krb5-2 libgssapi3-heimdal libgssrpc4 libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal libhogweed4 libhx509-5-heimdal libitm1 libjs-jquery libjs-sphinxdoc libjs-underscore libk5crypto3 libkadm5clnt-mit11 libkadm5srv-mit11 libkdb5-9 libkeyutils1 libkmod2 libkrb5-26-heimdal libkrb5-3 libkrb5support0 libksba8 libldap-2.4-2 libldap-common liblocale-gettext-perl liblsan0 liblz4-1 liblzma5 libmagic-mgc libmagic1 libmnl0 libmount1 libmpc3 libmpdec2 libmpfr6 libmpx2 libmspack0 libncurses5 libncursesw5 libnetfilter-conntrack3 libnettle6 libnewt0.52 libnfnetlink0 libnfsidmap2 libnghttp2-14 libnl-3-200 libnl-genl-3-200 libnorm1 libnpth0 libnss-systemd libnuma1 libp11-kit0 libpam-cap libpam-krb5 libpam-modules libpam-modules-bin libpam-runtime libpam-systemd libpam0g libparted2 libpcap0.8 libpci3 libpcre3 libpgm-5.2-0 libpipeline1 libplymouth4 libpng16-16 libpolkit- gobject-1-0 libpopt0 libpsl5 libpython-all-dev libpython-dev libpython- stdlib libpython2.7 libpython2.7-dev libpython2.7-minimal # tail -f /var/log/syslog ... Jan 22 12:50:33 bionic-kernel systemd[1]: Assertion 'xsprintf: buf[] must be big enough' failed at ../src/core/job.c:803, function job_log_status_message(). Aborting. Broadcast message from systemd-journald@bionic-kernel (Wed 2020-01-22 12:50:33 UTC): systemd[1]: Caught , dumped core as pid 14620. Broadcast message from systemd-journald@bionic-kernel (Wed 2020-01-22 12:50:33 UTC): systemd[1]: Freezing execution. Jan 22 12:50:33 bionic-kernel systemd[1]: Caught , dumped core as pid 14620. Jan 22 12:50:33 bionic-kernel systemd[1]: Freezing execution. [Regression Potential] The patches replace xsprintf with snprintf and the regression potential is small. [Other] Only Bionic is affected. [1] https://github.com/systemd/systemd/issues/4534 [2] https://github.com/systemd/systemd/commit/e68eedbbdc98fa13449756b7fee3bed689d76493 [3] https://github.com/systemd/systemd/commit/574432f889ce3de126bbc6736bcbd22ee170ff82 ** Affects: systemd (Ubuntu) Importance: Medium Assignee: Ioanna Alifieraki (joalif) Status: Confirmed ** Affects: systemd (Ubuntu Bionic) Importance: Medium Assignee: Ioanna Alifieraki (joalif) Status: Confirmed ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Bionic) Status: New => Confirmed ** Changed in: systemd (Ubuntu) Status: New => Confirmed ** Changed in: systemd (Ubuntu) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: sys
[Touch-packages] [Bug 1841058] Re: kernel version 4.4.0-1090-aws docker file system issue
*** This bug is a duplicate of bug 1851243 *** https://bugs.launchpad.net/bugs/1851243 ** This bug has been marked a duplicate of bug 1851243 overlayfs : broken access to r/w files -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to sed in Ubuntu. https://bugs.launchpad.net/bugs/1841058 Title: kernel version 4.4.0-1090-aws docker file system issue Status in linux-aws package in Ubuntu: New Status in sed package in Ubuntu: New Bug description: When using kernel version 4.4.0-1090-aws if you have running container and you do sed on some files then you cannot access them inside the container any more we use the nginx image and we can reproduce it everytime in the container we have chown and then sed commands on some nginx.conf files after the sed we are getting persmission denied inside the container even that we use root. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux-aws/+bug/1841058/+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 1591411] Re: systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25 second delay
@Nick What symptoms do you observe? Delays when ssh? Could you please share your reproducer or describe in which circumstances you hit the bug? Do you see any leaking scopes "ls -ld /run/systemd/transient/session-*.scope*" ? Lastly what version of systemd do you run? Thanks. -- 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 second delay Status in D-Bus: Fix Released Status in systemd: Fix Released Status in dbus package in Ubuntu: Fix Released Status in systemd package in Ubuntu: Fix Released Status in dbus source package in Xenial: Fix Released Status in systemd source package in Xenial: Invalid Status in dbus source package in Yakkety: Won't Fix Status in systemd source package in Yakkety: Invalid Bug description: [Impact] The bug affects multiple users and introduces an user visible delay (~25 seconds) on SSH connections after a large number of sessions have been processed. This has a serious impact on big systems and servers running our software. The currently proposed fix is actually a safe workaround for the bug as proposed by the dbus upstream. The workaround makes uid 0 immune to the pending_fd_timeout limit that kicks in and causes the original issue. [Test Case] lxc launch ubuntu:x test lxc exec test -- login -f ubuntu ssh-import-id Then ran a script as follows (passing in ubuntu@): while [ 1 ]; do (time ssh $1 "echo OK > /dev/null") 2>&1 | grep ^real >> log done Then checking the log file if there are any ssh sessions that are taking 25+ seconds to complete. Multiple instances of the same script can be used at the same time. [Regression Potential] The fix has a rather low regression potential as the workaround is a very small change only affecting one particular case - handling of uid 0. The fix has been tested by multiple users and has been around in zesty for a while, with multiple people involved in reviewing the change. It's also a change that has been proposed by upstream. [Original Description] I noticed on a system that accepts large numbers of SSH connections that after awhile, SSH sessions were taking ~25 seconds to complete. Looking in /var/log/auth.log, systemd-logind starts failing with the following: Jun 10 23:55:28 test sshd[3666]: pam_unix(sshd:session): session opened for user ubuntu by (uid=0) Jun 10 23:55:28 test systemd-logind[105]: New session c1052 of user ubuntu. Jun 10 23:55:28 test systemd-logind[105]: Failed to abandon session scope: Transport endpoint is not connected Jun 10 23:55:28 test sshd[3666]: pam_systemd(sshd:session): Failed to create session: Message recipient disconnected from message bus without replying I reproduced this in an LXD container by doing something like: lxc launch ubuntu:x test lxc exec test -- login -f ubuntu ssh-import-id Then ran a script as follows (passing in ubuntu@): while [ 1 ]; do (time ssh $1 "echo OK > /dev/null") 2>&1 | grep ^real >> log done In my case, after 1052 logins, the 1053rd and thereafter were taking 25+ seconds to complete. Here are some snippets from the log file: $ cat log | grep 0m0 | wc -l 1052 $ cat log | grep 0m25 | wc -l 4 $ tail -5 log real 0m0.222s real 0m25.232s real 0m25.235s real 0m25.236s real 0m25.239s ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: systemd 229-4ubuntu5 ProcVersionSignature: Ubuntu 4.4.0-22.40-generic 4.4.8 Uname: Linux 4.4.0-22-generic x86_64 ApportVersion: 2.20.1-0ubuntu2 Architecture: amd64 Date: Sat Jun 11 00:09:34 2016 MachineType: Notebook W230SS ProcEnviron: TERM=xterm-256color PATH=(custom, no user) ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-22-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/systemd-timesyncd.service → /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf 2 overridden configuration files found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 04/15/2014 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: 4.6.5 dmi.board.asset.tag: Tag 12345 dmi.board.name: W230SS dmi.board.vendor: Notebook dmi.board.version: Not Applicable dmi.chassis.asset.tag: No Asset Tag dmi.chassis.type: 9 dmi.chassis.vendor: Notebook dmi.chassis.version: N/A dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr4.6.5:bd04/15/2014:svnNotebook:pnW230SS:pvrNotApplicable:rvnNotebook:rnW230SS:rvrNotApplicable:cvnNotebook:ct9:cvrN/A: dmi.product.name: W230SS dmi.product.version: Not Applicable
[Touch-packages] [Bug 1828892] Re: systemctl - alias service reports inactive while aliased is active
Verification on Xenial. Repeating test case from description. - Test case 1 - libvirtd alias service : libvirtd aliased service : libvirt-bin # ls -la libvirtd.service lrwxrwxrwx 1 root root 39 Mar 21 16:27 libvirtd.service -> /lib/systemd/system/libvirt-bin.service # systemctl is-active libvirtd active # systemctl is-active libvirt-bin active - Test case 2 - sshd alias service : sshd aliased service : ssh # ls -la sshd.service lrwxrwxrwx 1 root root 31 Mar 21 14:39 sshd.service -> /lib/systemd/system/ssh.service # systemctl is-active sshd active # systemctl is-active ssh active # dpkg -l | grep systemd ii libpam-systemd:amd64 229-4ubuntu21.22 amd64system and service manager - PAM module ii libsystemd0:amd64229-4ubuntu21.22 amd64systemd utility library ii systemd 229-4ubuntu21.22 amd64system and service manager ii systemd-sysv 229-4ubuntu21.22 amd64system and service manager - SysV links ** 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/1828892 Title: systemctl - alias service reports inactive while aliased is active Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Fix Committed Bug description: [Impact] 'systemctl is-active' command reports an alias service as inactive even though the aliased service is active. Currently the 'systemctl is-active' command does not load units to minimise its effect on the system (i.e. that a monitoring command does not itself alter the state of the system). However, this behaviour leads to inconsistencies when services are aliased. [Test case] - Test case 1 - libvirtd alias service : libvirtd aliased service : libvirt-bin /etc/systemd/system$ ls -la libvirtd.service lrwxrwxrwx 1 root root 39 May 13 20:49 libvirtd.service -> /lib/systemd/system/libvirt-bin.service $ systemctl is-active libvirtd inactive $ systemctl is-active libvirt-bin active - Test case 2 - sshd alias service : sshd aliased service : ssh /ect/systemd/system$ ls -la sshd.service lrwxrwxrwx 1 root root 31 Mar 19 19:44 sshd.service -> /lib/systemd/system/ssh.service $ systemctl is-active sshd inactive $ systemctl is-active ssh active [Regression Potential] This fix may result into systemctl reporting inconsistent information concerning the status of a service. [Other] Upstream issue : https://github.com/systemd/systemd/issues/7875 Upstream fix : https://github.com/systemd/systemd/pull/7997 Xenial is affected, fix exists on Bionic onward. $ lsb_release -rd Description: Ubuntu 16.04.6 LTS Release: 16.04 $ apt-cache policy systemd systemd: Installed: 229-4ubuntu21.21 Candidate: 229-4ubuntu21.21 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1828892/+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 1650740] Re: dhclient depends on fstab 16.04LTS
*** This bug is a duplicate of bug 1632405 *** https://bugs.launchpad.net/bugs/1632405 ** This bug has been marked a duplicate of bug 1632405 virt-customize enters infinite loop: dhclient-script: cannot open /etc/fstab -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu. https://bugs.launchpad.net/bugs/1650740 Title: dhclient depends on fstab 16.04LTS Status in isc-dhcp package in Ubuntu: Confirmed Bug description: As noted here: https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1632405 dhclient-script attempts to read fstab and if not available is unable to continue; while a workaround has been provided in the upstream for the dependent (and fairly critical) package, which will hopefully make it into the 16.04 repos soon, the bug does seem to be in dhclient- script, and presumably is easily fixable. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1650740/+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 1828892] Re: systemctl - alias service reports inactive while aliased is active
@ddstreet There is no need to include the manpage correction (commit 71c9f49d730c8e) since it reverts commit c7612b2 which does not exist in xenial systemd. Initially issue #7875 was classified as feature request and not as a bug. Upstream added modified the manpage (https://github.com/systemd/systemd/commit/c7612b20052d9151f60a96623b8743cbac88390d) to clarify that 'is-active' command does not load units and therefore explain why an alias unit is reported inactive while the aliased is reported active. Later, when they realised it is a bug and fixed it they reverted c7612b2 with 71c9f49d730c8e. -- 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/1828892 Title: systemctl - alias service reports inactive while aliased is active Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Bug description: [Impact] 'systemctl is-active' command reports an alias service as inactive even though the aliased service is active. Currently the 'systemctl is-active' command does not load units to minimise its effect on the system (i.e. that a monitoring command does not itself alter the state of the system). However, this behaviour leads to inconsistencies when services are aliased. [Test case] - Test case 1 - libvirtd alias service : libvirtd aliased service : libvirt-bin /etc/systemd/system$ ls -la libvirtd.service lrwxrwxrwx 1 root root 39 May 13 20:49 libvirtd.service -> /lib/systemd/system/libvirt-bin.service $ systemctl is-active libvirtd inactive $ systemctl is-active libvirt-bin active - Test case 2 - sshd alias service : sshd aliased service : ssh /ect/systemd/system$ ls -la sshd.service lrwxrwxrwx 1 root root 31 Mar 19 19:44 sshd.service -> /lib/systemd/system/ssh.service $ systemctl is-active sshd inactive $ systemctl is-active ssh active [Regression Potential] This fix may result into systemctl reporting inconsistent information concerning the status of a service. [Other] Upstream issue : https://github.com/systemd/systemd/issues/7875 Upstream fix : https://github.com/systemd/systemd/pull/7997 Xenial is affected, fix exists on Bionic onward. $ lsb_release -rd Description: Ubuntu 16.04.6 LTS Release: 16.04 $ apt-cache policy systemd systemd: Installed: 229-4ubuntu21.21 Candidate: 229-4ubuntu21.21 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1828892/+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 1828892] Re: systemctl - alias service reports inactive while aliased is active
Debdiff for Xenial. ** Patch added: "lp1828892_xenial.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1828892/+attachment/5264308/+files/lp1828892_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/1828892 Title: systemctl - alias service reports inactive while aliased is active Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Bug description: [Impact] 'systemctl is-active' command reports an alias service as inactive even though the aliased service is active. Currently the 'systemctl is-active' command does not load units to minimise its effect on the system (i.e. that a monitoring command does not itself alter the state of the system). However, this behaviour leads to inconsistencies when services are aliased. [Test case] - Test case 1 - libvirtd alias service : libvirtd aliased service : libvirt-bin /etc/systemd/system$ ls -la libvirtd.service lrwxrwxrwx 1 root root 39 May 13 20:49 libvirtd.service -> /lib/systemd/system/libvirt-bin.service $ systemctl is-active libvirtd inactive $ systemctl is-active libvirt-bin active - Test case 2 - sshd alias service : sshd aliased service : ssh /ect/systemd/system$ ls -la sshd.service lrwxrwxrwx 1 root root 31 Mar 19 19:44 sshd.service -> /lib/systemd/system/ssh.service $ systemctl is-active sshd inactive $ systemctl is-active ssh active [Regression Potential] This fix may result into systemctl reporting inconsistent information concerning the status of a service. [Other] Upstream issue : https://github.com/systemd/systemd/issues/7875 Upstream fix : https://github.com/systemd/systemd/pull/7997 Xenial is affected, fix exists on Bionic onward. $ lsb_release -rd Description: Ubuntu 16.04.6 LTS Release: 16.04 $ apt-cache policy systemd systemd: Installed: 229-4ubuntu21.21 Candidate: 229-4ubuntu21.21 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1828892/+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 1828892] Re: systemctl - alias service reports inactive while aliased is active
** Changed in: systemd (Ubuntu) Status: Confirmed => In Progress ** Changed in: systemd (Ubuntu Xenial) 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/1828892 Title: systemctl - alias service reports inactive while aliased is active Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Bug description: [Impact] 'systemctl is-active' command reports an alias service as inactive even though the aliased service is active. Currently the 'systemctl is-active' command does not load units to minimise its effect on the system (i.e. that a monitoring command does not itself alter the state of the system). However, this behaviour leads to inconsistencies when services are aliased. [Test case] - Test case 1 - libvirtd alias service : libvirtd aliased service : libvirt-bin /etc/systemd/system$ ls -la libvirtd.service lrwxrwxrwx 1 root root 39 May 13 20:49 libvirtd.service -> /lib/systemd/system/libvirt-bin.service $ systemctl is-active libvirtd inactive $ systemctl is-active libvirt-bin active - Test case 2 - sshd alias service : sshd aliased service : ssh /ect/systemd/system$ ls -la sshd.service lrwxrwxrwx 1 root root 31 Mar 19 19:44 sshd.service -> /lib/systemd/system/ssh.service $ systemctl is-active sshd inactive $ systemctl is-active ssh active [Regression Potential] This fix may result into systemctl reporting inconsistent information concerning the status of a service. [Other] Upstream issue : https://github.com/systemd/systemd/issues/7875 Upstream fix : https://github.com/systemd/systemd/pull/7997 Xenial is affected, fix exists on Bionic onward. $ lsb_release -rd Description: Ubuntu 16.04.6 LTS Release: 16.04 $ apt-cache policy systemd systemd: Installed: 229-4ubuntu21.21 Candidate: 229-4ubuntu21.21 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1828892/+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 1806012] Re: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server
Just opened a MP against systemd to make the 'ondemand' service configurable through /etc/default/cpufrequtils file. This change has two purposes : 1) Make 'onedmand' service configurable. It is important for the 'ondemand' service to be configurable because depending on the use case and the the CPU model, 'ondemand' may not select the optimal governor for the user's needs. 2) Fix an existing bug when cpufrequtils installed. In case cpufrequtils is installed and user has chosen a different governor (by editing the /etc/default/cpufrequtils file) than the one selected by ondemand service, the ondemand service will overwrite user's settings and stick to its selection. With this change the ondemand service will first check if the /etc/default/cpufrequtils files exist and in case there is a governor defined, the ondemand service will select the defined governor. In case there is no such file, ondemand service will behave as it does currently. The /etc/default/cpufrequtils file is chosen on purpose to provide compatibility between ondemand service and cpufrequtils package. -- 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/1806012 Title: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: Whilst debugging 'slow instance performance' on a Ubuntu Bionic based cloud, I observed that the default cpu governor configuration was set to 'powersave'; toggling this to 'performance' (while in not anyway a particularly green thing todo) resulted in the instance slowness disappearing and the cloud performance being as expected (based on a prior version of the deploy on Ubuntu Xenial). AFAICT Xenial does the same thing albeit in a slight different way, but we definitely did not see the same performance laggy-ness under a Xenial based cloud. Raising against systemd (as this package sets the governor to 'powersave') - I feel that the switch to 'performance' although appropriate then obscures what might be a performance/behavioural difference in the underlying kernel when a machine is under load. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.9 ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18 Uname: Linux 4.15.0-39-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 Date: Fri Nov 30 10:05:46 2018 Lsusb: Bus 002 Device 002: ID 8087:8002 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 413c:a001 Dell Computer Corp. Hub Bus 001 Device 002: ID 8087:800a Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. PowerEdge R630 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-39-generic root=UUID=a361a524-47eb-46c3-8a04-e5eaa65188c9 ro hugepages=103117 iommu=pt intel_iommu=on SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/08/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 2.3.4 dmi.board.name: 02C2CP dmi.board.vendor: Dell Inc. dmi.board.version: A03 dmi.chassis.type: 23 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr2.3.4:bd11/08/2016:svnDellInc.:pnPowerEdgeR630:pvr:rvnDellInc.:rn02C2CP:rvrA03:cvnDellInc.:ct23:cvr: dmi.product.name: PowerEdge R630 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1806012/+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 1806012] Re: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server
** Merge proposal linked: https://code.launchpad.net/~joalif/ubuntu/+source/systemd/+git/systemd/+merge/367469 -- 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/1806012 Title: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: Whilst debugging 'slow instance performance' on a Ubuntu Bionic based cloud, I observed that the default cpu governor configuration was set to 'powersave'; toggling this to 'performance' (while in not anyway a particularly green thing todo) resulted in the instance slowness disappearing and the cloud performance being as expected (based on a prior version of the deploy on Ubuntu Xenial). AFAICT Xenial does the same thing albeit in a slight different way, but we definitely did not see the same performance laggy-ness under a Xenial based cloud. Raising against systemd (as this package sets the governor to 'powersave') - I feel that the switch to 'performance' although appropriate then obscures what might be a performance/behavioural difference in the underlying kernel when a machine is under load. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.9 ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18 Uname: Linux 4.15.0-39-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 Date: Fri Nov 30 10:05:46 2018 Lsusb: Bus 002 Device 002: ID 8087:8002 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 413c:a001 Dell Computer Corp. Hub Bus 001 Device 002: ID 8087:800a Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. PowerEdge R630 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-39-generic root=UUID=a361a524-47eb-46c3-8a04-e5eaa65188c9 ro hugepages=103117 iommu=pt intel_iommu=on SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/08/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 2.3.4 dmi.board.name: 02C2CP dmi.board.vendor: Dell Inc. dmi.board.version: A03 dmi.chassis.type: 23 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr2.3.4:bd11/08/2016:svnDellInc.:pnPowerEdgeR630:pvr:rvnDellInc.:rn02C2CP:rvrA03:cvnDellInc.:ct23:cvr: dmi.product.name: PowerEdge R630 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1806012/+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 1828892] [NEW] systemctl - alias service reports inactive while aliased is active
Public bug reported: [Impact] 'systemctl is-active' command reports an alias service as inactive even though the aliased service is active. Currently the 'systemctl is-active' command does not load units to minimise its effect on the system (i.e. that a monitoring command does not itself alter the state of the system). However, this behaviour leads to inconsistencies when services are aliased. [Test case] - Test case 1 - libvirtd alias service : libvirtd aliased service : libvirt-bin /etc/systemd/system$ ls -la libvirtd.service lrwxrwxrwx 1 root root 39 May 13 20:49 libvirtd.service -> /lib/systemd/system/libvirt-bin.service $ systemctl is-active libvirtd inactive $ systemctl is-active libvirt-bin active - Test case 2 - sshd alias service : sshd aliased service : ssh /ect/systemd/system$ ls -la sshd.service lrwxrwxrwx 1 root root 31 Mar 19 19:44 sshd.service -> /lib/systemd/system/ssh.service $ systemctl is-active sshd inactive $ systemctl is-active ssh active [Regression Potential] This fix may result into systemctl reporting inconsistent information concerning the status of a service. [Other] Upstream issue : https://github.com/systemd/systemd/issues/7875 Upstream fix : https://github.com/systemd/systemd/pull/7997 Xenial is affected, fix exists on Bionic onward. $ lsb_release -rd Description:Ubuntu 16.04.6 LTS Release:16.04 $ apt-cache policy systemd systemd: Installed: 229-4ubuntu21.21 Candidate: 229-4ubuntu21.21 ** Affects: systemd (Ubuntu) Importance: Medium Assignee: Ioanna Alifieraki (joalif) Status: Confirmed ** Affects: systemd (Ubuntu Xenial) Importance: Medium Assignee: Ioanna Alifieraki (joalif) Status: Confirmed ** Tags: sts ** Changed in: systemd (Ubuntu) Status: New => Confirmed ** Changed in: systemd (Ubuntu) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Xenial) Status: New => Confirmed ** Changed in: systemd (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Xenial) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Tags added: sts -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1828892 Title: systemctl - alias service reports inactive while aliased is active Status in systemd package in Ubuntu: Confirmed Status in systemd source package in Xenial: Confirmed Bug description: [Impact] 'systemctl is-active' command reports an alias service as inactive even though the aliased service is active. Currently the 'systemctl is-active' command does not load units to minimise its effect on the system (i.e. that a monitoring command does not itself alter the state of the system). However, this behaviour leads to inconsistencies when services are aliased. [Test case] - Test case 1 - libvirtd alias service : libvirtd aliased service : libvirt-bin /etc/systemd/system$ ls -la libvirtd.service lrwxrwxrwx 1 root root 39 May 13 20:49 libvirtd.service -> /lib/systemd/system/libvirt-bin.service $ systemctl is-active libvirtd inactive $ systemctl is-active libvirt-bin active - Test case 2 - sshd alias service : sshd aliased service : ssh /ect/systemd/system$ ls -la sshd.service lrwxrwxrwx 1 root root 31 Mar 19 19:44 sshd.service -> /lib/systemd/system/ssh.service $ systemctl is-active sshd inactive $ systemctl is-active ssh active [Regression Potential] This fix may result into systemctl reporting inconsistent information concerning the status of a service. [Other] Upstream issue : https://github.com/systemd/systemd/issues/7875 Upstream fix : https://github.com/systemd/systemd/pull/7997 Xenial is affected, fix exists on Bionic onward. $ lsb_release -rd Description: Ubuntu 16.04.6 LTS Release: 16.04 $ apt-cache policy systemd systemd: Installed: 229-4ubuntu21.21 Candidate: 229-4ubuntu21.21 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1828892/+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 1818282] Re: systemd-networkd - RoutingPolicyRule does not apply correctly
VERIFICATION Cosmic - Using configuration file from description $ dpkg -l | grep systemd ii systemd 239-7ubuntu10.12 amd64system and service manager $ ip rule 0: from all lookup local 0: from 172.31.24.153 lookup 1000 0: from 172.31.28.195 lookup 1000 32766: from all lookup main 32767: from all lookup default -- Install systemd from -proposed $ dpkg -l | grep systemd ii systemd 239-7ubuntu10.13 amd64system and service manager $ ip rule 0: from all lookup local 0: from 172.31.24.153 lookup 1000 0: from 172.31.24.152 lookup 1000 0: from 172.31.28.195 lookup 1000 0: from 172.31.24.151 lookup 1000 32766: from all lookup main 32767: from all lookup default $ sudo systemctl restart systemd-networkd $ ip rule 0: from all lookup local 0: from 172.31.24.153 lookup 1000 0: from 172.31.24.152 lookup 1000 0: from 172.31.28.195 lookup 1000 0: from 172.31.24.151 lookup 1000 32766: from all lookup main 32767: from all lookup default ** 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 systemd in Ubuntu. https://bugs.launchpad.net/bugs/1818282 Title: systemd-networkd - RoutingPolicyRule does not apply correctly Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Fix Committed Status in systemd source package in Disco: Fix Released Status in systemd package in Debian: Fix Committed Bug description: [Impact] When attaching multiple IPs on secondary interface the routing policy rules do not apply for all IPs. The rules that are applied after restarting networkd are random. The issue has been reported and addressed upstream. [Test Case] Attach multiple IPs to secondary interface, config file: $ cat /etc/systemd/network/ens8.network [Match] Name=ens8 [Network] Address=172.31.28.195/20 Address=172.31.24.151/20 Address=172.31.24.152/20 Address=172.31.24.153/20 [Route] Destination=0.0.0.0/0 Gateway=172.31.16.1 Table=1000 [Route] Destination=172.31.24.153 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.28.195 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.151 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.152 Gateway=0.0.0.0 Scope=link Table=1000 [RoutingPolicyRule] From=172.31.24.153 Table=1000 [RoutingPolicyRule] From=172.31.28.195 Table=1000 [RoutingPolicyRule] From=172.31.24.152 Table=1000 [RoutingPolicyRule] From=172.31.24.151 Table=1000 $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart networkd $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.153 lookup 1000 0:from 172.31.28.195 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart again $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.152 lookup 1000 32766:from all lookup main 32767:from all lookup default The behaviour is random [Regression Potential] May impact the systemd-networkd service functionality. [Other] Affects Disco Bionic and Cosmic. Upstream bug : https://github.com/systemd/systemd/issues/11280 Upstream fix : https://github.com/systemd/systemd/pull/11795/commits $ lsb_release -rd Description: Ubuntu Disco Dingo (development branch) Release: 19.04 Systemd version : systemd: Installed: 240-6ubuntu1 Candidate: 240-6ubuntu1 Version table: *** 240-6ubuntu1 500 500 http://gb.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818282/+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 1818282] Re: systemd-networkd - RoutingPolicyRule does not apply correctly
** 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/1818282 Title: systemd-networkd - RoutingPolicyRule does not apply correctly Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Fix Committed Status in systemd source package in Disco: Fix Released Status in systemd package in Debian: Fix Committed Bug description: [Impact] When attaching multiple IPs on secondary interface the routing policy rules do not apply for all IPs. The rules that are applied after restarting networkd are random. The issue has been reported and addressed upstream. [Test Case] Attach multiple IPs to secondary interface, config file: $ cat /etc/systemd/network/ens8.network [Match] Name=ens8 [Network] Address=172.31.28.195/20 Address=172.31.24.151/20 Address=172.31.24.152/20 Address=172.31.24.153/20 [Route] Destination=0.0.0.0/0 Gateway=172.31.16.1 Table=1000 [Route] Destination=172.31.24.153 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.28.195 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.151 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.152 Gateway=0.0.0.0 Scope=link Table=1000 [RoutingPolicyRule] From=172.31.24.153 Table=1000 [RoutingPolicyRule] From=172.31.28.195 Table=1000 [RoutingPolicyRule] From=172.31.24.152 Table=1000 [RoutingPolicyRule] From=172.31.24.151 Table=1000 $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart networkd $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.153 lookup 1000 0:from 172.31.28.195 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart again $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.152 lookup 1000 32766:from all lookup main 32767:from all lookup default The behaviour is random [Regression Potential] May impact the systemd-networkd service functionality. [Other] Affects Disco Bionic and Cosmic. Upstream bug : https://github.com/systemd/systemd/issues/11280 Upstream fix : https://github.com/systemd/systemd/pull/11795/commits $ lsb_release -rd Description: Ubuntu Disco Dingo (development branch) Release: 19.04 Systemd version : systemd: Installed: 240-6ubuntu1 Candidate: 240-6ubuntu1 Version table: *** 240-6ubuntu1 500 500 http://gb.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818282/+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 1818282] Re: systemd-networkd - RoutingPolicyRule does not apply correctly
VERIFICATION Bionic - Using configuration file from description $ dpkg -l | grep systemd ii systemd 237-3ubuntu10.19 amd64system and service manager $ ip rule 0: from all lookup local 0: from 172.31.24.153 lookup 1000 0: from 172.31.28.195 lookup 1000 0: from 172.31.24.151 lookup 1000 32766: from all lookup main 32767: from all lookup default -- Install systemd from -proposed $ dpkg -l | grep systemd ii systemd 237-3ubuntu10.20 amd64system and service manager $ ip rule 0: from all lookup local 0: from 172.31.24.153 lookup 1000 0: from 172.31.28.195 lookup 1000 0: from 172.31.24.151 lookup 1000 0: from 172.31.24.152 lookup 1000 32766: from all lookup main 32767: from all lookup default $ sudo systemctl restart systemd-networkd $ ip rule 0: from all lookup local 0: from 172.31.24.153 lookup 1000 0: from 172.31.28.195 lookup 1000 0: from 172.31.24.152 lookup 1000 0: from 172.31.24.151 lookup 1000 32766: from all lookup main 32767: from all lookup default -- 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/1818282 Title: systemd-networkd - RoutingPolicyRule does not apply correctly Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Cosmic: Fix Committed Status in systemd source package in Disco: Fix Released Status in systemd package in Debian: Fix Committed Bug description: [Impact] When attaching multiple IPs on secondary interface the routing policy rules do not apply for all IPs. The rules that are applied after restarting networkd are random. The issue has been reported and addressed upstream. [Test Case] Attach multiple IPs to secondary interface, config file: $ cat /etc/systemd/network/ens8.network [Match] Name=ens8 [Network] Address=172.31.28.195/20 Address=172.31.24.151/20 Address=172.31.24.152/20 Address=172.31.24.153/20 [Route] Destination=0.0.0.0/0 Gateway=172.31.16.1 Table=1000 [Route] Destination=172.31.24.153 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.28.195 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.151 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.152 Gateway=0.0.0.0 Scope=link Table=1000 [RoutingPolicyRule] From=172.31.24.153 Table=1000 [RoutingPolicyRule] From=172.31.28.195 Table=1000 [RoutingPolicyRule] From=172.31.24.152 Table=1000 [RoutingPolicyRule] From=172.31.24.151 Table=1000 $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart networkd $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.153 lookup 1000 0:from 172.31.28.195 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart again $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.152 lookup 1000 32766:from all lookup main 32767:from all lookup default The behaviour is random [Regression Potential] May impact the systemd-networkd service functionality. [Other] Affects Disco Bionic and Cosmic. Upstream bug : https://github.com/systemd/systemd/issues/11280 Upstream fix : https://github.com/systemd/systemd/pull/11795/commits $ lsb_release -rd Description: Ubuntu Disco Dingo (development branch) Release: 19.04 Systemd version : systemd: Installed: 240-6ubuntu1 Candidate: 240-6ubuntu1 Version table: *** 240-6ubuntu1 500 500 http://gb.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818282/+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 1806012] Re: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server
@james-page What was the the BIOS setting before setting it to "OS control"? Also what do you mean by "we've just stuck with the default ondmand behaviour" ? You mean that you let systemd ondemand service do whatever it does by default or that you use the ondemand governor ? -- 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/1806012 Title: set-cpufreq: 'powersave' governor configuration sanity on ubuntu server Status in systemd package in Ubuntu: In Progress Status in systemd source package in Xenial: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: Whilst debugging 'slow instance performance' on a Ubuntu Bionic based cloud, I observed that the default cpu governor configuration was set to 'powersave'; toggling this to 'performance' (while in not anyway a particularly green thing todo) resulted in the instance slowness disappearing and the cloud performance being as expected (based on a prior version of the deploy on Ubuntu Xenial). AFAICT Xenial does the same thing albeit in a slight different way, but we definitely did not see the same performance laggy-ness under a Xenial based cloud. Raising against systemd (as this package sets the governor to 'powersave') - I feel that the switch to 'performance' although appropriate then obscures what might be a performance/behavioural difference in the underlying kernel when a machine is under load. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.9 ProcVersionSignature: Ubuntu 4.15.0-39.42-generic 4.15.18 Uname: Linux 4.15.0-39-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.5 Architecture: amd64 Date: Fri Nov 30 10:05:46 2018 Lsusb: Bus 002 Device 002: ID 8087:8002 Intel Corp. Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 413c:a001 Dell Computer Corp. Hub Bus 001 Device 002: ID 8087:800a Intel Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. PowerEdge R630 ProcEnviron: TERM=xterm-256color PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.15.0-39-generic root=UUID=a361a524-47eb-46c3-8a04-e5eaa65188c9 ro hugepages=103117 iommu=pt intel_iommu=on SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 11/08/2016 dmi.bios.vendor: Dell Inc. dmi.bios.version: 2.3.4 dmi.board.name: 02C2CP dmi.board.vendor: Dell Inc. dmi.board.version: A03 dmi.chassis.type: 23 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr2.3.4:bd11/08/2016:svnDellInc.:pnPowerEdgeR630:pvr:rvnDellInc.:rn02C2CP:rvrA03:cvnDellInc.:ct23:cvr: dmi.product.name: PowerEdge R630 dmi.sys.vendor: Dell Inc. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1806012/+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 1818282] Re: systemd-networkd - RoutingPolicyRule does not apply correctly
Debdiff for Bionic. ** Patch added: "lp1818282_bionic.debdiff" https://bugs.launchpad.net/ubuntu/bionic/+source/systemd/+bug/1818282/+attachment/5248233/+files/lp1818282_bionic.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/1818282 Title: systemd-networkd - RoutingPolicyRule does not apply correctly Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: Fix Released Status in systemd package in Debian: New Bug description: [Impact] When attaching multiple IPs on secondary interface the routing policy rules do not apply for all IPs. The rules that are applied after restarting networkd are random. The issue has been reported and addressed upstream. [Test Case] Attach multiple IPs to secondary interface, config file: $ cat /etc/systemd/network/ens8.network [Match] Name=ens8 [Network] Address=172.31.28.195/20 Address=172.31.24.151/20 Address=172.31.24.152/20 Address=172.31.24.153/20 [Route] Destination=0.0.0.0/0 Gateway=172.31.16.1 Table=1000 [Route] Destination=172.31.24.153 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.28.195 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.151 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.152 Gateway=0.0.0.0 Scope=link Table=1000 [RoutingPolicyRule] From=172.31.24.153 Table=1000 [RoutingPolicyRule] From=172.31.28.195 Table=1000 [RoutingPolicyRule] From=172.31.24.152 Table=1000 [RoutingPolicyRule] From=172.31.24.151 Table=1000 $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart networkd $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.153 lookup 1000 0:from 172.31.28.195 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart again $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.152 lookup 1000 32766:from all lookup main 32767:from all lookup default The behaviour is random [Regression Potential] May impact the systemd-networkd service functionality. [Other] Affects Disco Bionic and Cosmic. Upstream bug : https://github.com/systemd/systemd/issues/11280 Upstream fix : https://github.com/systemd/systemd/pull/11795/commits $ lsb_release -rd Description: Ubuntu Disco Dingo (development branch) Release: 19.04 Systemd version : systemd: Installed: 240-6ubuntu1 Candidate: 240-6ubuntu1 Version table: *** 240-6ubuntu1 500 500 http://gb.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818282/+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 1818282] Re: systemd-networkd - RoutingPolicyRule does not apply correctly
Debdiff for cosmic. ** Patch added: "lp1818282_cosmic.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818282/+attachment/5247821/+files/lp1818282_cosmic.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/1818282 Title: systemd-networkd - RoutingPolicyRule does not apply correctly Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: Fix Released Status in systemd package in Debian: New Bug description: [Impact] When attaching multiple IPs on secondary interface the routing policy rules do not apply for all IPs. The rules that are applied after restarting networkd are random. The issue has been reported and addressed upstream. [Test Case] Attach multiple IPs to secondary interface, config file: $ cat /etc/systemd/network/ens8.network [Match] Name=ens8 [Network] Address=172.31.28.195/20 Address=172.31.24.151/20 Address=172.31.24.152/20 Address=172.31.24.153/20 [Route] Destination=0.0.0.0/0 Gateway=172.31.16.1 Table=1000 [Route] Destination=172.31.24.153 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.28.195 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.151 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.152 Gateway=0.0.0.0 Scope=link Table=1000 [RoutingPolicyRule] From=172.31.24.153 Table=1000 [RoutingPolicyRule] From=172.31.28.195 Table=1000 [RoutingPolicyRule] From=172.31.24.152 Table=1000 [RoutingPolicyRule] From=172.31.24.151 Table=1000 $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart networkd $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.153 lookup 1000 0:from 172.31.28.195 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart again $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.152 lookup 1000 32766:from all lookup main 32767:from all lookup default The behaviour is random [Regression Potential] May impact the systemd-networkd service functionality. [Other] Affects Disco Bionic and Cosmic. Upstream bug : https://github.com/systemd/systemd/issues/11280 Upstream fix : https://github.com/systemd/systemd/pull/11795/commits $ lsb_release -rd Description: Ubuntu Disco Dingo (development branch) Release: 19.04 Systemd version : systemd: Installed: 240-6ubuntu1 Candidate: 240-6ubuntu1 Version table: *** 240-6ubuntu1 500 500 http://gb.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818282/+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 1818282] Re: systemd-networkd - RoutingPolicyRule does not apply correctly
** Bug watch added: Debian Bug tracker #924406 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924406 ** Also affects: systemd (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=924406 Importance: Unknown Status: Unknown -- 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/1818282 Title: systemd-networkd - RoutingPolicyRule does not apply correctly Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: Fix Committed Status in systemd package in Debian: Unknown Bug description: [Impact] When attaching multiple IPs on secondary interface the routing policy rules do not apply for all IPs. The rules that are applied after restarting networkd are random. The issue has been reported and addressed upstream. [Test Case] Attach multiple IPs to secondary interface, config file: $ cat /etc/systemd/network/ens8.network [Match] Name=ens8 [Network] Address=172.31.28.195/20 Address=172.31.24.151/20 Address=172.31.24.152/20 Address=172.31.24.153/20 [Route] Destination=0.0.0.0/0 Gateway=172.31.16.1 Table=1000 [Route] Destination=172.31.24.153 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.28.195 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.151 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.152 Gateway=0.0.0.0 Scope=link Table=1000 [RoutingPolicyRule] From=172.31.24.153 Table=1000 [RoutingPolicyRule] From=172.31.28.195 Table=1000 [RoutingPolicyRule] From=172.31.24.152 Table=1000 [RoutingPolicyRule] From=172.31.24.151 Table=1000 $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart networkd $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.153 lookup 1000 0:from 172.31.28.195 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart again $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.152 lookup 1000 32766:from all lookup main 32767:from all lookup default The behaviour is random [Regression Potential] May impact the systemd-networkd service functionality. [Other] Affects Disco Bionic and Cosmic. Upstream bug : https://github.com/systemd/systemd/issues/11280 Upstream fix : https://github.com/systemd/systemd/pull/11795/commits $ lsb_release -rd Description: Ubuntu Disco Dingo (development branch) Release: 19.04 Systemd version : systemd: Installed: 240-6ubuntu1 Candidate: 240-6ubuntu1 Version table: *** 240-6ubuntu1 500 500 http://gb.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818282/+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 1818282] Re: systemd-networkd - RoutingPolicyRule does not apply correctly
** Description changed: [Impact] When attaching multiple IPs on secondary interface the routing policy rules do not apply for all IPs. The rules that are applied after restarting networkd are random. The issue has been reported and addressed upstream. [Test Case] Attach multiple IPs to secondary interface, config file: $ cat /etc/systemd/network/ens8.network [Match] Name=ens8 [Network] Address=172.31.28.195/20 Address=172.31.24.151/20 Address=172.31.24.152/20 Address=172.31.24.153/20 [Route] Destination=0.0.0.0/0 Gateway=172.31.16.1 Table=1000 [Route] Destination=172.31.24.153 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.28.195 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.151 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.152 Gateway=0.0.0.0 Scope=link Table=1000 [RoutingPolicyRule] From=172.31.24.153 Table=1000 [RoutingPolicyRule] From=172.31.28.195 Table=1000 [RoutingPolicyRule] From=172.31.24.152 Table=1000 [RoutingPolicyRule] From=172.31.24.151 Table=1000 $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart networkd $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.153 lookup 1000 0:from 172.31.28.195 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart again $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.152 lookup 1000 32766:from all lookup main 32767:from all lookup default The behaviour is random - [Regression Potential] May impact the systemd-networkd service functionality. - [Other] - Affects Disco and Bionic (probably Cosmic as well, but haven't tested it - yet). + Affects Disco Bionic and Cosmic. Upstream bug : https://github.com/systemd/systemd/issues/11280 Upstream fix : https://github.com/systemd/systemd/pull/11795/commits $ lsb_release -rd Description: Ubuntu Disco Dingo (development branch) Release: 19.04 Systemd version : systemd: Installed: 240-6ubuntu1 Candidate: 240-6ubuntu1 Version table: *** 240-6ubuntu1 500 500 http://gb.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status ** Also affects: systemd (Ubuntu Cosmic) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Cosmic) Status: New => In Progress ** Changed in: systemd (Ubuntu Cosmic) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Cosmic) Assignee: (unassigned) => Ioanna Alifieraki (joalif) -- 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/1818282 Title: systemd-networkd - RoutingPolicyRule does not apply correctly Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: [Impact] When attaching multiple IPs on secondary interface the routing policy rules do not apply for all IPs. The rules that are applied after restarting networkd are random. The issue has been reported and addressed upstream. [Test Case] Attach multiple IPs to secondary interface, config file: $ cat /etc/systemd/network/ens8.network [Match] Name=ens8 [Network] Address=172.31.28.195/20 Address=172.31.24.151/20 Address=172.31.24.152/20 Address=172.31.24.153/20 [Route] Destination=0.0.0.0/0 Gateway=172.31.16.1 Table=1000 [Route] Destination=172.31.24.153 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.28.195 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.151 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.152 Gateway=0.0.0.0 Scope=link Table=1000 [RoutingPolicyRule] From=172.31.24.153 Table=1000 [RoutingPolicyRule] From=172.31.28.195 Table=1000 [RoutingPolicyRule] From=172.31.24.152 Table=1000 [RoutingPolicyRule] From=172.31.24.151 Table=1000 $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart networkd $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.153 lo
[Touch-packages] [Bug 1818282] Re: systemd-networkd - RoutingPolicyRule does not apply correctly
** 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/1818282 Title: systemd-networkd - RoutingPolicyRule does not apply correctly Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Disco: In Progress Bug description: [Impact] When attaching multiple IPs on secondary interface the routing policy rules do not apply for all IPs. The rules that are applied after restarting networkd are random. The issue has been reported and addressed upstream. [Test Case] Attach multiple IPs to secondary interface, config file: $ cat /etc/systemd/network/ens8.network [Match] Name=ens8 [Network] Address=172.31.28.195/20 Address=172.31.24.151/20 Address=172.31.24.152/20 Address=172.31.24.153/20 [Route] Destination=0.0.0.0/0 Gateway=172.31.16.1 Table=1000 [Route] Destination=172.31.24.153 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.28.195 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.151 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.152 Gateway=0.0.0.0 Scope=link Table=1000 [RoutingPolicyRule] From=172.31.24.153 Table=1000 [RoutingPolicyRule] From=172.31.28.195 Table=1000 [RoutingPolicyRule] From=172.31.24.152 Table=1000 [RoutingPolicyRule] From=172.31.24.151 Table=1000 $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart networkd $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.153 lookup 1000 0:from 172.31.28.195 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart again $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.152 lookup 1000 32766:from all lookup main 32767:from all lookup default The behaviour is random [Regression Potential] May impact the systemd-networkd service functionality. [Other] Affects Disco and Bionic (probably Cosmic as well, but haven't tested it yet). Upstream bug : https://github.com/systemd/systemd/issues/11280 Upstream fix : https://github.com/systemd/systemd/pull/11795/commits $ lsb_release -rd Description: Ubuntu Disco Dingo (development branch) Release: 19.04 Systemd version : systemd: Installed: 240-6ubuntu1 Candidate: 240-6ubuntu1 Version table: *** 240-6ubuntu1 500 500 http://gb.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818282/+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 1818282] Re: systemd-networkd - RoutingPolicyRule does not apply correctly
debdiff for Disco ** Patch added: "lp1818282_disco.debdiff" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818282/+attachment/5243370/+files/lp1818282_disco.debdiff -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1818282 Title: systemd-networkd - RoutingPolicyRule does not apply correctly Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Disco: In Progress Bug description: [Impact] When attaching multiple IPs on secondary interface the routing policy rules do not apply for all IPs. The rules that are applied after restarting networkd are random. The issue has been reported and addressed upstream. [Test Case] Attach multiple IPs to secondary interface, config file: $ cat /etc/systemd/network/ens8.network [Match] Name=ens8 [Network] Address=172.31.28.195/20 Address=172.31.24.151/20 Address=172.31.24.152/20 Address=172.31.24.153/20 [Route] Destination=0.0.0.0/0 Gateway=172.31.16.1 Table=1000 [Route] Destination=172.31.24.153 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.28.195 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.151 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.152 Gateway=0.0.0.0 Scope=link Table=1000 [RoutingPolicyRule] From=172.31.24.153 Table=1000 [RoutingPolicyRule] From=172.31.28.195 Table=1000 [RoutingPolicyRule] From=172.31.24.152 Table=1000 [RoutingPolicyRule] From=172.31.24.151 Table=1000 $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart networkd $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.153 lookup 1000 0:from 172.31.28.195 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart again $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.152 lookup 1000 32766:from all lookup main 32767:from all lookup default The behaviour is random [Regression Potential] May impact the systemd-networkd service functionality. [Other] Affects Disco and Bionic (probably Cosmic as well, but haven't tested it yet). Upstream bug : https://github.com/systemd/systemd/issues/11280 Upstream fix : https://github.com/systemd/systemd/pull/11795/commits $ lsb_release -rd Description: Ubuntu Disco Dingo (development branch) Release: 19.04 Systemd version : systemd: Installed: 240-6ubuntu1 Candidate: 240-6ubuntu1 Version table: *** 240-6ubuntu1 500 500 http://gb.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818282/+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 1818282] Re: systemd-networkd - RoutingPolicyRule does not apply correctly
** Changed in: systemd (Ubuntu) Status: New => In Progress ** Also affects: systemd (Ubuntu Disco) Importance: Undecided Status: In Progress ** Also affects: systemd (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Bionic) Status: New => In Progress ** Changed in: systemd (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Disco) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Disco) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Changed in: systemd (Ubuntu Bionic) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Tags added: sts ** Description changed: - [Description] + [Impact] When attaching multiple IPs on secondary interface the routing policy rules do not apply for all IPs. The rules that are applied after restarting networkd are random. The issue has been reported and addressed upstream. [Test Case] Attach multiple IPs to secondary interface, config file: - $ cat /etc/systemd/network/ens8.network + $ cat /etc/systemd/network/ens8.network [Match] Name=ens8 [Network] Address=172.31.28.195/20 Address=172.31.24.151/20 Address=172.31.24.152/20 Address=172.31.24.153/20 [Route] Destination=0.0.0.0/0 Gateway=172.31.16.1 Table=1000 [Route] Destination=172.31.24.153 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.28.195 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.151 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.152 Gateway=0.0.0.0 Scope=link Table=1000 [RoutingPolicyRule] From=172.31.24.153 Table=1000 [RoutingPolicyRule] From=172.31.28.195 Table=1000 [RoutingPolicyRule] From=172.31.24.152 Table=1000 [RoutingPolicyRule] From=172.31.24.151 Table=1000 - $ ip rule show - 0:from all lookup local - 0:from 172.31.24.151 lookup 1000 - 32766:from all lookup main - 32767:from all lookup default + 0:from all lookup local + 0:from 172.31.24.151 lookup 1000 + 32766:from all lookup main + 32767:from all lookup default - restart networkd $ sudo systemctl restart systemd-networkd $ ip rule show - 0:from all lookup local - 0:from 172.31.24.151 lookup 1000 - 0:from 172.31.24.153 lookup 1000 - 0:from 172.31.28.195 lookup 1000 - 32766:from all lookup main - 32767:from all lookup default + 0:from all lookup local + 0:from 172.31.24.151 lookup 1000 + 0:from 172.31.24.153 lookup 1000 + 0:from 172.31.28.195 lookup 1000 + 32766:from all lookup main + 32767:from all lookup default - restart again $ sudo systemctl restart systemd-networkd $ ip rule show - 0:from all lookup local - 0:from 172.31.24.151 lookup 1000 - 0:from 172.31.24.152 lookup 1000 - 32766:from all lookup main + 0:from all lookup local + 0:from 172.31.24.151 lookup 1000 + 0:from 172.31.24.152 lookup 1000 + 32766:from all lookup main 32767:from all lookup default The behaviour is random + + + [Regression Potential] + + May impact the systemd-networkd service functionality. + [Other] Affects Disco and Bionic (probably Cosmic as well, but haven't tested it yet). Upstream bug : https://github.com/systemd/systemd/issues/11280 Upstream fix : https://github.com/systemd/systemd/pull/11795/commits - $ lsb_release -rd Description: Ubuntu Disco Dingo (development branch) Release: 19.04 Systemd version : systemd: - Installed: 240-6ubuntu1 - Candidate: 240-6ubuntu1 - Version table: - *** 240-6ubuntu1 500 - 500 http://gb.archive.ubuntu.com/ubuntu disco/main amd64 Packages - 100 /var/lib/dpkg/status + Installed: 240-6ubuntu1 + Candidate: 240-6ubuntu1 + Version table: + *** 240-6ubuntu1 500 + 500 http://gb.archive.ubuntu.com/ubuntu disco/main amd64 Packages + 100 /var/lib/dpkg/status -- 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/1818282 Title: systemd-networkd - RoutingPolicyRule does not apply correctly Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Disco: In Progress Bug description: [Impact] When attaching multiple IPs on secondary interface the routing policy rules do not apply for all IPs. The rules that are applied after restarting networkd are random. The issue has been reported and addressed upstream. [Test Case] Attach multiple IPs to secondary interface, config file: $ cat /etc/systemd/network/ens8.network [Match] Name=ens8 [Network] Addres
[Touch-packages] [Bug 1818282] [NEW] systemd-networkd - RoutingPolicyRule does not apply correctly
Public bug reported: [Description] When attaching multiple IPs on secondary interface the routing policy rules do not apply for all IPs. The rules that are applied after restarting networkd are random. The issue has been reported and addressed upstream. [Test Case] Attach multiple IPs to secondary interface, config file: $ cat /etc/systemd/network/ens8.network [Match] Name=ens8 [Network] Address=172.31.28.195/20 Address=172.31.24.151/20 Address=172.31.24.152/20 Address=172.31.24.153/20 [Route] Destination=0.0.0.0/0 Gateway=172.31.16.1 Table=1000 [Route] Destination=172.31.24.153 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.28.195 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.151 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.152 Gateway=0.0.0.0 Scope=link Table=1000 [RoutingPolicyRule] From=172.31.24.153 Table=1000 [RoutingPolicyRule] From=172.31.28.195 Table=1000 [RoutingPolicyRule] From=172.31.24.152 Table=1000 [RoutingPolicyRule] From=172.31.24.151 Table=1000 $ ip rule show 0: from all lookup local 0: from 172.31.24.151 lookup 1000 32766: from all lookup main 32767: from all lookup default - restart networkd $ sudo systemctl restart systemd-networkd $ ip rule show 0: from all lookup local 0: from 172.31.24.151 lookup 1000 0: from 172.31.24.153 lookup 1000 0: from 172.31.28.195 lookup 1000 32766: from all lookup main 32767: from all lookup default - restart again $ sudo systemctl restart systemd-networkd $ ip rule show 0: from all lookup local 0: from 172.31.24.151 lookup 1000 0: from 172.31.24.152 lookup 1000 32766: from all lookup main 32767: from all lookup default The behaviour is random [Other] Affects Disco and Bionic (probably Cosmic as well, but haven't tested it yet). Upstream bug : https://github.com/systemd/systemd/issues/11280 Upstream fix : https://github.com/systemd/systemd/pull/11795/commits $ lsb_release -rd Description:Ubuntu Disco Dingo (development branch) Release:19.04 Systemd version : systemd: Installed: 240-6ubuntu1 Candidate: 240-6ubuntu1 Version table: *** 240-6ubuntu1 500 500 http://gb.archive.ubuntu.com/ubuntu disco/main amd64 Packages 100 /var/lib/dpkg/status ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- 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/1818282 Title: systemd-networkd - RoutingPolicyRule does not apply correctly Status in systemd package in Ubuntu: New Bug description: [Description] When attaching multiple IPs on secondary interface the routing policy rules do not apply for all IPs. The rules that are applied after restarting networkd are random. The issue has been reported and addressed upstream. [Test Case] Attach multiple IPs to secondary interface, config file: $ cat /etc/systemd/network/ens8.network [Match] Name=ens8 [Network] Address=172.31.28.195/20 Address=172.31.24.151/20 Address=172.31.24.152/20 Address=172.31.24.153/20 [Route] Destination=0.0.0.0/0 Gateway=172.31.16.1 Table=1000 [Route] Destination=172.31.24.153 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.28.195 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.151 Gateway=0.0.0.0 Scope=link Table=1000 [Route] Destination=172.31.24.152 Gateway=0.0.0.0 Scope=link Table=1000 [RoutingPolicyRule] From=172.31.24.153 Table=1000 [RoutingPolicyRule] From=172.31.28.195 Table=1000 [RoutingPolicyRule] From=172.31.24.152 Table=1000 [RoutingPolicyRule] From=172.31.24.151 Table=1000 $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart networkd $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.153 lookup 1000 0:from 172.31.28.195 lookup 1000 32766:from all lookup main 32767:from all lookup default - restart again $ sudo systemctl restart systemd-networkd $ ip rule show 0:from all lookup local 0:from 172.31.24.151 lookup 1000 0:from 172.31.24.152 lookup 1000 32766:from all lookup main 32767:from all lookup default The behaviour is random [Other] Affects Disco and Bionic (probably Cosmic as well, but haven't tested it yet). Upstream bug : https://github.com/systemd/systemd/issues/11280 Upstream fix : https://github.com/systemd/systemd/pull/11795/commits $ lsb_release -rd Description: Ubuntu Disco Dingo (development branch) Release: 19.04 Systemd version :
