[Touch-packages] [Bug 1961833] Re: openssh 8.8 breaks login to Canonical servers
interestingly, paramiko is also broken when connecting to older servers, but not for the same reason as this bug. See bug 1973241 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1961833 Title: openssh 8.8 breaks login to Canonical servers Status in openssh package in Ubuntu: Won't Fix Bug description: With 8.7p1-4 connecting to wendigo debug1: Next authentication method: publickey debug1: Offering public key: /home/jak/.ssh/id_rsa RSA SHA256:Dj1/l9g5RH00/wO7puC1WVxgpvmhmaQg3wEETwmOFPk agent debug1: Server accepts key: /home/jak/.ssh/id_rsa RSA SHA256:Dj1/l9g5RH00/wO7puC1WVxgpvmhmaQg3wEETwmOFPk agent With 8.8p1-1 debug1: Offering public key: /home/jak/.ssh/id_rsa RSA SHA256:Dj1/l9g5RH00/wO7puC1WVxgpvmhmaQg3wEETwmOFPk agent debug1: send_pubkey_test: no mutual signature algorithm Needs further investigation, but blocks people a bit right now To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1961833/+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 1961833] Re: openssh 8.8 breaks login to Canonical servers
For reference to anyone coming here with this problem, when connecting to a remote sshd server you can find what host key algorithms the remote host uses by using -vv and check the debug output; look first for the *peer* server KEXINIT proposal (not the earlier *local client* KEXINIT proposal): debug2: peer server KEXINIT proposal a line or two after that, you should see the list of host key algorithms the remote host is offering; if it contains *only* ssh-rsa then this bug is relevant. debug2: host key algorithms: ssh-rsa Note that by default many systems support multiple algorithms, e.g. you may see: debug2: host key algorithms: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh- ed25519 in this case, even though the remote host does offer ssh-rsa, it also supports other algorithms that jammy does support. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1961833 Title: openssh 8.8 breaks login to Canonical servers Status in openssh package in Ubuntu: Won't Fix Bug description: With 8.7p1-4 connecting to wendigo debug1: Next authentication method: publickey debug1: Offering public key: /home/jak/.ssh/id_rsa RSA SHA256:Dj1/l9g5RH00/wO7puC1WVxgpvmhmaQg3wEETwmOFPk agent debug1: Server accepts key: /home/jak/.ssh/id_rsa RSA SHA256:Dj1/l9g5RH00/wO7puC1WVxgpvmhmaQg3wEETwmOFPk agent With 8.8p1-1 debug1: Offering public key: /home/jak/.ssh/id_rsa RSA SHA256:Dj1/l9g5RH00/wO7puC1WVxgpvmhmaQg3wEETwmOFPk agent debug1: send_pubkey_test: no mutual signature algorithm Needs further investigation, but blocks people a bit right now To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1961833/+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 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest
** Changed in: openssl (Ubuntu) Assignee: Nicolas Bock (nicolasbock) => (unassigned) ** Changed in: openssl (Ubuntu Bionic) Assignee: Nicolas Bock (nicolasbock) => Bruce Elrick (virtuous-sloth) ** Changed in: openssl (Ubuntu Bionic) Status: Fix Committed => In Progress ** Tags removed: verification-needed verification-needed-bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1940141 Title: OpenSSL servers can send a non-empty status_request in a CertificateRequest Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Bionic: In Progress Bug description: [Impact] openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a CertificateRequest message to the client with a non-empty status_request extension. This issue was fixed in openssl-1.1.1d and is included in Focal onward. Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767 Upstream patch review at https://github.com/openssl/openssl/pull/9780 The issue leads to various client failures with TLS 1.3 as described in, e.g. https://github.com/golang/go/issues/35722 https://github.com/golang/go/issues/34040 [Test Plan] The issue can be reproduced by building with `enable-ssl-trace` and then running `s_server` like this: ``` openssl s_server -key key.pem -cert cert.pem -status_file test/recipes/ocsp-response.der -Verify 5 ``` And running `s_client` like this: ``` openssl s_client -status -trace -cert cert.pem -key key.pem ``` The output shows a `status_request` extension in the `CertificateRequest` as follows: Received Record Header: Version = TLS 1.2 (0x303) Content Type = ApplicationData (23) Length = 1591 Inner Content Type = Handshake (22) CertificateRequest, Length=1570 request_context (len=0): extensions, length = 1567 extension_type=status_request(5), length=1521 - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2 0.. 000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01 0.+.0.. 001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86 0...0.. 002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47 0..1.0...UG ...more lines omitted... If the `status_request` extension is present in a `CertificateRequest` then it must be empty according to RFC8446, Sec. 4.4.2.1. [Where problems could occur] The patch disables the `status_request` extension inside a `CertificateRequest`. Applications expecting the incorrect, non-empty reply for the `status_request` extension will break with this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1906331] Re: systemd-resolve crashes fairly often (and reports various assertions)
** Changed in: systemd (Ubuntu) Assignee: Dan Streetman (ddstreet) => (unassigned) ** Changed in: systemd (Ubuntu Hirsute) Assignee: Dan Streetman (ddstreet) => (unassigned) -- 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/1906331 Title: systemd-resolve crashes fairly often (and reports various assertions) Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Incomplete Status in systemd source package in Groovy: Won't Fix Status in systemd source package in Hirsute: Fix Released Bug description: [impact] systemd-resolved crashes [test case] see original description; I can't reproduce so I'm relying on the reporter(s) to test/verify. [regression potential] any regression would likely occur while processing sd_event objects, which are used throughout systemd code; this could result in crashes in almost any part of systemd code. However a more likely regression would be leaks of sd_event objects due to failure to release the final ref for an object. [scope] This is needed for f/g/h This might be fixed by upstream commit f814c871e65df8552a055dd887bc94b074037833; if so, that commit isn't included in any systemd release yet, and so is needed in h and earlier. [other info] I believe this is caused by a freed sd_event object that is then processed and calls the on_query_timeout callback with invalid state, leading to failed assertion, which causes resolved to crash; that's what analysis of the crash dump appears to indicate. This may be fixed by the upstream commit referenced in [scope], which takes additional refs during function calls. However I haven't reproduced this myself, so I'm only guessing as to the cause and solution at this point. I'm unsure why this would not occur in bionic, but per comment 5 it seems it doesn't happen in that release. [original description] (Tested on regularly updated Ubuntu 20.04, currently i use systemd 245.4-4ubuntu3.2) I observe fairly lot of segfaults of systemd-resolve. Frequency vary but … see below. I have no clue what is the reason. Specific feature of my machine is that apart from normal cable connection (to OpenWRT router) I use OpenVPN for business network (and this submits specific nameserver for myorg.local domain). ~ $ LC_ALL=C dmesg -T --level=info | grep systemd-resolve [Sun Nov 29 11:47:37 2020] systemd-resolve[1629307]: segfault at 190eed7bdc6 ip 7fd98f771dc9 sp 7ffc2352a100 error 4 in libsystemd-shared-245.so[7fd98f74c000+16e000] [Sun Nov 29 11:57:27 2020] systemd-resolve[1629787]: segfault at 1f ip 55ab7b0cb686 sp 7fff78ce4bd0 error 4 in systemd-resolved[55ab7b0a4000+3e000] [Sun Nov 29 12:07:37 2020] systemd-resolve[1630481]: segfault at 191 ip 55ca69fed91c sp 7ffc4d757dc0 error 6 in systemd-resolved[55ca69fc2000+3e000] [Sun Nov 29 13:12:26 2020] systemd-resolve[1638829]: segfault at 19224162371 ip 7fc1bc9b9dc9 sp 7ffc21378170 error 4 in libsystemd-shared-245.so[7fc1bc994000+16e000] [Sun Nov 29 13:32:57 2020] systemd-resolve[1639886]: segfault at 1926d8126d3 ip 7f7ed17e9dc9 sp 7ffda2cea0b0 error 4 in libsystemd-shared-245.so[7f7ed17c4000+16e000] [Sun Nov 29 13:42:37 2020] systemd-resolve[1640246]: segfault at 61 ip 558d992e2686 sp 7fff08906af0 error 4 in systemd-resolved[558d992bb000+3e000] [Sun Nov 29 15:42:26 2020] systemd-resolve[1645397]: segfault at 1943c92afc7 ip 7fd4c1721dc9 sp 7fff25259ce0 error 4 in libsystemd-shared-245.so[7fd4c16fc000+16e000] [Sun Nov 29 16:02:36 2020] systemd-resolve[1646052]: segfault at 1947ecb3726 ip 7f1008549dc9 sp 7fff44a6db70 error 4 in libsystemd-shared-245.so[7f1008524000+16e000] [Sun Nov 29 17:42:35 2020] systemd-resolve[1649403]: segfault at 71 ip 55a37fe5a686 sp 7ffd9a160440 error 4 in systemd-resolved[55a37fe33000+3e000] [Sun Nov 29 17:52:35 2020] systemd-resolve[1649759]: segfault at 558d292947d0 ip 558d292947d0 sp 7ffec7ab3bf8 error 15 [Sun Nov 29 19:17:55 2020] systemd-resolve[1652349]: segfault at 558995b77cf0 ip 558995b77cf0 sp 7ffe545ae4a8 error 15 [Sun Nov 29 19:32:35 2020] systemd-resolve[1652640]: segfault at 19773c20194 ip 7f66bb529dc9 sp 7fffd7066fc0 error 4 in libsystemd-shared-245.so[7f66bb504000+16e000] [Sun Nov 29 20:03:54 2020] systemd-resolve[1653715]: segfault at 197e3aee918 ip 7fdc40b51dc9 sp 7ffde484fbf0 error 4 in libsystemd-shared-245.so[7fdc40b2c000+16e000] [Sun Nov 29 20:22:24 2020] systemd-resolve[1654540]: segfault at 19820a05297 ip 7f6a92839dc9 sp 7ffe4ba00440 error 4 in libsystemd-shared-245.so[7f6a92814000+16e000] [Sun Nov 29 21:13:10 2020] systemd-resolve[1660272]: segfault at 555f9a5915e0 ip 555f9a5915e0 sp 7fff053e5e68 error 15
[Touch-packages] [Bug 1928733] Re: Starting systemd Network Service fails with "Invalid argument"
per comment 6, this should be fixed in jammy, so marking fixed released there. ** Changed in: systemd (Ubuntu) Status: Triaged => Fix Released -- 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/1928733 Title: Starting systemd Network Service fails with "Invalid argument" Status in systemd: Unknown Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Bionic: Triaged Status in systemd source package in Focal: Triaged Status in systemd source package in Groovy: Won't Fix Status in systemd source package in Hirsute: Won't Fix Status in systemd source package in Impish: Triaged Bug description: This server has a new install of Ubuntu 18.04 server. Sometimes (around 50% of the time) when it boots systemd-networkd.service initially fails to start with an error as below. It then tries again and succeeds, however other services which depend on systemd-networkd have already failed on the dependency by then. From the output of "journalctl -u systemd-networkd": -- Reboot -- May 17 19:44:28 server1 systemd[1]: Starting Network Service... May 17 19:44:30 server1 systemd[2261]: systemd-networkd.service: Failed to set up mount namespacing: Invalid argument May 17 19:44:30 server1 systemd[2261]: systemd-networkd.service: Failed at step NAMESPACE spawning /lib/systemd/systemd-networkd: Invalid argument May 17 19:44:30 server1 systemd[1]: systemd-networkd.service: Main process exited, code=exited, status=226/NAMESPACE May 17 19:44:30 server1 systemd[1]: systemd-networkd.service: Failed with result 'exit-code'. May 17 19:44:30 server1 systemd[1]: Failed to start Network Service. May 17 19:44:30 server1 systemd[1]: systemd-networkd.service: Service has no hold-off time, scheduling restart. May 17 19:44:30 server1 systemd[1]: systemd-networkd.service: Scheduled restart job, restart counter is at 1. May 17 19:44:30 server1 systemd[1]: Stopped Network Service. May 17 19:44:30 server1 systemd[1]: Starting Network Service... May 17 19:44:30 server1 systemd-networkd[2321]: Enumeration completed May 17 19:44:30 server1 systemd[1]: Started Network Service. May 17 19:44:30 server1 systemd-networkd[2321]: eno2: IPv6 successfully enabled May 17 19:44:30 server1 systemd-networkd[2321]: eno1: Link is not managed by us May 17 19:44:30 server1 systemd-networkd[2321]: enp94s0f0np0: Link is not managed by us May 17 19:44:30 server1 systemd-networkd[2321]: lo: Link is not managed by us May 17 19:44:30 server1 systemd-networkd[2321]: enp94s0f1np1: Link is not managed by us May 17 19:44:30 server1 systemd-networkd[2321]: eno1: IPv6 successfully enabled May 17 19:44:30 server1 systemd-networkd[2321]: enp94s0f0np0: Link is not managed by us May 17 19:44:30 server1 systemd-networkd[2321]: lo: Link is not managed by us May 17 19:44:30 server1 systemd-networkd[2321]: enp94s0f1np1: Link is not managed by us May 17 19:44:31 server1 systemd-networkd[2321]: eno2: Link UP May 17 19:44:31 server1 systemd-networkd[2321]: eno1: Link UP May 17 19:44:34 server1 systemd-networkd[2321]: eno2: Gained carrier May 17 19:44:34 server1 systemd-networkd[2321]: eno1: Gained carrier May 17 19:44:35 server1 systemd-networkd[2321]: eno1: Gained IPv6LL May 17 19:44:35 server1 systemd-networkd[2321]: eno1: Configured May 17 19:44:36 server1 systemd-networkd[2321]: eno2: Gained IPv6LL May 17 19:44:36 server1 systemd-networkd[2321]: eno2: Configured ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: systemd 237-3ubuntu10.46 ProcVersionSignature: Ubuntu 4.15.0-142.146-generic 4.15.18 Uname: Linux 4.15.0-142-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.23 Architecture: amd64 Date: Mon May 17 19:53:11 2021 InstallationDate: Installed on 2021-03-18 (60 days ago) InstallationMedia: Ubuntu-Server 18.04 LTS "Bionic Beaver" - Release amd64 (20180426) Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 004: ID 1604:10c0 Tascam Bus 001 Device 003: ID 1604:10c0 Tascam Bus 001 Device 002: ID 1604:10c0 Tascam Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub MachineType: Dell Inc. PowerEdge R440 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-142-generic root=/dev/mapper/vg1-lv_root ro processor.max_cstate=1 intel_idle.max_cstate=0 transparent_hugepage=never SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 09/23/2020 dmi.bios.vendor: Dell Inc. dmi.bios.version: 2.9.3 dmi.board.name: 04JN2K dmi.board.vendor: Dell Inc. dmi.board.version: A06 dmi.chassis.type: 23 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr2.9.3:bd09/23/2020:svnDellInc.:pnPowerEdgeR440:pvr:rvnDellInc.:rn04JN2K:rvrA06:cvnDellInc.:ct23:cvr: dmi.product.family: PowerEdge
[Touch-packages] [Bug 1939255] Re: dhclient triggers systemd-resolved start limit when processing more than 5 interfaces at once
> It seems this issue may occur not only when receiving addresses on multiple interfaces, but also when dhcp requests on multiple interfaces times out and the hook script was called with 'reason' == FAIL. yep, the try-reload-or-restart is done for those as well and this should be fixed for those $reason cases; since this bug is already resolved, I suggest you open a new bug. -- 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/1939255 Title: dhclient triggers systemd-resolved start limit when processing more than 5 interfaces at once Status in systemd package in Ubuntu: Invalid Status in systemd source package in Bionic: Fix Released Status in systemd source package in Focal: Fix Released Bug description: [impact] on a system where systemd-resolved is running, if dhclient is used on more than 5 interfaces, it calls the '/etc/dhcp/dhclient-enter- hooks.d/resolved' script multiple times, which then restarts systemd- resolved multiple times, triggering the unit's start-limit throttle which results in the unit entering failed state [test case] on a system with more than 5 available interfaces to run dhclient on (where all the interfaces will get a dhcp response), run dhclient with the interfaces: $ dhclient ens8 ens9 ens10 ens11 ens12 ens13 ens14 ens15 check if systemd-resolved failed: $ journalctl -b -1 -u systemd-resolved ... Aug 09 00:38:08 sf316232-b systemd[1]: systemd-resolved.service: Start request repeated too quickly. Aug 09 00:38:08 sf316232-b systemd[1]: systemd-resolved.service: Failed with result 'start-limit-hit'. Aug 09 00:38:08 sf316232-b systemd[1]: Failed to start Network Name Resolution. [regression potential] failure to start/stop/restart systemd-resolved, or problems adding dhclient-provided DNS nameservers to systemd-resolved [scope] this is needed only for b/f the dhclient 'hook' script is provided by the systemd package in focal and earlier, and needs fixing in those releases in h and later, the 'hook' script is included in the isc-dhcp-client package and notifies systemd-resolved in a more direct way without requiring restarting, and so doesn't trigger the restart limiting. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1939255/+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 1966381] Re: applications crash that never crashed under Ubuntu-20.04
> I think you have a problem there too. oh I'm certainly not claiming a 1g default swap is appropriate, that does seem far, far too small to me and will likely cause widespread issues beyond just this, I was only saying that tweaking the systemd- oomd swap % full setting would IMHO not be likely to fix this very well - and as you point out increasing the swap size to a more reasonable size almost certainly will help (and might be why upstream hadn't noticed this before), regardless of the systemd-oomd swap % used default setting, because it would be far less likely to fill swap up to the oomd swap % full default. > Maybe running with such a starved swapspace triggers systemd-oom to do weird things? >From my quick read of the code, it doesn't seem to be doing anything weird at all, I think it's doing exactly what it's programmed to do. I just don't think the code is correct. -- 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/1966381 Title: applications crash that never crashed under Ubuntu-20.04 Status in systemd package in Ubuntu: New Status in systemd source package in Jammy: New Bug description: Just now I was watching some video in Firefox. I popped over to another virtual workspace for a few minutes, and when I popped back to Firefox it had gone. The same thing had been happening all week (I installed fresh Ubuntu-22.04 last week) with Chrome, Firefox and Thunderbird. This time instead of shrugging it off I looked in the logs, and found this Mar 25 19:45:40 ubuntu systemd-oomd[960]: Killed /user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-firefox-6607.scope due to memory used (15940579328) / total (16153944064) and swap used (925564928) / total (1023406080) being more than 90.00% Mar 22 08:11:29 ubuntu systemd[5029]: app-gnome-google\x2dchrome-5412.scope: systemd-oomd killed 298 process(es) in this unit. Mar 23 11:09:28 ubuntu systemd-oomd[1055]: Killed /user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-thunderbird-5418.scope due to memory used (15591993344) / total (16149745664) and swap used (927760384) / total (1023406080) being more than 90.00% Mar 23 11:09:28 ubuntu systemd[5029]: app-gnome-thunderbird-5418.scope: systemd-oomd killed 173 process(es) in this unit. I know it's saying those three entirely unrelated applications had suddenly decided to swallow all the RAM+swap on this laptop of mine - but the very same apps didn't act like that last week under Ubuntu-20.04, so I suspect something else is going on I can't say they hadn't swallowed all the RAM, but there is ZERO sign of a system on the verge of collapsing - everything has been screaming along just nicely - no sign of the "staggering" you normally get when the OS is heavily into swap. However, now that I look I see my 16G laptop only has 1G swap??? I just let the Ubuntu installer do it's defaults - but it used to auto- choose 1xRAM or 2xRAM - what's with this 1G swap? Could that be related? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: systemd-oomd 249.11-0ubuntu1 ProcVersionSignature: Ubuntu 5.15.0-23.23-generic 5.15.27 Uname: Linux 5.15.0-23-generic x86_64 ApportVersion: 2.20.11-0ubuntu79 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Mar 25 19:47:44 2022 InstallationDate: Installed on 2022-03-13 (11 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20220313) SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1966381/+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 1966381] Re: applications crash that never crashed under Ubuntu-20.04
> it's going to be hard to get around the core issue of oomd counting pagecache as memory pressure assuming my quick 10-minute assessment of this bug is correct, of course...maybe i'm totally wrong about what the problem is ;-) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1966381 Title: applications crash that never crashed under Ubuntu-20.04 Status in systemd package in Ubuntu: New Status in systemd source package in Jammy: New Bug description: Just now I was watching some video in Firefox. I popped over to another virtual workspace for a few minutes, and when I popped back to Firefox it had gone. The same thing had been happening all week (I installed fresh Ubuntu-22.04 last week) with Chrome, Firefox and Thunderbird. This time instead of shrugging it off I looked in the logs, and found this Mar 25 19:45:40 ubuntu systemd-oomd[960]: Killed /user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-firefox-6607.scope due to memory used (15940579328) / total (16153944064) and swap used (925564928) / total (1023406080) being more than 90.00% Mar 22 08:11:29 ubuntu systemd[5029]: app-gnome-google\x2dchrome-5412.scope: systemd-oomd killed 298 process(es) in this unit. Mar 23 11:09:28 ubuntu systemd-oomd[1055]: Killed /user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-thunderbird-5418.scope due to memory used (15591993344) / total (16149745664) and swap used (927760384) / total (1023406080) being more than 90.00% Mar 23 11:09:28 ubuntu systemd[5029]: app-gnome-thunderbird-5418.scope: systemd-oomd killed 173 process(es) in this unit. I know it's saying those three entirely unrelated applications had suddenly decided to swallow all the RAM+swap on this laptop of mine - but the very same apps didn't act like that last week under Ubuntu-20.04, so I suspect something else is going on I can't say they hadn't swallowed all the RAM, but there is ZERO sign of a system on the verge of collapsing - everything has been screaming along just nicely - no sign of the "staggering" you normally get when the OS is heavily into swap. However, now that I look I see my 16G laptop only has 1G swap??? I just let the Ubuntu installer do it's defaults - but it used to auto- choose 1xRAM or 2xRAM - what's with this 1G swap? Could that be related? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: systemd-oomd 249.11-0ubuntu1 ProcVersionSignature: Ubuntu 5.15.0-23.23-generic 5.15.27 Uname: Linux 5.15.0-23-generic x86_64 ApportVersion: 2.20.11-0ubuntu79 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Mar 25 19:47:44 2022 InstallationDate: Installed on 2022-03-13 (11 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20220313) SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1966381/+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 1966381] Re: applications crash that never crashed under Ubuntu-20.04
> So, maybe the default SwapUsedLimit is not appropriate for Ubuntu I don't think tweaking that will help much if at all, it's going to be hard to get around the core issue of oomd counting pagecache as memory pressure -- 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/1966381 Title: applications crash that never crashed under Ubuntu-20.04 Status in systemd package in Ubuntu: New Status in systemd source package in Jammy: New Bug description: Just now I was watching some video in Firefox. I popped over to another virtual workspace for a few minutes, and when I popped back to Firefox it had gone. The same thing had been happening all week (I installed fresh Ubuntu-22.04 last week) with Chrome, Firefox and Thunderbird. This time instead of shrugging it off I looked in the logs, and found this Mar 25 19:45:40 ubuntu systemd-oomd[960]: Killed /user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-firefox-6607.scope due to memory used (15940579328) / total (16153944064) and swap used (925564928) / total (1023406080) being more than 90.00% Mar 22 08:11:29 ubuntu systemd[5029]: app-gnome-google\x2dchrome-5412.scope: systemd-oomd killed 298 process(es) in this unit. Mar 23 11:09:28 ubuntu systemd-oomd[1055]: Killed /user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-thunderbird-5418.scope due to memory used (15591993344) / total (16149745664) and swap used (927760384) / total (1023406080) being more than 90.00% Mar 23 11:09:28 ubuntu systemd[5029]: app-gnome-thunderbird-5418.scope: systemd-oomd killed 173 process(es) in this unit. I know it's saying those three entirely unrelated applications had suddenly decided to swallow all the RAM+swap on this laptop of mine - but the very same apps didn't act like that last week under Ubuntu-20.04, so I suspect something else is going on I can't say they hadn't swallowed all the RAM, but there is ZERO sign of a system on the verge of collapsing - everything has been screaming along just nicely - no sign of the "staggering" you normally get when the OS is heavily into swap. However, now that I look I see my 16G laptop only has 1G swap??? I just let the Ubuntu installer do it's defaults - but it used to auto- choose 1xRAM or 2xRAM - what's with this 1G swap? Could that be related? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: systemd-oomd 249.11-0ubuntu1 ProcVersionSignature: Ubuntu 5.15.0-23.23-generic 5.15.27 Uname: Linux 5.15.0-23-generic x86_64 ApportVersion: 2.20.11-0ubuntu79 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Mar 25 19:47:44 2022 InstallationDate: Installed on 2022-03-13 (11 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20220313) SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1966381/+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 1966381] Re: applications crash that never crashed under Ubuntu-20.04
wow, looking at the systemd code (even upstream), oomd is counting pagecache as 'used' memory which is massively unfair as the kernel is responsible for pagecache use, not userspace, and it's not even accurate (from a OOM perspective) since the kernel will drop pagecache as memory pressure increases. Definitely some discussion and patching needs to happen upstream in systemd I think. -- 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/1966381 Title: applications crash that never crashed under Ubuntu-20.04 Status in systemd package in Ubuntu: New Status in systemd source package in Jammy: New Bug description: Just now I was watching some video in Firefox. I popped over to another virtual workspace for a few minutes, and when I popped back to Firefox it had gone. The same thing had been happening all week (I installed fresh Ubuntu-22.04 last week) with Chrome, Firefox and Thunderbird. This time instead of shrugging it off I looked in the logs, and found this Mar 25 19:45:40 ubuntu systemd-oomd[960]: Killed /user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-firefox-6607.scope due to memory used (15940579328) / total (16153944064) and swap used (925564928) / total (1023406080) being more than 90.00% Mar 22 08:11:29 ubuntu systemd[5029]: app-gnome-google\x2dchrome-5412.scope: systemd-oomd killed 298 process(es) in this unit. Mar 23 11:09:28 ubuntu systemd-oomd[1055]: Killed /user.slice/user-1001.slice/user@1001.service/app.slice/app-gnome-thunderbird-5418.scope due to memory used (15591993344) / total (16149745664) and swap used (927760384) / total (1023406080) being more than 90.00% Mar 23 11:09:28 ubuntu systemd[5029]: app-gnome-thunderbird-5418.scope: systemd-oomd killed 173 process(es) in this unit. I know it's saying those three entirely unrelated applications had suddenly decided to swallow all the RAM+swap on this laptop of mine - but the very same apps didn't act like that last week under Ubuntu-20.04, so I suspect something else is going on I can't say they hadn't swallowed all the RAM, but there is ZERO sign of a system on the verge of collapsing - everything has been screaming along just nicely - no sign of the "staggering" you normally get when the OS is heavily into swap. However, now that I look I see my 16G laptop only has 1G swap??? I just let the Ubuntu installer do it's defaults - but it used to auto- choose 1xRAM or 2xRAM - what's with this 1G swap? Could that be related? ProblemType: Bug DistroRelease: Ubuntu 22.04 Package: systemd-oomd 249.11-0ubuntu1 ProcVersionSignature: Ubuntu 5.15.0-23.23-generic 5.15.27 Uname: Linux 5.15.0-23-generic x86_64 ApportVersion: 2.20.11-0ubuntu79 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Fri Mar 25 19:47:44 2022 InstallationDate: Installed on 2022-03-13 (11 days ago) InstallationMedia: Ubuntu 22.04 LTS "Jammy Jellyfish" - Alpha amd64 (20220313) SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1966381/+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 1965180] Re: apt-add-repository requires --login for private repos, breaking automated workflows
** Merge proposal linked:
https://code.launchpad.net/~ddstreet/software-properties/+git/software-properties/+merge/417981
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to software-properties in
Ubuntu.
https://bugs.launchpad.net/bugs/1965180
Title:
apt-add-repository requires --login for private repos, breaking
automated workflows
Status in software-properties package in Ubuntu:
New
Status in software-properties source package in Jammy:
New
Bug description:
On Focal, in an automated environment (such as a launchpad builder), a
used can do the following workflow:
curl
"https://keyserver.ubuntu.com/pks/lookup?op=get=0x${FINGERPRINT};
--output /etc/apt/trusted.gpg.d/${FINGERPRINT}.asc
apt-add-repository "deb https://${USERNAME}:${PASSWORD}@private-
ppa.launchpad.net/${REPO}/ubuntu focal main"
Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease
Hit:2 http://archive.ubuntu.com/ubuntu focal-updates InRelease
Hit:3 http://archive.ubuntu.com/ubuntu focal-backports InRelease
Hit:4 http://security.ubuntu.com/ubuntu focal-security InRelease
Get:5 https://private-ppa.launchpad.net/$REPO/ubuntu focal InRelease [24.3 kB]
Get:6 https://private-ppa.launchpad.net/$REPO/ubuntu focal/main amd64
Packages [3288 B]
Get:7 https://private-ppa.launchpad.net/$REPO/ubuntu focal/main
Translation-en [1892 B]
However, on Jammy, I get the following:
curl "https://keyserver.ubuntu.com/pks/lookup?op=get=0x${FINGERPRINT};
--output /etc/apt/trusted.gpg.d/${FINGERPRINT}.asc
apt-add-repository "deb https://${USERNAME}:${PASSWORD}@private-
ppa.launchpad.net/${REPO}/ubuntu jammy main"
Repository: 'deb https://private-ppa.launchpad.net/$REPO/ubuntu jammy main'
Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 105,
in lpppa
self._lpppa = self.lpteam.getPPAByName(name=self.ppaname)
File "/usr/lib/python3/dist-packages/lazr/restfulclient/resource.py", line
592, in __call__
response, content = self.root._browser._request(
File "/usr/lib/python3/dist-packages/lazr/restfulclient/_browser.py", line
429, in _request
raise error
lazr.restfulclient.errors.NotFound: HTTP Error 404: Not Found
Response headers:
---
-content-encoding: gzip
content-length: 91
content-type: text/plain;charset=utf-8
date: Wed, 16 Mar 2022 19:54:16 GMT
server: gunicorn/19.8.1
status: 404
vary: Accept-Encoding
x-powered-by: Zope (www.zope.org), Python (www.python.org)
x-request-id: ec4bd7ff-f333-4543-ba91-3b7b063fab0e
x-vcs-revision: 81acd06336f3c4be8f28a2213f7a64912593402d
---
Response body:
---
b"Object: ,
name: '$REPO'"
---
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/usr/bin/apt-add-repository", line 364, in
sys.exit(0 if addaptrepo.main() else 1)
File "/usr/bin/apt-add-repository", line 352, in main
self.prompt_user_shortcut(shortcut)
File "/usr/bin/apt-add-repository", line 140, in prompt_user_shortcut
if shortcut.description:
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 117,
in description
return self.lpppa.description
File "/usr/lib/python3/dist-packages/softwareproperties/ppa.py", line 109,
in lpppa
raise ShortcutException(msg)
softwareproperties.shortcuthandler.ShortcutException: ERROR: ppa
'$REPO/proposed' not found (use --login if private)
Impish similarly breaks. Digging through changelogs, I see various
entries in Impish forward, starting with version 0.99.0 where a
refactor was done.
using `--login` is not possible in an automated setup (such as a
builder) as it starts an OAuth dance, which requires human
interaction. this will break existing automation utilizing apt-add-
repository for users when migrating to Jammy
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1965180/+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 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest
uploaded to bionic queue, thanks! -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1940141 Title: OpenSSL servers can send a non-empty status_request in a CertificateRequest Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Bionic: New Bug description: [Impact] openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a CertificateRequest message to the client with a non-empty status_request extension. This issue was fixed in openssl-1.1.1d and is included in Focal onward. Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767 Upstream patch review at https://github.com/openssl/openssl/pull/9780 The issue leads to various client failures with TLS 1.3 as described in, e.g. https://github.com/golang/go/issues/35722 https://github.com/golang/go/issues/34040 [Test Plan] The issue can be reproduced by building with `enable-ssl-trace` and then running `s_server` like this: ``` openssl s_server -key key.pem -cert cert.pem -status_file test/recipes/ocsp-response.der -Verify 5 ``` And running `s_client` like this: ``` openssl s_client -status -trace -cert cert.pem -key key.pem ``` The output shows a `status_request` extension in the `CertificateRequest` as follows: Received Record Header: Version = TLS 1.2 (0x303) Content Type = ApplicationData (23) Length = 1591 Inner Content Type = Handshake (22) CertificateRequest, Length=1570 request_context (len=0): extensions, length = 1567 extension_type=status_request(5), length=1521 - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2 0.. 000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01 0.+.0.. 001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86 0...0.. 002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47 0..1.0...UG ...more lines omitted... If the `status_request` extension is present in a `CertificateRequest` then it must be empty according to RFC8446, Sec. 4.4.2.1. [Where problems could occur] The patch disables the `status_request` extension inside a `CertificateRequest`. Applications expecting the incorrect, non-empty reply for the `status_request` extension will break with this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest
If you'd rather remove the opt-in part, that's fine with me; I can sponsor the debdiff then with the opt-in parts left out, if that works for you Bruce and Nicolas. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1940141 Title: OpenSSL servers can send a non-empty status_request in a CertificateRequest Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Bionic: New Bug description: [Impact] openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a CertificateRequest message to the client with a non-empty status_request extension. This issue was fixed in openssl-1.1.1d and is included in Focal onward. Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767 Upstream patch review at https://github.com/openssl/openssl/pull/9780 The issue leads to various client failures with TLS 1.3 as described in, e.g. https://github.com/golang/go/issues/35722 https://github.com/golang/go/issues/34040 [Test Plan] The issue can be reproduced by building with `enable-ssl-trace` and then running `s_server` like this: ``` openssl s_server -key key.pem -cert cert.pem -status_file test/recipes/ocsp-response.der -Verify 5 ``` And running `s_client` like this: ``` openssl s_client -status -trace -cert cert.pem -key key.pem ``` The output shows a `status_request` extension in the `CertificateRequest` as follows: Received Record Header: Version = TLS 1.2 (0x303) Content Type = ApplicationData (23) Length = 1591 Inner Content Type = Handshake (22) CertificateRequest, Length=1570 request_context (len=0): extensions, length = 1567 extension_type=status_request(5), length=1521 - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2 0.. 000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01 0.+.0.. 001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86 0...0.. 002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47 0..1.0...UG ...more lines omitted... If the `status_request` extension is present in a `CertificateRequest` then it must be empty according to RFC8446, Sec. 4.4.2.1. [Where problems could occur] The patch disables the `status_request` extension inside a `CertificateRequest`. Applications expecting the incorrect, non-empty reply for the `status_request` extension will break with this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest
@ubuntu-security since this is openssl, could you give the debdiff a review? I can sponsor it as a normal SRU if you have no objections (and the changes look ok to you), as it doesn't really seem like it would specifically need to go to the -security pocket. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1940141 Title: OpenSSL servers can send a non-empty status_request in a CertificateRequest Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Bionic: New Bug description: [Impact] openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a CertificateRequest message to the client with a non-empty status_request extension. This issue was fixed in openssl-1.1.1d and is included in Focal onward. Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767 Upstream patch review at https://github.com/openssl/openssl/pull/9780 The issue leads to various client failures with TLS 1.3 as described in, e.g. https://github.com/golang/go/issues/35722 https://github.com/golang/go/issues/34040 [Test Plan] The issue can be reproduced by building with `enable-ssl-trace` and then running `s_server` like this: ``` openssl s_server -key key.pem -cert cert.pem -status_file test/recipes/ocsp-response.der -Verify 5 ``` And running `s_client` like this: ``` openssl s_client -status -trace -cert cert.pem -key key.pem ``` The output shows a `status_request` extension in the `CertificateRequest` as follows: Received Record Header: Version = TLS 1.2 (0x303) Content Type = ApplicationData (23) Length = 1591 Inner Content Type = Handshake (22) CertificateRequest, Length=1570 request_context (len=0): extensions, length = 1567 extension_type=status_request(5), length=1521 - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2 0.. 000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01 0.+.0.. 001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86 0...0.. 002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47 0..1.0...UG ...more lines omitted... If the `status_request` extension is present in a `CertificateRequest` then it must be empty according to RFC8446, Sec. 4.4.2.1. [Where problems could occur] The patch disables the `status_request` extension inside a `CertificateRequest`. Applications expecting the incorrect, non-empty reply for the `status_request` extension will break with this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest
> It's not needed for actual functionality of the backport but that assumes that any future backports or fixes don't break this backport yes i get that, my comment is about whether or not the patch changes any code *outside* of the self-tests, e.g. the TLSProxy perl code changes. If that's *only* used for self-tests then including in the backport shouldn't cause any regression. Remember that people reviewing/sponsoring patches may not have deep experience with the code so it's good to more clearly explain things that aren't necessarily obvious, such as the 2nd patch only affecting test code (if that is indeed the case), since at first glance that isn't what it looks like. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1940141 Title: OpenSSL servers can send a non-empty status_request in a CertificateRequest Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Bionic: New Bug description: [Impact] openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a CertificateRequest message to the client with a non-empty status_request extension. This issue was fixed in openssl-1.1.1d and is included in Focal onward. Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767 Upstream patch review at https://github.com/openssl/openssl/pull/9780 The issue leads to various client failures with TLS 1.3 as described in, e.g. https://github.com/golang/go/issues/35722 https://github.com/golang/go/issues/34040 [Test Plan] The issue can be reproduced by building with `enable-ssl-trace` and then running `s_server` like this: ``` openssl s_server -key key.pem -cert cert.pem -status_file test/recipes/ocsp-response.der -Verify 5 ``` And running `s_client` like this: ``` openssl s_client -status -trace -cert cert.pem -key key.pem ``` The output shows a `status_request` extension in the `CertificateRequest` as follows: Received Record Header: Version = TLS 1.2 (0x303) Content Type = ApplicationData (23) Length = 1591 Inner Content Type = Handshake (22) CertificateRequest, Length=1570 request_context (len=0): extensions, length = 1567 extension_type=status_request(5), length=1521 - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2 0.. 000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01 0.+.0.. 001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86 0...0.. 002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47 0..1.0...UG ...more lines omitted... If the `status_request` extension is present in a `CertificateRequest` then it must be empty according to RFC8446, Sec. 4.4.2.1. [Where problems could occur] The patch disables the `status_request` extension inside a `CertificateRequest`. Applications expecting the incorrect, non-empty reply for the `status_request` extension will break with this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest
The 2nd upstream patch appears to add new functionality, for actually parsing a certificate request; is that actually needed (outside of the self-tests)? If not, it shouldn't be included in the backport. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1940141 Title: OpenSSL servers can send a non-empty status_request in a CertificateRequest Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Bionic: New Bug description: [Impact] openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a CertificateRequest message to the client with a non-empty status_request extension. This issue was fixed in openssl-1.1.1d and is included in Focal onward. Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767 Upstream patch review at https://github.com/openssl/openssl/pull/9780 The issue leads to various client failures with TLS 1.3 as described in, e.g. https://github.com/golang/go/issues/35722 https://github.com/golang/go/issues/34040 [Test Plan] The issue can be reproduced by building with `enable-ssl-trace` and then running `s_server` like this: ``` openssl s_server -key key.pem -cert cert.pem -status_file test/recipes/ocsp-response.der -Verify 5 ``` And running `s_client` like this: ``` openssl s_client -status -trace -cert cert.pem -key key.pem ``` The output shows a `status_request` extension in the `CertificateRequest` as follows: Received Record Header: Version = TLS 1.2 (0x303) Content Type = ApplicationData (23) Length = 1591 Inner Content Type = Handshake (22) CertificateRequest, Length=1570 request_context (len=0): extensions, length = 1567 extension_type=status_request(5), length=1521 - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2 0.. 000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01 0.+.0.. 001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86 0...0.. 002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47 0..1.0...UG ...more lines omitted... If the `status_request` extension is present in a `CertificateRequest` then it must be empty according to RFC8446, Sec. 4.4.2.1. [Where problems could occur] The patch disables the `status_request` extension inside a `CertificateRequest`. Applications expecting the incorrect, non-empty reply for the `status_request` extension will break with this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
> I have update ongoing on esm-infa-staging for it just to clarify, if the systemd patch isn't added to the actual main (currently closed) xenial-updates repo, it won't be very much help to anyone wanting to create new xenial containers on jammy. So, just patching systemd in the esm repo likely is not enough - especially if the prebuilt LXD container images don't pick up the ESM version of systemd. -- 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/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [workaround] On Jammy host edit default kernel command line to include systemd.unified_cgroup_hierarchy=false update your bootloader configuration; and reboot then hybrid cgroups will be on the host, and one can launch xenial container then. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+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 1964494] Re: Setting DuplicateAddressDetection=none doesn't disable DAD for link-local IPs
> I think this commit [1] may be related (landed in systemd v249) yeah, that commit seems to be intentionally forcing ACD on for statically configured ipv4, i'm not sure quite why, it seems like a user-configured setting should be honored; but possibly Yu was trying to default it to on instead of overriding user config. -- 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/1964494 Title: Setting DuplicateAddressDetection=none doesn't disable DAD for link- local IPs Status in systemd package in Ubuntu: New Bug description: A customer reported network disconnections on their storage servers when running 'netplan apply'. The culprit was that they have link-local addresses configured and the Duplicate Address Detection (DAD) mechanism was delaying the interfaces from coming back up. As a workaround we tried to disable DAD for the interfaces but that's not working in Ubuntu 22.04: I've noticed that setting DuplicateAddressDetection=none for an interface with a link-local address (e.g., 169.254.*) via a .network file added to /etc/systemd/network/ doesn't really disable Duplicate Address Detection. OS and package versions: - Description: Ubuntu Jammy Jellyfish (development branch). Release: 22.04 - systemd 249.5-2ubuntu4 Reproducer: --- 1- Set up Ubuntu 22.04 VM 2- Increase systemlog level: mkdir -p /etc/systemd/system/systemd-networkd.service.d/ cat > /etc/systemd/system/systemd-networkd.service.d/10-debug.conf
[Touch-packages] [Bug 1962038] Re: wrong sysrq value in /usr/lib/sysctl.d/50-default.conf
> systemd should drop its setting to defer to the file that we have been carrying in procps for a very long time. at some point it would be a better idea to drop the procps files and adjust the systemd defaults where/if needed. The sysctl configuration hasn't been applied by procps since upstart; with systemd, the systemd- sysctl service is what applies all the sysctl settings. -- 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/1962038 Title: wrong sysrq value in /usr/lib/sysctl.d/50-default.conf Status in procps package in Ubuntu: New Status in systemd package in Ubuntu: Triaged Status in procps source package in Impish: Won't Fix Status in systemd source package in Impish: New Status in procps source package in Jammy: New Status in systemd source package in Jammy: Triaged Bug description: [Impact] I've just learned that systemd is setting kernel.sysrq to 16 in /usr/lib/sysctl.d/50-default.conf. This is inconsistent with /etc/sysctl.d/10-magic-sysrq.conf which intentionally sets it to 176 by default. systemd should drop its setting to defer to the file that we have been carrying in procps for a very long time. Therefore, users can only sync their storage but not do any other actions using the magic sysrq key. [Test Plan] $ sysctl kernel.sysrq => This should show "kernel.sysrq = 176" as set by /etc/sysctl.d/10-magic-sysrq.conf $ sysctl net.ipv4.conf.all.rp_filter => This should show "net.ipv4.conf.all.rp_filter=2" as set by /etc/sysctl.d/10-network-security.conf [Where problems could occur] * This patch changes systemd's sysctl configuration in /lib/sysctl.d/*.conf * If something is broken it could fail to apply any of systemd's sysctl configuration, but Ubuntu's defaults from /etc/sysctl.d/*.conf would still be in place. [Other Info] * None To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/1962038/+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 1962332] Re: xenial systemd fails to start if cgroup2 is mounted
> "so this is fixed already in f and later" - think you mean "b and later" here? yes sorry, fixed in b and later ** Description changed: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, - so this is fixed already in f and later. + so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. -- 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/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Confirmed Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in b and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+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 1962332] [NEW] xenial systemd fails to start if cgroup2 is mounted
Public bug reported: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in f and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. ** Affects: systemd (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Fix Released -- 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/1962332 Title: xenial systemd fails to start if cgroup2 is mounted Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: New Bug description: [impact] now that jammy has moved to using unified cgroup2, containers started on jammy must also use unified cgroup2 (since the cgroup subsystems can only be mounted as v1 or v2 throughout the entire system, including inside containers). However, the systemd in xenial does not include support for cgroup2, and doesn't recognize its magic (added in upstream commit 099619957a0), so it fails to start completely. [test case] create a jammy system, that has unified cgroup2 mounted. Then: $ lxc launch ubuntu:xenial test-x ... $ lxc shell test-x (inside xenial container): $ mv /sbin/init /sbin/init.old $ cat > /sbin/init <+a q Failed to mount cgroup at /sys/fs/cgroup/systemd: Operation not permitted [!!] Failed to mount API filesystems, freezing. Freezing execution. [regression potential] any regression would likely break xenial containers from starting at all, or cause cgroup-related problems with systemd starting and/or managing services. [scope] this is needed only for xenial. However, as xenial is out of standard support, this would need to be an exception. this is fixed upstream with commit 099619957a0 (and possibly others - needs closer investigation and testing) which is first included in v230, so this is fixed already in f and later. this is not needed - by default - for trusty because upstart is used there; however, I think it's possible to change trusty over to use systemd instead of upstart. But since trusty is out of standard support, and it doesn't fail by default, it doesn't seem like it should be fixed. [other info] An alternative appears to be to change the host system back to using the 'hybrid' cgroup, however that obviously is awful and would remove the benefits of cgroup v2 from the host system, and force all containers on the host system to also use the 'hybrid' cgroup. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1962332/+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 1945225] Re: udev produces unpredictable net names when PCI device is a bridge
did you find any alternate way to handle this? If not we should probably review/merge the 247 naming approach, if @slyon approves -- 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/1945225 Title: udev produces unpredictable net names when PCI device is a bridge Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Status in systemd source package in Hirsute: Fix Released Status in systemd source package in Impish: Fix Released Bug description: [Impact] udev can produce unpredictable network interface names by default when multiple devices map to the same slot due to an intermediate bridge. On an Nvidia DGX2 system, I see the following when booting a system with udev 245.4-4ubuntu3.13: ubuntu@akis:~$ ls /sys/class/net enp134s0f0 enp6s0 ens103 ens107 eth3 eth9 enp134s0f1 ens102 ens106 eth1eth7 lo For each ens* device, there is a sibling eth* device that maps to the same slot because both devices are behind the same bridge. Unpredictable names present well known problems, but I'll describe a specific issue I'm having. We currently do automated network testing that MAAS deploys a system and then configures 2 specific NICs on the system. While MAAS does take care to always restore the names used during commissioning (eth3 will always be the same NIC on every deploy), these names can change each time the system is commissioned. So today we need to go in and edit the NIC names manually in MAAS any time the system is re-commissioned. [Test Case] Boot with kernel option net.naming-scheme=v247; verify that all network interfaces receive predictable names. [Fix] This issue was addressed upstream by adding a new v247 naming scheme that detects this scenario and disables usage of slot-based names for these devices. Obviously changing the default naming scheme in a released LTS series could break users. However, we could introduce the v247 scheme in a focal SRU, and keep the default scheme of v245 (via -Ddefault-net-naming-scheme=v245). Users impacted by this could then opt-in to the v247 scheme by passing net.naming-scheme=v247 or net.naming-scheme=latest on the kernel command line. I could add this to DGX2 systems via a kernel_opts MAAS tag to always get predictable names during commissioning. [Regression Risk] This would change the behavior of any users who select net.naming-scheme=latest, since the latest will now be v247 and not v245. I'm not sure why an existing Ubuntu user would be doing that though - AFAICT, Ubuntu currently always defaults to the latest scheme. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1945225/+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 1950508] Re: unified cgroup incorrectly used in container on host with legacy/hybrid cgroup
** Changed in: systemd (Ubuntu Impish) Assignee: Dan Streetman (ddstreet) => (unassigned) ** Changed in: systemd (Ubuntu Impish) Status: In Progress => 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/1950508 Title: unified cgroup incorrectly used in container on host with legacy/hybrid cgroup Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Impish: New Status in systemd source package in Jammy: Fix Released Bug description: [impact] after systemd was changed to default to cgroupv2, any container started on a host that still uses legacy or hybrid cgroup mounts will result in a container that attempts to use unified cgroup but can't due to all the controllers being used as v1 in the host kernel. [test case] TBD [regression potential] container, or vm or bare metal, that incorrectly uses cgroupv1, or incorrect use of cgroupv2. [scope] needed only for i and later f and earlier default to cgroupv1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950508/+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 1934147] Re: systemd leaks abandoned session scopes
per comment 5, released for impish
** Changed in: systemd (Ubuntu Impish)
Status: Fix Committed => Fix Released
** Changed in: systemd (Ubuntu)
Status: Fix Committed => Fix Released
--
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/1934147
Title:
systemd leaks abandoned session scopes
Status in snapd:
Invalid
Status in systemd:
New
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Bionic:
Fix Released
Status in systemd source package in Focal:
Fix Released
Status in systemd source package in Groovy:
Won't Fix
Status in systemd source package in Hirsute:
Fix Released
Status in systemd source package in Impish:
Fix Released
Bug description:
[impact]
systemd may leak sessions, leaving empty cgroups around as well as
abandoned session scopes.
[test case]
on a system where the user has a ssh key that allows noninteractive
login to localhost, and also has noninteractive sudo, run:
$ for i in {1..100}; do sudo -b -i -u ubuntu ssh localhost -- sleep 1;
done; for i in {1..20}; do echo 'Reloading...'; sudo systemctl daemon-
reload; done
check the sessions to see there have been leaked sessions:
$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 1000 ubuntu ttyS0
350 1000 ubuntu
351 1000 ubuntu
360 1000 ubuntu
...
to verify the sessions were leaked, clear them out with:
$ echo '' | sudo tee
/sys/fs/cgroup/unified/user.slice/user-1000.slice/session-*.scope/cgroup.events
that should result in all the leaked sessions being cleaned up.
[regression potential]
issues during systemd pid1 reexec/reload, or issues while cleaning up
sessions, including leaking sessions/cgroups
[scope]
this is needed for all releases
upstream bug linked above, and upstream PR:
https://github.com/systemd/systemd/pull/20199
[original description]
On a system that is monitored via telegraf I found many abandoned
systemd session which I believe are created by a potential race where
systemd is reloading unit files and at the same time a user is
connecting to the system via ssh or is executing the su command.
The simple reproducer
$ for i in {1..100}; do sleep 0.2; ssh localhost sudo systemctl
daemon-reload & ssh localhost sleep 1 & done
Wait > 1 second
$ jobs -p | xargs --verbose --no-run-if-empty kill -KILL
To clean out STOPPED jobs and
$ systemctl status --all 2> /dev/null | grep --before-context 3
abandoned
will produce something similar to
│ ├─ 175 su - ubuntu
│ ├─ 178 -su
│ ├─62375 systemctl status --all
│ └─62376 grep --color=auto --before-context 3 abandoned
--
● session-273.scope - Session 273 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-273.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
--
● session-274.scope - Session 274 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-274.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
--
● session-30.scope - Session 30 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-30.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 10:05:56 UTC; 3h 30min ago
--
● session-302.scope - Session 302 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-302.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:04 UTC; 4min 6s ago
--
│ ├─ 175 su - ubuntu
│ ├─ 178 -su
│ ├─62375 systemctl status --all
│ └─62376 grep --color=auto --before-context 3 abandoned
The system in question is running Bionic, systemd-237-3ubuntu10.48
To manage notifications about this bug go to:
https://bugs.launchpad.net/snapd/+bug/1934147/+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 1949970] Re: attempt to dlopen nonexistent pam_kwallet.so spams log
I think we should ignore hirsute since it reaches EOL next week. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1949970 Title: attempt to dlopen nonexistent pam_kwallet.so spams log Status in lightdm package in Ubuntu: Fix Released Status in lightdm source package in Bionic: New Status in lightdm source package in Focal: Fix Committed Status in lightdm source package in Hirsute: Fix Committed Status in lightdm source package in Impish: Fix Committed Status in lightdm source package in Jammy: Fix Released Bug description: [impact] lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet which died around Trusty (https://launchpad.net/ubuntu/+source/pam- kwallet) while pam_kwallet5.so comes from kwallet-pam which provides only the newer '5' version, not the older unversioned library file. This results in repeated spam error messages in the system log complaining about failure to load pam_kwallet.so [test case] install/enable lightdm and check system log at boot for messages like: Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so [regression potential] any regression would likely cause problems during login and/or missing or extra log messages during pam authentication. [scope] this is needed in all releases [other info] https://github.com/canonical/lightdm/pull/216 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1949970/+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 1949970] Re: attempt to dlopen nonexistent pam_kwallet.so spams log
ubuntu@lp1949970-f:~$ dpkg -l lightdm|grep lightdm ii lightdm1.30.0-0ubuntu4~20.04.1 amd64Display Manager ubuntu@lp1949970-f:~$ journalctl -b -g 'unable to dlopen' -- Logs begin at Tue 2022-01-11 17:28:51 UTC, end at Tue 2022-01-11 18:02:33 UTC. -- Jan 11 17:58:09 lp1949970-f lightdm[1048]: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory Jan 11 17:58:09 lp1949970-f lightdm[1048]: PAM unable to dlopen(pam_kwallet5.so): /lib/security/pam_kwallet5.so: cannot open shared object file: No such file or directory Jan 11 17:58:11 lp1949970-f lightdm[1278]: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory Jan 11 17:58:11 lp1949970-f lightdm[1278]: PAM unable to dlopen(pam_kwallet5.so): /lib/security/pam_kwallet5.so: cannot open shared object file: No such file or directory ...(upgrade and reboot)... ubuntu@lp1949970-f:~$ dpkg -l lightdm|grep lightdm ii lightdm1.30.0-0ubuntu4~20.04.2 amd64Display Manager ubuntu@lp1949970-f:~$ journalctl -b -g 'unable to dlopen' -- Logs begin at Tue 2022-01-11 17:28:51 UTC, end at Tue 2022-01-11 18:03:41 UTC. -- -- No entries -- ** Tags removed: verification-needed verification-needed-focal verification-needed-impish ** Tags added: verification-done verification-done-focal verification-done-impish -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1949970 Title: attempt to dlopen nonexistent pam_kwallet.so spams log Status in lightdm package in Ubuntu: Fix Released Status in lightdm source package in Bionic: New Status in lightdm source package in Focal: Fix Committed Status in lightdm source package in Hirsute: Fix Committed Status in lightdm source package in Impish: Fix Committed Status in lightdm source package in Jammy: Fix Released Bug description: [impact] lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet which died around Trusty (https://launchpad.net/ubuntu/+source/pam- kwallet) while pam_kwallet5.so comes from kwallet-pam which provides only the newer '5' version, not the older unversioned library file. This results in repeated spam error messages in the system log complaining about failure to load pam_kwallet.so [test case] install/enable lightdm and check system log at boot for messages like: Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so [regression potential] any regression would likely cause problems during login and/or missing or extra log messages during pam authentication. [scope] this is needed in all releases [other info] https://github.com/canonical/lightdm/pull/216 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1949970/+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 1949970] Re: attempt to dlopen nonexistent pam_kwallet.so spams log
ubuntu@lp1949970-i:~$ dpkg -l lightdm|grep lightdm ii lightdm 1.30.0-0ubuntu4 amd64Display Manager ubuntu@lp1949970-i:~$ journalctl -b -g 'unable to dlopen' -- Journal begins at Tue 2022-01-11 17:28:57 UTC, ends at Tue 2022-01-11 17:59:05 UTC. -- Jan 11 17:58:14 lp1949970-i lightdm[939]: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory Jan 11 17:58:14 lp1949970-i lightdm[939]: PAM unable to dlopen(pam_kwallet5.so): /lib/security/pam_kwallet5.so: cannot open shared object file: No such file or directory Jan 11 17:58:16 lp1949970-i lightdm[1083]: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory Jan 11 17:58:16 lp1949970-i lightdm[1083]: PAM unable to dlopen(pam_kwallet5.so): /lib/security/pam_kwallet5.so: cannot open shared object file: No such file or directory ...(upgrade and reboot)... ubuntu@lp1949970-i:~$ dpkg -l lightdm|grep lightdm ii lightdm1.30.0-0ubuntu4.21.10.1 amd64Display Manager ubuntu@lp1949970-i:~$ journalctl -b -g 'unable to dlopen' -- Journal begins at Tue 2022-01-11 17:28:57 UTC, ends at Tue 2022-01-11 18:01:00 UTC. -- -- No entries -- -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1949970 Title: attempt to dlopen nonexistent pam_kwallet.so spams log Status in lightdm package in Ubuntu: Fix Released Status in lightdm source package in Bionic: New Status in lightdm source package in Focal: Fix Committed Status in lightdm source package in Hirsute: Fix Committed Status in lightdm source package in Impish: Fix Committed Status in lightdm source package in Jammy: Fix Released Bug description: [impact] lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet which died around Trusty (https://launchpad.net/ubuntu/+source/pam- kwallet) while pam_kwallet5.so comes from kwallet-pam which provides only the newer '5' version, not the older unversioned library file. This results in repeated spam error messages in the system log complaining about failure to load pam_kwallet.so [test case] install/enable lightdm and check system log at boot for messages like: Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so [regression potential] any regression would likely cause problems during login and/or missing or extra log messages during pam authentication. [scope] this is needed in all releases [other info] https://github.com/canonical/lightdm/pull/216 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1949970/+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 1950496] Re: networkd doesn't provide DNS to nspawn containers
Also for future reference I think upstream commit fb3aec45a0de7f71aa6418bd4f9d5f314efb4eb5 fixes this, but I never got a chance to test it before upgrading. ** Changed in: systemd (Ubuntu Focal) Status: New => Incomplete ** Changed in: systemd (Ubuntu) Status: New => Fix Released -- 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/1950496 Title: networkd doesn't provide DNS to nspawn containers Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Incomplete Bug description: [impact] the host networkd doesn't include DNS info to nspawn containers [test case] create/start a nspawn container, e.g. with 'machinectl start', open a shell in the container, and check resolvectl to see if a nameserver was provided. [regression potential] failures in the host networkd, possibly affecting other host interfaces which are controlled by networkd, or (more likely) failure to provide dhcp to nspawn containers [scope] TBD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950496/+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 1950496] Re: networkd doesn't provide DNS to nspawn containers
I was able to reproduce this when my bare metal system was running focal, but I since have upgraded to impish and now i can't reproduce this problem in a focal VM, so probably there is some specific network setup required to reproduce (that I have on my bare metal system but not in a VM); since it's no longer a problem for me as I've upgraded to impish, I'm dropping ownership of this, but if anyone else has this problem (i.e. can reproduce it) please reopen the bug and/or add a comment. ** Changed in: systemd (Ubuntu Focal) Assignee: Dan Streetman (ddstreet) => (unassigned) ** Changed in: systemd (Ubuntu Focal) Importance: Medium => Low ** Changed in: systemd (Ubuntu Focal) Status: In Progress => 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/1950496 Title: networkd doesn't provide DNS to nspawn containers Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Incomplete Bug description: [impact] the host networkd doesn't include DNS info to nspawn containers [test case] create/start a nspawn container, e.g. with 'machinectl start', open a shell in the container, and check resolvectl to see if a nameserver was provided. [regression potential] failures in the host networkd, possibly affecting other host interfaces which are controlled by networkd, or (more likely) failure to provide dhcp to nspawn containers [scope] TBD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950496/+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 1946388] Re: Journalctl -f --file some.journal causes coredump
** Changed in: systemd (Ubuntu Focal) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Focal) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1946388 Title: Journalctl -f --file some.journal causes coredump Status in systemd: Fix Released Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Bug description: [impact] journalctl -f --file FILE results in segfault [test case] $ journalctl -f --file $FILENAME [regression potential] journalctl segfault or failure to properly operate [scope] needed in focal fixed upstream in 2b6df46d21a at v246, so fixed already in h and later [original description] Focal latest systemd 245. Journalctl -f --file path/to/file.journal. Will allways causes journalctl crash... The same doesnt happen on centos8 systemd 239... I couldnt test on any more systems atm. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1946388/+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 1946388] Re: Journalctl -f --file some.journal causes coredump
** Bug watch added: github.com/systemd/systemd/issues #15528 https://github.com/systemd/systemd/issues/15528 ** Also affects: systemd via https://github.com/systemd/systemd/issues/15528 Importance: Unknown Status: Unknown ** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Fix Released ** Description changed: + [impact] + + journalctl -f --file FILE results in segfault + + [test case] + + $ journalctl -f --file $FILENAME + + [regression potential] + + journalctl segfault or failure to properly operate + + [scope] + + needed in focal + + fixed upstream in 2b6df46d21a at v246, so fixed already in h and later + + [original description] + Focal latest systemd 245. Journalctl -f --file path/to/file.journal. Will allways causes journalctl crash... The same doesnt happen on centos8 systemd 239... I couldnt test on any more systems atm. -- 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/1946388 Title: Journalctl -f --file some.journal causes coredump Status in systemd: Unknown Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: New Bug description: [impact] journalctl -f --file FILE results in segfault [test case] $ journalctl -f --file $FILENAME [regression potential] journalctl segfault or failure to properly operate [scope] needed in focal fixed upstream in 2b6df46d21a at v246, so fixed already in h and later [original description] Focal latest systemd 245. Journalctl -f --file path/to/file.journal. Will allways causes journalctl crash... The same doesnt happen on centos8 systemd 239... I couldnt test on any more systems atm. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1946388/+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 1950794] Re: DHCPv4 (IAID+DUID) networking broken in LXC containers
> Reverting this upstream commit seems to fix the problem: > https://github.com/systemd/systemd/commit/0299deab53d2a087727a5d04c1500c322c48b63e lxd and systemd have what I can only describe euphemistically as a horrible relationship. Instead of carrying another patch on systemd to get it working in lxd, could you try to work this out correctly, either by convincing upstream systemd to change or convincing lxd to change? Long term, it does Ubuntu no favors by hacking up systemd because lxd doesn't conform to the systemd container interface. https://systemd.io/CONTAINER_INTERFACE/ -- 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/1950794 Title: DHCPv4 (IAID+DUID) networking broken in LXC containers Status in lxd package in Ubuntu: New Status in systemd package in Ubuntu: Fix Committed Bug description: DHCPv4 networking does not work in the default IAID+DUID (ClientIdentifier=duid) mode in LXC containers, using systemd-networkd v249.5-2ubuntu1. Static configuration and DHCPv6 work without problem. Reproducer: $ lxc launch ubuntu-daily:jammy jj $ lxc exec jj bash # add-apt-repository ppa:ci-train-ppa-service/4704 # apt install systemd # install systemd 249.5-2ubuntu1 # cat /etc/systemd/network/00-test.network [Match] Name=eth0 [Network] DHCP=ipv4 # systemctl restart systemd-networkd.service # networkctl IDX LINK TYPE OPERATIONAL SETUP [...] 611 eth0 ethercarrier failed A workaround is to avoid IAID+DUID mode via: [DHCPv4] #ClientIdentifier=mac ClientIdentifier=duid-only Interesting logs: Nov 12 14:10:48 jj systemd-networkd[174]: eth0: Requested to activate link Nov 12 14:10:48 jj systemd-networkd[174]: eth0: DHCPv4 client: Failed to set IAID: Device or resource busy Nov 12 14:10:48 jj systemd-networkd[174]: eth0: DHCP4 CLIENT: Failed to set IAID+DUID: Device or resource busy Nov 12 14:10:48 jj systemd-networkd[174]: Failed to check link is initialized: Device or resource busy Nov 12 14:10:48 jj systemd-networkd[174]: eth0: Failed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1950794/+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 1950520] Re: systemd-resolved delivers SOA information when it should not
> Is there a ppa with a more recent systemd-resolved to try on focal yes, https://launchpad.net/~ubuntu-support-team/+archive/ubuntu/systemd however that includes the entire upstream systemd code, not only systemd-resolved; i'd suggest you test inside a VM and not on your main system. -- 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/1950520 Title: systemd-resolved delivers SOA information when it should not Status in systemd package in Ubuntu: Invalid Bug description: I have a setup where a host (say A) in the network runs knot-resolver as a caching nameserver. Among the other hosts, some of them run ubuntu 20.04 and use systemd- resolved. The dhcp setup make all these host use A as their nameserver. The issue with systemd- The issue is that if I do: host -t SOA foo.local the hosts running systemd-resolved answer foo.local has SOA record foo.local. nobody.invalid. 1 3600 1200 604800 10800 making up the SOA record from nowhere (sort of). In fact, if I do the same query pointing directly at A host -t SOA foo.local I correctly get no SOA record. The incorrect response of resolved breaks mDNS resolution. In fact, if nsswitch.conf is set at hosts: files mdns4_minimal [NOTFOUND=return] dns any call requiring name resolution first goes through the hosts files, then mdns is attempted. However, the nss mdnd implementation first checks if the DNS server responds to SOA queries for the top level local name and if this is the case, it gives up. As a consequence, trying to access hosts on the .local domain always fail. The reason why systemd-resolved makes up a SOA record for hosts such as foo.local is that knot resolver replies to queries about it without an answer, but including an authority section ;; AUTHORITY SECTION: foo.local. 10800 IN SOA foo.local. nobody.invalid. 1 3600 1200 604800 10800 ;; ADDITIONAL SECTION: explanation.invalid.10800 IN TXT "Blocking is mandated by standards, see references on https://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml; and systemd-resolved turns that AUTHORITY section into a SOA record. It is not totally clear to me if the fault is on knot-resolver, systemd-resolved or both, but I tend to think it is the second one. Unfortunately, trying to inquire upstream about systemd-resolved appears to be forbidden for anybody not running the last two releases of systemd. Furthermore, I understand that the nature of systemd makes it extra hard or impossible to test a more recent version of systemd-resolved than the one shipped in ubuntu focal. Interestingly, the issue seems to bite those running omnia turris router too (see https://forum.turris.cz/t/avahi-local-domain-warning- on-ubuntu/13437). Maybe they use knot-resolver as their caching nameserver. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950520/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
> It's not something that snapd writes out, it's curious where this comes from it's not written out, it's internally handled/added by pid1, and it *should* be there, because you do want (for example) the mount to be stopped if its backing device is removed. However when the mount is stopped, the BindsTo should be removed (internally, by pid1). So there's some problem with non-core bionic systemd that isn't correctly adding the relation at all, and some problem with core bionic systemd that isn't properly removing the relation when the mount is stopped -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
Sorry to clarify that, the dep is added to the mount over a daemon- reload, but only on core: ddstreet@localhost:~$ systemctl list-dependencies snap-hello\\x2dworld-29.mount snap-hello\x2dworld-29.mount ● ├─-.mount ● ├─snap.mount ● ├─system.slice ● └─var-lib-snapd.mount ddstreet@localhost:~$ systemctl list-dependencies --reverse snap-hello\\x2dworld-29.mount snap-hello\x2dworld-29.mount ● └─multi-user.target ● └─graphical.target ddstreet@localhost:~$ sudo systemctl daemon-reload ddstreet@localhost:~$ systemctl list-dependencies snap-hello\\x2dworld-29.mount snap-hello\x2dworld-29.mount ● ├─-.mount ● ├─dev-loop2.device ● ├─snap.mount ● ├─system.slice ● └─var-lib-snapd.mount ddstreet@localhost:~$ systemctl list-dependencies --reverse snap-hello\\x2dworld-29.mount snap-hello\x2dworld-29.mount ● ├─dev-loop2.device ● └─multi-user.target ● └─graphical.target ubuntu@test-b-full:~$ systemctl list-dependencies snap-hello\\x2dworld-29.mount snap-hello\x2dworld-29.mount ● ├─-.mount ● └─system.slice ubuntu@test-b-full:~$ systemctl list-dependencies --reverse snap-hello\\x2dworld-29.mount snap-hello\x2dworld-29.mount ● └─multi-user.target ● └─graphical.target ubuntu@test-b-full:~$ sudo systemctl daemon-reload ubuntu@test-b-full:~$ systemctl list-dependencies snap-hello\\x2dworld-29.mount snap-hello\x2dworld-29.mount ● ├─-.mount ● └─system.slice ubuntu@test-b-full:~$ systemctl list-dependencies --reverse snap-hello\\x2dworld-29.mount snap-hello\x2dworld-29.mount ● └─multi-user.target ● └─graphical.target -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
This added BindsTo is what's causing the problem: ddstreet@localhost:~$ systemctl show -p BindsTo snap-hello\\x2dworld-29.mount BindsTo= ddstreet@localhost:~$ sudo systemctl daemon-reload ddstreet@localhost:~$ systemctl show -p BindsTo snap-hello\\x2dworld-29.mount BindsTo=dev-loop6.device ubuntu@test-b-full:~$ systemctl show -p BindsTo snap-hello\\x2dworld-29.mount BindsTo= ubuntu@test-b-full:~$ sudo systemctl daemon-reload ubuntu@test-b-full:~$ systemctl show -p BindsTo snap-hello\\x2dworld-29.mount BindsTo= Once the mount unit BindsTo= the loop device, systemd won't start the mount unit (which actually runs 'mount') until the loop device is 'started' but of course the loop device won't ever be started until 'mount' is called. -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
Note one interesting point is that in a core18 system, a squashfs mount (any loop-based mount, really) includes a dep from the mount to its loop device, while the non-core system does not: ddstreet@localhost:~$ cat /etc/issue Ubuntu Core 18 on \4 (\l) ddstreet@localhost:~$ systemctl list-dependencies snap-hello\\x2dworld-29.mount snap-hello\x2dworld-29.mount ● ├─-.mount ● ├─dev-loop3.device ● ├─snap.mount ● ├─system.slice ● └─var-lib-snapd.mount ddstreet@localhost:~$ systemctl list-dependencies --reverse snap-hello\\x2dworld-29.mount snap-hello\x2dworld-29.mount ● ├─dev-loop3.device ● └─multi-user.target ● └─graphical.target ubuntu@test-b-full:~$ cat /etc/issue Ubuntu 18.04.6 LTS \n \l ubuntu@test-b-full:~$ systemctl list-dependencies snap-hello\\x2dworld-29.mount snap-hello\x2dworld-29.mount ● ├─-.mount ● └─system.slice ubuntu@test-b-full:~$ systemctl list-dependencies --reverse snap-hello\\x2dworld-29.mount snap-hello\x2dworld-29.mount ● └─multi-user.target ● └─graphical.target -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
> @slyon you might want to see if commit 918e6f1c0151429f5095355f4f3f74f16e79724a fixes this (and there are a couple follow on commits to this) -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
@slyon you might want to see if commit 918e6f1c0151429f5095355f4f3f74f16e79724a fixes this -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1591490] Re: Please backport apt 1.0.9.2ubuntu2 from utopic (to fix do-release-upgrade)
** Changed in: trusty-backports Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to apt in Ubuntu. https://bugs.launchpad.net/bugs/1591490 Title: Please backport apt 1.0.9.2ubuntu2 from utopic (to fix do-release- upgrade) Status in trusty-backports: Won't Fix Status in apt package in Ubuntu: Confirmed Bug description: For me (and apparently many others), upgrading Ubuntu Trusty LTS to Ubuntu Xenial LTS fails because do-release-upgrade bails out because of apt error messages like this: Unknown Multi-Arch type 'no' for package 'kwin' Unknown Multi-Arch type 'no' for package 'kwin-dev' Unknown Multi-Arch type 'no' for package 'kwin-wayland' Unknown Multi-Arch type 'no' for package 'kwin-x11' Unknown Multi-Arch type 'no' for package 'libkf5sysguard-dev' Unknown Multi-Arch type 'no' for package 'compiz-core' Unknown Multi-Arch type 'no' for package 'compiz-gnome' Unknown Multi-Arch type 'no' for package 'libxapian-dev' It is caused by Debian bug #759099 [1] fixed in apt 1.0.7. Therefore I'm requesting a backport of "apt" to trusty. In the title I've suggested 1.0.9 from utopic - a more recent version might be fine too but when I tried to build the wily version on my local machine it couldn't because the g++ requirement had moved on too far. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=759099 To manage notifications about this bug go to: https://bugs.launchpad.net/trusty-backports/+bug/1591490/+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 1285783] Re: Right panel has a transparent background
** Changed in: trusty-backports Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to ubuntu-themes in Ubuntu. https://bugs.launchpad.net/bugs/1285783 Title: Right panel has a transparent background Status in trusty-backports: Won't Fix Status in gtk+3.0 package in Ubuntu: Fix Released Status in ubuntu-themes package in Ubuntu: Fix Released Bug description: Launching gnome-tweak-tool and choosing a category on the left panel makes the right panel transparent. To manage notifications about this bug go to: https://bugs.launchpad.net/trusty-backports/+bug/1285783/+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 326217] Re: QT libraries in hardy broken because of backports
** Changed in: hardy-backports Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to qt4-x11 in Ubuntu. https://bugs.launchpad.net/bugs/326217 Title: QT libraries in hardy broken because of backports Status in Hardy Backports: Won't Fix Status in qt4-x11 package in Ubuntu: Invalid Bug description: Binary package hint: libqt4-core Hello, there is an uncompatibility in the current LTS release Hardy Heron. Several packages (like qt4-core, qt4-gui etc) are in 4.3.4 version but some others (libqt4-dbg, libqt4-doc...) are backported and in version 4.4.0. And this is big problem. For example I am unable to develop with QT4 because I need all of the modules (core, bui, dbg, doc, xml, webkit etc) and this cannot be done because of dependencies: The following packages have unmet dependencies: libqt4-help: Depends: libqt4-sql (= 4.4.0-1ubuntu5~hardy1) but 4.3.4-0ubuntu3 is to be installed Solution: backport all QT4 libraries (version 4.4.0). Thanks. To manage notifications about this bug go to: https://bugs.launchpad.net/hardy-backports/+bug/326217/+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 313960] Re: Please update dnsmasq hardy packages to version 2.46
** Changed in: hardy-backports Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to dnsmasq in Ubuntu. https://bugs.launchpad.net/bugs/313960 Title: Please update dnsmasq hardy packages to version 2.46 Status in Hardy Backports: Won't Fix Status in dnsmasq package in Ubuntu: Invalid Bug description: Binary package hint: dnsmasq Hello, Dnsmasq has added support for CNAME directives in the config file starting with version 2.46. This version is not available in Hardy, while I believe a LTS release should deserve this improvement. All alternatives require (to my knowledge) heavier configuration and / or demand more on resources. Switching to bind in order to use CNAME or compiling dnsmasq2.46 from source should be considered nontrivial/discourage for the average/beginning user. How about relasing a package for v2.46 in backports ? Regards, Dr. Moe To manage notifications about this bug go to: https://bugs.launchpad.net/hardy-backports/+bug/313960/+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 792301] Re: Ericsson F5521gw 3G module for Lenovo not using optimal kernel module
** Changed in: lucid-backports Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to modemmanager in Ubuntu. https://bugs.launchpad.net/bugs/792301 Title: Ericsson F5521gw 3G module for Lenovo not using optimal kernel module Status in Lucid Backports: Won't Fix Status in ModemManager: Fix Released Status in modemmanager package in Ubuntu: Fix Released Bug description: Binary package hint: modemmanager The Ericsson F5521gw 3G module should use the usb_ncm kernel module (/dev/usb0) for connecting for optimal speed and CPU usage (important for HSPA+ connections). Modemmanager needs to be told this for the usb ID 0bdb:1911 (currently only 0bdb:190d supported). See the attached patch already in current version of modemmanager: http://cgit.freedesktop.org/ModemManager/ModemManager/commit/?id=0b757465ffe6108066d32312ab4e895c372c8f72 ProblemType: Bug DistroRelease: Ubuntu 11.04 Package: modemmanager 0.4+git.20110124t203624.00b6cce-2ubuntu1 ProcVersionSignature: Ubuntu 2.6.38-9.43-generic-pae 2.6.38.4 Uname: Linux 2.6.38-9-generic-pae i686 Architecture: i386 Date: Fri Jun 3 12:41:25 2011 ProcEnviron: LANGUAGE=nb_NO:nb:no_NO:no:nn_NO:nn:en PATH=(custom, user) LANG=nb_NO.UTF-8 SHELL=/bin/bash SourcePackage: modemmanager UpgradeStatus: Upgraded to natty on 2011-04-29 (35 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/lucid-backports/+bug/792301/+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 865907] Re: Please backport tracker to Oneiric
** Changed in: oneiric-backports Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to tracker in Ubuntu. https://bugs.launchpad.net/bugs/865907 Title: Please backport tracker to Oneiric Status in Oneiric Backports: Won't Fix Status in tracker package in Ubuntu: Invalid Bug description: Tracker 0.12 is the latest stable release of GNOME's search engine. It is needed for GNOME Documents. I've tested version 12.6-1 by letting it index my home directory and I ran some searches. The indexed documents showed up in GNOME Documents as they were supposed to. Build log: https://launchpadlibrarian.net/81619551/buildlog_ubuntu- oneiric-amd64.tracker_0.12.3-1~ppa1_BUILDING.txt.gz Tracker 0.12 has been in the GNOME 3 PPA for a month now (since October 5). I've been running it on my computer for a month and I've not seen a single complaint about it not working. https://launchpad.net/~gnome3-team/+archive/gnome3/+builds?build_text=tracker_state=all To manage notifications about this bug go to: https://bugs.launchpad.net/oneiric-backports/+bug/865907/+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 1791958] Re: iptables-restore is missing -w option
Hello, the backports process has recently been updated, please see the new documentation: https://wiki.ubuntu.com/UbuntuBackports I'm closing this bug, but please feel free to open a new bug (or reopen this bug) using the new process, if appropriate. ** Changed in: bionic-backports Status: New => Won't Fix -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iptables in Ubuntu. https://bugs.launchpad.net/bugs/1791958 Title: iptables-restore is missing -w option Status in Bionic Backports: Won't Fix Status in iptables package in Ubuntu: Confirmed Bug description: For CRIU we need to have iptables version 1.6.2 which includes the '-w' option in iptables-restore. This is a request to update iptables to 1.6.2 in 18.10 and if possible backport the necessary changes to 18.04. The CRIU project gets right now many bug reports (mostly in the combination LXD + CRIU) due to the missing '-w' option in iptables- restore. Especially as 18.04 will be around for some time it would be good to have iptables-restore available with '-w'. This is one example bug report: https://github.com/checkpoint- restore/criu/issues/551 But not only CRIU would benefit from this change. It seems also problematic with Kubernetes: https://github.com/kubernetes/kubernetes/pull/60978 So if possible, please update iptables to 1.6.2 (or backport changes) to support -w in iptables-restore. To manage notifications about this bug go to: https://bugs.launchpad.net/bionic-backports/+bug/1791958/+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 1950511] [NEW] FTBFS due to meson disallowing + for bools
Public bug reported: FTBFS with new meson: ../meson.build:46:3: ERROR: Object <[BooleanHolder] holds [bool]: False> of type bool does not support the `+` operator. ** Affects: systemd (Ubuntu) Importance: High Assignee: Dan Streetman (ddstreet) Status: In Progress ** Affects: systemd (Ubuntu Jammy) Importance: High Assignee: Dan Streetman (ddstreet) Status: In Progress ** Also affects: systemd (Ubuntu Jammy) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Jammy) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Jammy) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Jammy) Importance: Medium => High ** Changed in: systemd (Ubuntu Jammy) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1950511 Title: FTBFS due to meson disallowing + for bools Status in systemd package in Ubuntu: In Progress Status in systemd source package in Jammy: In Progress Bug description: FTBFS with new meson: ../meson.build:46:3: ERROR: Object <[BooleanHolder] holds [bool]: False> of type bool does not support the `+` operator. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950511/+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 1950508] Re: unified cgroup incorrectly used in container on host with legacy/hybrid cgroup
** Changed in: systemd (Ubuntu Jammy) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Impish) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Jammy) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Impish) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Jammy) Status: New => In Progress ** Changed in: systemd (Ubuntu Impish) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1950508 Title: unified cgroup incorrectly used in container on host with legacy/hybrid cgroup Status in systemd package in Ubuntu: In Progress Status in systemd source package in Impish: In Progress Status in systemd source package in Jammy: In Progress Bug description: [impact] after systemd was changed to default to cgroupv2, any container started on a host that still uses legacy or hybrid cgroup mounts will result in a container that attempts to use unified cgroup but can't due to all the controllers being used as v1 in the host kernel. [test case] TBD [regression potential] container, or vm or bare metal, that incorrectly uses cgroupv1, or incorrect use of cgroupv2. [scope] needed only for i and later f and earlier default to cgroupv1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950508/+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 1950508] [NEW] unified cgroup incorrectly used in container on host with legacy/hybrid cgroup
Public bug reported: [impact] after systemd was changed to default to cgroupv2, any container started on a host that still uses legacy or hybrid cgroup mounts will result in a container that attempts to use unified cgroup but can't due to all the controllers being used as v1 in the host kernel. [test case] TBD [regression potential] container, or vm or bare metal, that incorrectly uses cgroupv1, or incorrect use of cgroupv2. [scope] needed only for i and later f and earlier default to cgroupv1 ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Affects: systemd (Ubuntu Impish) Importance: Undecided Status: New ** Affects: systemd (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Impish) 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/1950508 Title: unified cgroup incorrectly used in container on host with legacy/hybrid cgroup Status in systemd package in Ubuntu: New Status in systemd source package in Impish: New Status in systemd source package in Jammy: New Bug description: [impact] after systemd was changed to default to cgroupv2, any container started on a host that still uses legacy or hybrid cgroup mounts will result in a container that attempts to use unified cgroup but can't due to all the controllers being used as v1 in the host kernel. [test case] TBD [regression potential] container, or vm or bare metal, that incorrectly uses cgroupv1, or incorrect use of cgroupv2. [scope] needed only for i and later f and earlier default to cgroupv1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950508/+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 1950496] [NEW] networkd doesn't provide DNS to nspawn containers
Public bug reported: [impact] the host networkd doesn't include DNS info to nspawn containers [test case] create/start a nspawn container, e.g. with 'machinectl start', open a shell in the container, and check resolvectl to see if a nameserver was provided. [regression potential] failures in the host networkd, possibly affecting other host interfaces which are controlled by networkd, or (more likely) failure to provide dhcp to nspawn containers [scope] TBD ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Affects: systemd (Ubuntu Focal) Importance: Medium Assignee: Dan Streetman (ddstreet) Status: In Progress ** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Focal) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Focal) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1950496 Title: networkd doesn't provide DNS to nspawn containers Status in systemd package in Ubuntu: New Status in systemd source package in Focal: In Progress Bug description: [impact] the host networkd doesn't include DNS info to nspawn containers [test case] create/start a nspawn container, e.g. with 'machinectl start', open a shell in the container, and check resolvectl to see if a nameserver was provided. [regression potential] failures in the host networkd, possibly affecting other host interfaces which are controlled by networkd, or (more likely) failure to provide dhcp to nspawn containers [scope] TBD To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1950496/+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 1949089] Re: systemd randomly fails to activate mount units in Ubuntu Core 18
> and in QEMU it seems that this bug is not reproducible can you provide steps on how this is reproducable then? -- 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/1949089 Title: systemd randomly fails to activate mount units in Ubuntu Core 18 Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: New Bug description: Since a month or so, we've been seeing random failures in our snapd spread tests where systemd could not start the mount unit associated with a snap because of a failed dependency. The issue is described in the comments to PR https://github.com/snapcore/snapd/pull/10935, but I'll summarize it here. When starting a snap, snapd creates a mount unit to mount the snap's squashfs (the template is https://github.com/snapcore/snapd/blob/release/2.53/systemd/systemd.go#L1186-L1205). The snapd asks systemd to reload the configuration, and starts the mount unit. The failure we've observed is that sometimes systemd decides to stop our mount unit (search for "Unmounting Mount unit for test-snapd-svc- flip-flop" in the attached log), and then tries to reactivate it again, and at that point it fails. When I asked for help, Lukas pointed out that the latest update contains a patch that is related to reload handling and mount units: http://launchpadlibrarian.net/555420796/systemd_237-3ubuntu10.51_237-3ubuntu10.52.diff.gz (the patch itself is better visible at https://github.com/systemd/systemd/commit/f0831ed2a03fcef582660be1c3b1a9f3e267e656). When looking at the systemd git log, though, I noticed another patch that was applied shortly after this one, which also seems related but was not backported: https://github.com/systemd/systemd/commit/04eb582acc203eab0bc5c2cc5e13986f16e09df0 Since the stopping of our mount unit happens immediately after a systemd reload, it actually seems very likely that the inclusion of f0831ed2a03fcef582660be1c3b1a9f3e267e656 in the systemd update is what causes our woes (though, indeed, the issue is not reliably reproducible, so we cannot be sure). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1949089/+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 1949970] Re: attempt to dlopen nonexistent pam_kwallet.so spams log
** Also affects: lightdm (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: lightdm (Ubuntu Bionic) Importance: Undecided => Low -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1949970 Title: attempt to dlopen nonexistent pam_kwallet.so spams log Status in lightdm package in Ubuntu: New Status in lightdm source package in Bionic: New Status in lightdm source package in Focal: New Status in lightdm source package in Hirsute: New Status in lightdm source package in Impish: New Status in lightdm source package in Jammy: New Bug description: [impact] lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet which died around Trusty (https://launchpad.net/ubuntu/+source/pam- kwallet) while pam_kwallet5.so comes from kwallet-pam which provides only the newer '5' version, not the older unversioned library file. This results in repeated spam error messages in the system log complaining about failure to load pam_kwallet.so [test case] install/enable lightdm and check system log at boot for messages like: Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so [regression potential] any regression would likely cause problems during login and/or missing or extra log messages during pam authentication. [scope] this is needed in all releases [other info] https://github.com/canonical/lightdm/pull/216 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1949970/+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 1949970] Re: attempt to dlopen nonexistent pam_kwallet.so spams log
** Description changed: [impact] lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet which died around Trusty (https://launchpad.net/ubuntu/+source/pam- kwallet) while pam_kwallet5.so comes from kwallet-pam which provides only the newer '5' version, not the older unversioned library file. This results in repeated spam error messages in the system log complaining about failure to load pam_kwallet.so [test case] install/enable lightdm and check system log at boot for messages like: Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so [regression potential] any regression would likely cause problems during login and/or missing or extra log messages during pam authentication. [scope] this is needed in all releases + + [other info] + + https://github.com/canonical/lightdm/pull/216 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1949970 Title: attempt to dlopen nonexistent pam_kwallet.so spams log Status in lightdm package in Ubuntu: New Status in lightdm source package in Focal: New Status in lightdm source package in Hirsute: New Status in lightdm source package in Impish: New Status in lightdm source package in Jammy: New Bug description: [impact] lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet which died around Trusty (https://launchpad.net/ubuntu/+source/pam- kwallet) while pam_kwallet5.so comes from kwallet-pam which provides only the newer '5' version, not the older unversioned library file. This results in repeated spam error messages in the system log complaining about failure to load pam_kwallet.so [test case] install/enable lightdm and check system log at boot for messages like: Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so [regression potential] any regression would likely cause problems during login and/or missing or extra log messages during pam authentication. [scope] this is needed in all releases [other info] https://github.com/canonical/lightdm/pull/216 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1949970/+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 1949970] [NEW] attempt to dlopen nonexistent pam_kwallet.so spams log
Public bug reported: [impact] lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet which died around Trusty (https://launchpad.net/ubuntu/+source/pam- kwallet) while pam_kwallet5.so comes from kwallet-pam which provides only the newer '5' version, not the older unversioned library file. This results in repeated spam error messages in the system log complaining about failure to load pam_kwallet.so [test case] install/enable lightdm and check system log at boot for messages like: Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so [regression potential] any regression would likely cause problems during login and/or missing or extra log messages during pam authentication. [scope] this is needed in all releases ** Affects: lightdm (Ubuntu) Importance: Low Status: New ** Affects: lightdm (Ubuntu Focal) Importance: Low Status: New ** Affects: lightdm (Ubuntu Hirsute) Importance: Low Status: New ** Affects: lightdm (Ubuntu Impish) Importance: Low Status: New ** Affects: lightdm (Ubuntu Jammy) Importance: Low Status: New ** Also affects: lightdm (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: lightdm (Ubuntu Jammy) Importance: Undecided Status: New ** Also affects: lightdm (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: lightdm (Ubuntu Hirsute) Importance: Undecided Status: New ** Changed in: lightdm (Ubuntu Focal) Importance: Undecided => Low ** Changed in: lightdm (Ubuntu Hirsute) Importance: Undecided => Low ** Changed in: lightdm (Ubuntu Impish) Importance: Undecided => Low ** Changed in: lightdm (Ubuntu Jammy) Importance: Undecided => Low -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1949970 Title: attempt to dlopen nonexistent pam_kwallet.so spams log Status in lightdm package in Ubuntu: New Status in lightdm source package in Focal: New Status in lightdm source package in Hirsute: New Status in lightdm source package in Impish: New Status in lightdm source package in Jammy: New Bug description: [impact] lightdm's pam.d config includes an attempt to dlopen pam_kwallet.so as well as pam_kwallet5.so, however pam_wallet.so comes from pam-kwallet which died around Trusty (https://launchpad.net/ubuntu/+source/pam- kwallet) while pam_kwallet5.so comes from kwallet-pam which provides only the newer '5' version, not the older unversioned library file. This results in repeated spam error messages in the system log complaining about failure to load pam_kwallet.so [test case] install/enable lightdm and check system log at boot for messages like: Nov 04 18:17:47 thrain lightdm[2510]: PAM unable to dlopen(pam_kwallet.so): /lib/security/pam_kwallet.so: cannot open shared object file: No such file or directory Nov 04 18:17:47 thrain lightdm[2510]: PAM adding faulty module: pam_kwallet.so [regression potential] any regression would likely cause problems during login and/or missing or extra log messages during pam authentication. [scope] this is needed in all releases To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1949970/+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 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest
> the additional information contains valid data. then I think SRU'ing this would cause a behavior change that could possibly break someone, which isn't something we should do. I'd suggest putting the fix behind some opt-in mechanism, so anyone who is affected can opt-in to the fixed behavior, but there's no change by default. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1940141 Title: OpenSSL servers can send a non-empty status_request in a CertificateRequest Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Bionic: New Bug description: [Impact] openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a CertificateRequest message to the client with a non-empty status_request extension. This issue was fixed in openssl-1.1.1d and is included in Focal onward. Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767 Upstream patch review at https://github.com/openssl/openssl/pull/9780 The issue leads to various client failures with TLS 1.3 as described in, e.g. https://github.com/golang/go/issues/35722 https://github.com/golang/go/issues/34040 [Test Plan] The issue can be reproduced by building with `enable-ssl-trace` and then running `s_server` like this: ``` openssl s_server -key key.pem -cert cert.pem -status_file test/recipes/ocsp-response.der -Verify 5 ``` And running `s_client` like this: ``` openssl s_client -status -trace -cert cert.pem -key key.pem ``` The output shows a `status_request` extension in the `CertificateRequest` as follows: Received Record Header: Version = TLS 1.2 (0x303) Content Type = ApplicationData (23) Length = 1591 Inner Content Type = Handshake (22) CertificateRequest, Length=1570 request_context (len=0): extensions, length = 1567 extension_type=status_request(5), length=1521 - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2 0.. 000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01 0.+.0.. 001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86 0...0.. 002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47 0..1.0...UG ...more lines omitted... If the `status_request` extension is present in a `CertificateRequest` then it must be empty according to RFC8446, Sec. 4.4.2.1. [Where problems could occur] The patch disables the `status_request` extension inside a `CertificateRequest`. Applications expecting the incorrect, non-empty reply for the `status_request` extension will break with this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1948538] Re: USB serial devices not available in /dev/serial/by-id/ after upgrade
> /usr/lib/udev/rules.d/90-pi-bluetooth.rules:14 Invalid value ... rules provided by pi-bluetooth package, not systemd. ** Package changed: systemd (Ubuntu) => pi-bluetooth (Ubuntu) -- 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/1948538 Title: USB serial devices not available in /dev/serial/by-id/ after upgrade Status in pi-bluetooth package in Ubuntu: New Bug description: it looks like systemd-udevd is crashing with the following error: -- Boot a74cfdb7e237433f9321d32ebe70e086 -- Oct 23 13:28:50 Himari systemd-udevd[931]: /usr/lib/udev/rules.d/90-pi-bluetooth.rules:14 Invalid value "/bin/sh -c 'ALIASES=/proc/device-tree/aliases; if cmp -s $ALIASES/uart0 $ALIASES/serial0; then echo 0;elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then echo 1; else exit 1; fi'" for PROGRAM (char 58: invalid substitution type), ignoring, but please fix it. Oct 23 13:28:50 Himari systemd-udevd[931]: /usr/lib/udev/rules.d/90-pi-bluetooth.rules:27 Invalid value "/bin/sh -c 'ALIASES=/proc/device-tree/aliases; if [ -e /dev/ttyAMA0 ]; then exit 1; elif cmp -s $ALIASES/uart0 $ALIASES/serial0; then echo 0;elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then echo 1; else exit 1; fi'" for PROGRAM (char 97: invalid substitution type), ignoring, but please fix it. Oct 23 13:28:50 Himari systemd-udevd[931]: /usr/lib/udev/rules.d/90-pi-bluetooth.rules:38 Invalid value "/bin/sh -c 'ALIASES=/proc/device-tree/aliases; if cmp -s $ALIASES/uart1 $ALIASES/serial0; then echo 0; elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then echo 1; else exit 1; fi '" for PROGRAM (char 58: invalid substitution type), ignoring, but please fix it. I'm not sure if this is related, or a red herring. this is on a raspberry pi 4b 2GB that was recently upgraded from 21.04 to 21.10 ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: udev 248.3-1ubuntu8 ProcVersionSignature: Ubuntu 5.13.0-1008.9-raspi 5.13.14 Uname: Linux 5.13.0-1008-raspi aarch64 ApportVersion: 2.20.11-0ubuntu70 Architecture: arm64 CasperMD5CheckResult: unknown CustomUdevRuleFiles: 70-snap.snapd.rules 70-snap.mjpg-streamer.rules Date: Sat Oct 23 13:31:46 2021 ImageMediaBuild: 20210421.1 Lspci-vt: -[:00]---00.0-[01]00.0 VIA Technologies, Inc. VL805/806 xHCI USB 3.0 Controller Lsusb: Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 1d50:614e OpenMoko, Inc. lpc1769 Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub ProcEnviron: SHELL=/bin/bash LANG=C.UTF-8 TERM=xterm XDG_RUNTIME_DIR= PATH=(custom, user) ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=640 bcm2708_fb.fbheight=480 bcm2708_fb.fbswap=1 smsc95xx.macaddr=DC:A6:32:7C:E6:E5 vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait fixrtc quiet splash SourcePackage: systemd UpgradeStatus: Upgraded to impish on 2021-10-17 (6 days ago) acpidump: To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pi-bluetooth/+bug/1948538/+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 1947708] Re: Cannot configure suspend-then-hibernate
> [ 82.230208] Lockdown: systemd-logind: hibernation is restricted; see man kernel_lockdown.7 you're using UEFI secure boot, which puts the system into 'lockdown', which disallows (unencrypted) hibernation. So this isn't a problem with systemd, this requires the kernel to handle encrypted hibernation. I *think* that functionality isn't yet in the upstream kernel, as I think this thread was the last discussion about adding it: https://lore.kernel.org/lkml/20210220013255.1083202-1-matthewgarr...@google.com/ ** Package changed: systemd (Ubuntu) => linux (Ubuntu) -- 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/1947708 Title: Cannot configure suspend-then-hibernate Status in linux package in Ubuntu: New Bug description: Previous bug 1947617 was closed because my swap space was insufficient. Swap was increased to 24G and the problem remains. Configuring login to suspend-then-hiberrnate when the lid is off and configuring sleep so that hibernate happens 10 seconds after suspend, when trying to test with: sudo systemctl suspend-then-hibernate I get: Failed to suspend system, hibernate later via logind: Sleep verb "suspend-then-hibernate" not supported This could be a security vulnerability. If the user expects the system to suspend (and then lock) when the lid is off and it does not work, somebody could then just reopen the lid and get access. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: systemd 248.3-1ubuntu8 ProcVersionSignature: Ubuntu 5.13.0-19.19-generic 5.13.14 Uname: Linux 5.13.0-19-generic x86_64 ApportVersion: 2.20.11-0ubuntu70 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: i3 Date: Tue Oct 19 11:51:50 2021 InstallationDate: Installed on 2021-10-14 (4 days ago) InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012) MachineType: HP HP ENVY x360 Convertible 13-ay0xxx ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-19-generic root=UUID=e85d08c2-ae82-4f0f-a625-a5012616c934 ro quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /usr/lib/systemd/system/systemd-localed.service → /usr/lib/systemd/system/systemd-localed.service.d/locale-gen.conf [EXTENDED] /usr/lib/systemd/system/user@.service → /usr/lib/systemd/system/user@.service.d/timeout.conf 3 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/30/2021 dmi.bios.release: 15.20 dmi.bios.vendor: Insyde dmi.bios.version: F.20 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 876E dmi.board.vendor: HP dmi.board.version: 12.52 dmi.chassis.asset.tag: Chassis Asset Tag dmi.chassis.type: 31 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.ec.firmware.release: 12.52 dmi.modalias: dmi:bvnInsyde:bvrF.20:bd07/30/2021:br15.20:efr12.52:svnHP:pnHPENVYx360Convertible13-ay0xxx:pvrType1ProductConfigId:sku3V693EA#ABF:rvnHP:rn876E:rvr12.52:cvnHP:ct31:cvrChassisVersion: dmi.product.family: 103C_5335KV HP Envy dmi.product.name: HP ENVY x360 Convertible 13-ay0xxx dmi.product.sku: 3V693EA#ABF dmi.product.version: Type1ProductConfigId dmi.sys.vendor: HP mtime.conffile..etc.systemd.logind.conf: 2021-10-18T18:51:43.976989 mtime.conffile..etc.systemd.sleep.conf: 2021-10-18T18:52:04.283409 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1947708/+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 1947617] Re: Cannot configure suspend-then-hibernate
You have 16G of memory: > [0.081527] Memory: 15609664K/16134968K available But you only seem to have 2G of swap: [2.770354] Adding 2097148k swap on /swapfile There is no way hibernation is possible on your system with this setup. ** Changed in: systemd (Ubuntu) Status: New => Invalid -- 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/1947617 Title: Cannot configure suspend-then-hibernate Status in systemd package in Ubuntu: Invalid Bug description: Configuring login to suspend-then-hiberrnate when the lid is off and configuring sleep so that hibernate happens 10 seconds after suspend, when trying to test with: sudo systemctl suspend-then-hibernate I get: Failed to suspend system, hibernate later via logind: Sleep verb "suspend-then-hibernate" not supported This could be a security vulnerability. If the user expects the system to suspend (and then lock) when the lid is off and it does not work, somebody could then just reopen the lid and get access. ProblemType: Bug DistroRelease: Ubuntu 21.10 Package: systemd 248.3-1ubuntu8 ProcVersionSignature: Ubuntu 5.13.0-19.19-generic 5.13.14 Uname: Linux 5.13.0-19-generic x86_64 ApportVersion: 2.20.11-0ubuntu70 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: i3 Date: Mon Oct 18 18:57:35 2021 InstallationDate: Installed on 2021-10-14 (3 days ago) InstallationMedia: Ubuntu 21.10 "Impish Indri" - Release amd64 (20211012) MachineType: HP HP ENVY x360 Convertible 13-ay0xxx ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.13.0-19-generic root=UUID=e85d08c2-ae82-4f0f-a625-a5012616c934 ro quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /usr/lib/systemd/system/systemd-localed.service → /usr/lib/systemd/system/systemd-localed.service.d/locale-gen.conf [EXTENDED] /usr/lib/systemd/system/user@.service → /usr/lib/systemd/system/user@.service.d/timeout.conf 3 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 07/30/2021 dmi.bios.release: 15.20 dmi.bios.vendor: Insyde dmi.bios.version: F.20 dmi.board.asset.tag: Type2 - Board Asset Tag dmi.board.name: 876E dmi.board.vendor: HP dmi.board.version: 12.52 dmi.chassis.asset.tag: Chassis Asset Tag dmi.chassis.type: 31 dmi.chassis.vendor: HP dmi.chassis.version: Chassis Version dmi.ec.firmware.release: 12.52 dmi.modalias: dmi:bvnInsyde:bvrF.20:bd07/30/2021:br15.20:efr12.52:svnHP:pnHPENVYx360Convertible13-ay0xxx:pvrType1ProductConfigId:sku3V693EA#ABF:rvnHP:rn876E:rvr12.52:cvnHP:ct31:cvrChassisVersion: dmi.product.family: 103C_5335KV HP Envy dmi.product.name: HP ENVY x360 Convertible 13-ay0xxx dmi.product.sku: 3V693EA#ABF dmi.product.version: Type1ProductConfigId dmi.sys.vendor: HP mtime.conffile..etc.systemd.logind.conf: 2021-10-18T18:51:43.976989 mtime.conffile..etc.systemd.sleep.conf: 2021-10-18T18:52:04.283409 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1947617/+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 1934393] Re: systemd-logind network access is blocked, and breaks remote authentication configurations
Ok let's go with option #1 then, just open up systemd-logind to network access directly by editing the service file. @mbiebl, do you want to patch this in Debian too, should I open a merge request in salsa? Obviously if Debian is patched first, that's ideal. Assuming you're ok with directly patching systemd-logind to open network access, instead of putting a drop-in file in the nis package. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1934393 Title: systemd-logind network access is blocked, and breaks remote authentication configurations Status in systemd: Fix Released Status in nis package in Ubuntu: Confirmed Status in openldap package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Status in nis package in Debian: Fix Released Bug description: [impact] starting in focal, systemd-logind runs sandboxed without any network access, which breaks any configuration that uses remote servers for user data, e.g. ldap, nis, etc A more full discussion is available in the upstream bug report as well as the debian bug report, see other info section below [test case] many possible ways to reproduce this; there are reproducers in some of the bugs reported before that are caused by this, e.g. bug 1915502 or bug 1916235 [regression potential] failure to authenticate when using remote user data, incorrect authentication, security issues due to un-sandboxing of systemd-logind [scope] this is needed in f and later before focal, systemd-logind was not sandboxed so this did not apply [other info] this isn't actually a bug in systemd, this is a by-design security feature; see links below (and/or comment 13 in this bug) to upstream comments about how systemd's position is that no NSS module should ever perform network access, and any NSS module that does needs to also adjust the restrictions of systemd services such as systemd-logind, systemd-userdbd, and possibly others that might need to make NSS calls into glibc. https://github.com/systemd/systemd/issues/7074#issuecomment-338157851 https://github.com/systemd/systemd/issues/15705#issuecomment-624125354 this may also can cause systemd-udevd failures in some cases as well. https://github.com/systemd/systemd/pull/7343#issuecomment-344800313 For reference, upstream discussion around the systemd-logind sandboxing specifically: https://github.com/systemd/systemd/issues/7074 upstream updated doc PR explaining the upstream position: https://github.com/systemd/systemd/pull/7343 Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625 Note that while this Debian bug is marked as fix released, I don't think it actually fixes the problem, from the final comment it seems like the only change was to add Recommends: nscd, which doesn't really solve things if someone doesn't use nscd. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1934393/+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 1945225] Re: udev produces unpredictable net names when PCI device is a bridge
> I like the idea of the kernel command line argument because it is easy to apply and consistent across install types. I agree the kernel boot param is absolutely easier, especially in the context of maas. TL;DR from me is: I think it's at least worth looking at using a link file, or some other simpler method for this specific situation/hardware; if that's significantly more work and/or more complex, I'm +1 on this MR. For more detail; my main objection to the MR is 2 things: 1) it would (in very limited situations) change the interface naming for anyone who is manually setting net-naming to 'latest' (which can be done either with a boot param, or editing the env var used by systemd-udevd). Why would anyone manually set that? I don't know for sure, since it is (and as you say, has long been) the default for ubuntu builds of systemd, but of course that's exactly the requirement for anyone to actually use the change introduced by the MR, so it's possible. 2) it doesn't actually fix this for anyone currently experiencing the problem; they would have to know about this change, and then take the extra step of manually setting the net-naming. So this really is a change that primarily benefits a very limited group of possibly affected users. Note that I don't think #2 is necessarily a blocker; I've done exactly that before, e.g. bug 304393. I do think your backport of the v247 naming scheme is the best way to handle this *if* there is no other way to address it (that isn't significantly more painful). -- 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/1945225 Title: udev produces unpredictable net names when PCI device is a bridge Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Status in systemd source package in Hirsute: Fix Released Status in systemd source package in Impish: Fix Released Bug description: [Impact] udev can produce unpredictable network interface names by default when multiple devices map to the same slot due to an intermediate bridge. On an Nvidia DGX2 system, I see the following when booting a system with udev 245.4-4ubuntu3.13: ubuntu@akis:~$ ls /sys/class/net enp134s0f0 enp6s0 ens103 ens107 eth3 eth9 enp134s0f1 ens102 ens106 eth1eth7 lo For each ens* device, there is a sibling eth* device that maps to the same slot because both devices are behind the same bridge. Unpredictable names present well known problems, but I'll describe a specific issue I'm having. We currently do automated network testing that MAAS deploys a system and then configures 2 specific NICs on the system. While MAAS does take care to always restore the names used during commissioning (eth3 will always be the same NIC on every deploy), these names can change each time the system is commissioned. So today we need to go in and edit the NIC names manually in MAAS any time the system is re-commissioned. [Test Case] Boot with kernel option net.naming-scheme=v247; verify that all network interfaces receive predictable names. [Fix] This issue was addressed upstream by adding a new v247 naming scheme that detects this scenario and disables usage of slot-based names for these devices. Obviously changing the default naming scheme in a released LTS series could break users. However, we could introduce the v247 scheme in a focal SRU, and keep the default scheme of v245 (via -Ddefault-net-naming-scheme=v245). Users impacted by this could then opt-in to the v247 scheme by passing net.naming-scheme=v247 or net.naming-scheme=latest on the kernel command line. I could add this to DGX2 systems via a kernel_opts MAAS tag to always get predictable names during commissioning. [Regression Risk] This would change the behavior of any users who select net.naming-scheme=latest, since the latest will now be v247 and not v245. I'm not sure why an existing Ubuntu user would be doing that though - AFAICT, Ubuntu currently always defaults to the latest scheme. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1945225/+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 1945225] Re: udev produces unpredictable net names when PCI device is a bridge
> how would one insert such a file during (and early enough) in the commissioning process? well, i'll leave that one up to the maas team to answer properly, but i think there are ways to use custom commissioning scripts: https://maas.io/docs/commissioning-scripts-reference or even custom commissioning images: https://maas.io/docs/image-builder -- 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/1945225 Title: udev produces unpredictable net names when PCI device is a bridge Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Status in systemd source package in Hirsute: Fix Released Status in systemd source package in Impish: Fix Released Bug description: [Impact] udev can produce unpredictable network interface names by default when multiple devices map to the same slot due to an intermediate bridge. On an Nvidia DGX2 system, I see the following when booting a system with udev 245.4-4ubuntu3.13: ubuntu@akis:~$ ls /sys/class/net enp134s0f0 enp6s0 ens103 ens107 eth3 eth9 enp134s0f1 ens102 ens106 eth1eth7 lo For each ens* device, there is a sibling eth* device that maps to the same slot because both devices are behind the same bridge. Unpredictable names present well known problems, but I'll describe a specific issue I'm having. We currently do automated network testing that MAAS deploys a system and then configures 2 specific NICs on the system. While MAAS does take care to always restore the names used during commissioning (eth3 will always be the same NIC on every deploy), these names can change each time the system is commissioned. So today we need to go in and edit the NIC names manually in MAAS any time the system is re-commissioned. [Test Case] Boot with kernel option net.naming-scheme=v247; verify that all network interfaces receive predictable names. [Fix] This issue was addressed upstream by adding a new v247 naming scheme that detects this scenario and disables usage of slot-based names for these devices. Obviously changing the default naming scheme in a released LTS series could break users. However, we could introduce the v247 scheme in a focal SRU, and keep the default scheme of v245 (via -Ddefault-net-naming-scheme=v245). Users impacted by this could then opt-in to the v247 scheme by passing net.naming-scheme=v247 or net.naming-scheme=latest on the kernel command line. I could add this to DGX2 systems via a kernel_opts MAAS tag to always get predictable names during commissioning. [Regression Risk] This would change the behavior of any users who select net.naming-scheme=latest, since the latest will now be v247 and not v245. I'm not sure why an existing Ubuntu user would be doing that though - AFAICT, Ubuntu currently always defaults to the latest scheme. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1945225/+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 1945225] Re: udev produces unpredictable net names when PCI device is a bridge
> udev can produce unpredictable network interface names by default when multiple devices map to the same slot due to an intermediate bridge. so, if I understand it right, the MR won't actually fix this for anyone without additional per-system work, right? specifically, any system with this problem will need to also add the 'net.naming-scheme=latest' boot parameter (or set it via systemd-udevd env var). If that's the case, then it seems like a much simpler manual workaround for this would be to just avoid slot naming for the problematic nics, for example by dropping a link file into /etc/systemd/network/ with content like: [Match] Driver="whatever driver the DGX nics use, or use some other specific match" [Link] NamePolicy=keep kernel database onboard path AlternativeNamesPolicy=database onboard path MACAddressPolicy=persistent essentially, override the 99-default.link to remove 'slot' naming. > While MAAS does take care to always restore the names used during commissioning (eth3 will always be the same NIC on every deploy), these names can change each time the system is commissioned. if the only change needed is during maas comissioning, that seems like the perfect time to use a link file to override the specific problematic nics by whatever matching logic is best. -- 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/1945225 Title: udev produces unpredictable net names when PCI device is a bridge Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Status in systemd source package in Hirsute: Fix Released Status in systemd source package in Impish: Fix Released Bug description: [Impact] udev can produce unpredictable network interface names by default when multiple devices map to the same slot due to an intermediate bridge. On an Nvidia DGX2 system, I see the following when booting a system with udev 245.4-4ubuntu3.13: ubuntu@akis:~$ ls /sys/class/net enp134s0f0 enp6s0 ens103 ens107 eth3 eth9 enp134s0f1 ens102 ens106 eth1eth7 lo For each ens* device, there is a sibling eth* device that maps to the same slot because both devices are behind the same bridge. Unpredictable names present well known problems, but I'll describe a specific issue I'm having. We currently do automated network testing that MAAS deploys a system and then configures 2 specific NICs on the system. While MAAS does take care to always restore the names used during commissioning (eth3 will always be the same NIC on every deploy), these names can change each time the system is commissioned. So today we need to go in and edit the NIC names manually in MAAS any time the system is re-commissioned. [Test Case] Boot with kernel option net.naming-scheme=v247; verify that all network interfaces receive predictable names. [Fix] This issue was addressed upstream by adding a new v247 naming scheme that detects this scenario and disables usage of slot-based names for these devices. Obviously changing the default naming scheme in a released LTS series could break users. However, we could introduce the v247 scheme in a focal SRU, and keep the default scheme of v245 (via -Ddefault-net-naming-scheme=v245). Users impacted by this could then opt-in to the v247 scheme by passing net.naming-scheme=v247 or net.naming-scheme=latest on the kernel command line. I could add this to DGX2 systems via a kernel_opts MAAS tag to always get predictable names during commissioning. [Regression Risk] This would change the behavior of any users who select net.naming-scheme=latest, since the latest will now be v247 and not v245. I'm not sure why an existing Ubuntu user would be doing that though - AFAICT, Ubuntu currently always defaults to the latest scheme. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1945225/+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 1940715] Re: systemd-resolved restricts edns0 advertised max size to 512
** Bug watch added: github.com/systemd/systemd/issues #20993 https://github.com/systemd/systemd/issues/20993 ** Also affects: systemd via https://github.com/systemd/systemd/issues/20993 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/1940715 Title: systemd-resolved restricts edns0 advertised max size to 512 Status in systemd: Unknown Status in systemd package in Ubuntu: New Status in systemd source package in Bionic: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Hirsute: In Progress Status in systemd source package in Impish: New Bug description: [impact] when talking to upstream nameservers, systemd-resolved limits its advertised max packet size as 512 in its edns0 opt. However, one of the primary benefits of edns0 is to allow using packet sizes larger than 512, which is the pre-edns0 max packet size. this results in systemd-resolved failing to handle responses larger than 512 with udp/edns0, and having to fall back to tcp. This is not optimal (since tcp dns imposes significantly higher overhead) and may even cause failures, if a firewall allows udp dns but blocks tcp dns traffic. [test case] enable debug logging in systemd-resolved, with 'sudo systemctl edit systemd-resolved' and then add: [Service] Environment=SYSTEMD_LOG_LEVEL=debug then save that file and restart systemd-resolved (or reboot). Make sure to flush the cache and reset server features before reproducing: $ sudo resolvectl flush-caches $ sudo resolvectl reset-server-features Lookup 'toomany.ddstreet.org' and check systemd-resolved logs to see if it used TCP fallback or not: ... Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Reply truncated, retrying via TCP. ... Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Verified we get a response at feature level TCP from DNS server 10.202.51.1. Aug 24 12:17:48 lp1940715-f systemd-resolved[1199]: Added positive unauthenticated cache entry for toomany.ddstreet.org IN A 1799s on eth0/INET/10.202.51.1 A correct lookup using larger EDNS0 response size looks like: ... Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Using feature level UDP+EDNS0 for transaction 43808. Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Using DNS server 10.202.51.1 for transaction 43808. Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Announcing packet size 1472 in egress EDNS(0) packet. Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Emitting UDP, link MTU is 1500, socket MTU is 0, minimal MTU is 40 Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Sending query packet with id 43808 of size 49. Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Processing query... Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Received dns UDP packet of size 689, ifindex=131, ttl=0, fragsize=0 Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Processing incoming packet of size 689 on transaction 43808 (rcode=SUCCESS). Aug 24 12:28:13 lp1940715-f systemd-resolved[174]: Added positive unauthenticated non-confidential cache entry for toomany.ddstreet.org IN A 1175s on eth0/INET/10.202.51.1 ... [regression potential] failure to correctly look up dns records, or other problems while performing dns lookups with systemd-resolved [scope] this is needed for all releases this still needs fixing upstream: https://github.com/systemd/systemd/pull/20528 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1940715/+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 1946086] Re: systemd user daemon fails with Permission denied when creating transient scope
*** This bug is a duplicate of bug 1742804 ***
https://bugs.launchpad.net/bugs/1742804
** This bug has been marked a duplicate of bug 1742804
Failed to add PIDs to scope's control group
--
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/1946086
Title:
systemd user daemon fails with Permission denied when creating
transient scope
Status in systemd package in Ubuntu:
Confirmed
Bug description:
Observed on 18.04. Systemd user instance fails when trying to create a
transient scope when logged in through ssh as a regular user
Specifically this fails:
$ systemd-run --user --scope ls
Job for run-rc78f932ad730440490bd7bc17f9d5c8c.scope failed.
See "systemctl status run-rc78f932ad730440490bd7bc17f9d5c8c.scope" and
"journalctl -xe" for details.
Inspecting journal shows:
Oct 05 10:38:16 ubuntu systemd[1437]:
run-rc78f932ad730440490bd7bc17f9d5c8c.scope: Failed to add PIDs to scope's
control group: Permission denied
Oct 05 10:38:16 ubuntu systemd[1437]:
run-rc78f932ad730440490bd7bc17f9d5c8c.scope: Failed with result 'resources'.
Oct 05 10:38:16 ubuntu systemd[1437]: Failed to start /bin/ls.
Oct 05 10:38:16 ubuntu polkitd(authority=local)[1244]: Unregistered
Authentication Agent for unix-process:7425:200857 (system bus name :1.106,
object path /org/freedesktop/PolicyKit1/AuthenticationAgent, locale
en_US.UTF-8) (disconnected from bus)
Further strace shows that there is an EACCES when writing the PID of the
forked process to cgroup procs:
1437 openat(AT_FDCWD,
"/sys/fs/cgroup/pids/user.slice/user-999.slice/user@999.service/run-r067b0361ac97410886bbb3eec1c3848d.scope/pids.max",
O_WRONLY|O_NOCTTY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
1437 newfstatat(AT_FDCWD, "/sys/fs/cgroup/unified", {st_dev=makedev(0, 32),
st_ino=1, st_mode=S_IFDIR|0555, st_nlink=5, st_uid=0, st_gid=0,
st_blksize=4096, st_blocks=0, st_size=0, st_atime=1633428300 /*
2021-10-05T10:05:00.33600+ */, st_atime_nsec=33600,
st_mtime=1633428300 /* 2021-10-05T10:05:00.33600+ */,
st_mtime_nsec=33600, st_ctime=1633428300 /*
2021-10-05T10:05:00.33600+ */, st_ctime_nsec=33600},
AT_SYMLINK_NOFOLLOW) = 0
1437 openat(AT_FDCWD,
"/sys/fs/cgroup/unified/user.slice/user-999.slice/user@999.service/run-r067b0361ac97410886bbb3eec1c3848d.scope/cgroup.procs",
O_WRONLY|O_NOCTTY|O_CLOEXEC) = 34
1437 fcntl(34, F_GETFL)= 0x8001 (flags O_WRONLY|O_LARGEFILE)
1437 fstat(34, {st_dev=makedev(0, 32), st_ino=2358, st_mode=S_IFREG|0644,
st_nlink=1, st_uid=999, st_gid=999, st_blksize=4096, st_blocks=0, st_size=0,
st_atime=1633430486 /* 2021-10-05T10:41:26.701277147+ */,
st_atime_nsec=701277147, st_mtime=1633430486 /*
2021-10-05T10:41:26.701277147+ */, st_mtime_nsec=701277147,
st_ctime=1633430486 /* 2021-10-05T10:41:26.701277147+ */,
st_ctime_nsec=701277147}) = 0
1437 write(34, "7461\n", 5)= -1 EACCES (Permission denied)
1437 close(34) = 0
Full strace of the failed attempt:
https://paste.ubuntu.com/p/4vwtYQ7mww/
When executing the same command from a gnome terminal, the scope is
created successfuly. Full trace of successful execution:
https://paste.ubuntu.com/p/XjJ8mfxSXn/
The relevant bit from the happy execution path:
openat(AT_FDCWD,
"/sys/fs/cgroup/pids/user.slice/user-999.slice/user@999.service/run-rd9ebe0f0326b482e82ca374c5ae613cd.scope/pids.max",
O_WRONLY|O_NOCTTY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
newfstatat(AT_FDCWD, "/sys/fs/cgroup/unified", {st_dev=makedev(0, 32),
st_ino=1, st_mode=S_IFDIR|0555, st_nlink=5, st_uid=0, st_gid=0,
st_blksize=4096, st_blocks=0, st_size=0, st_atime=1633428300 /*
2021-10-05T10:05:00.33600+ */, st_atime_nsec=33600,
st_mtime=1633428300 /* 2021-10-05T10:05:00.33600+ */,
st_mtime_nsec=33600, st_ctime=1633428300 /*
2021-10-05T10:05:00.33600+ */, st_ctime_nsec=33600},
AT_SYMLINK_NOFOLLOW) = 0
openat(AT_FDCWD,
"/sys/fs/cgroup/unified/user.slice/user-999.slice/user@999.service/run-rd9ebe0f0326b482e82ca374c5ae613cd.scope/cgroup.procs",
O_WRONLY|O_NOCTTY|O_CLOEXEC) = 34
fcntl(34, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE)
fstat(34, {st_dev=makedev(0, 32), st_ino=2298, st_mode=S_IFREG|0644,
st_nlink=1, st_uid=999, st_gid=999, st_blksize=4096, st_blocks=0, st_size=0,
st_atime=1633429609 /* 2021-10-05T10:26:49.619626843+ */,
st_atime_nsec=619626843, st_mtime=1633429609 /*
2021-10-05T10:26:49.619626843+ */, st_mtime_nsec=619626843,
st_ctime=1633429609 /* 2021-10-05T10:26:49.619626843+ */,
st_ctime_nsec=619626843}) = 0
write(34, "7410\n", 5) = 5
close(34) = 0
23838 write(31, "24075\n", 6) = -1 EACCES (Permission
denied)
$ lsb_release -rd
[Touch-packages] [Bug 1940141] Re: OpenSSL servers can send a non-empty status_request in a CertificateRequest
for later reference, i'd discussed this with nick and asked him to check if the 'status_request' reply contained any kind of valid data in the specific cases where this patch will disable it; my concern is if there is valid data in it, it's possible there are applications out there that might currently expect and/or use it, even if it's against the RFC, which might result in a regression after this patch. However, if the reply is empty or just has garbage, it's unlikely that any application is using it for anything currently, so there would be less chance of causing a regression. ** Tags added: sts-sponsor-ddstreet -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1940141 Title: OpenSSL servers can send a non-empty status_request in a CertificateRequest Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Bionic: New Bug description: [Impact] openssl does not conform to RFC8446, Sec. 4.4.2.1., by sending a CertificateRequest message to the client with a non-empty status_request extension. This issue was fixed in openssl-1.1.1d and is included in Focal onward. Upstream issue is tracked at https://github.com/openssl/openssl/issues/9767 Upstream patch review at https://github.com/openssl/openssl/pull/9780 The issue leads to various client failures with TLS 1.3 as described in, e.g. https://github.com/golang/go/issues/35722 https://github.com/golang/go/issues/34040 [Test Plan] The issue can be reproduced by building with `enable-ssl-trace` and then running `s_server` like this: ``` openssl s_server -key key.pem -cert cert.pem -status_file test/recipes/ocsp-response.der -Verify 5 ``` And running `s_client` like this: ``` openssl s_client -status -trace -cert cert.pem -key key.pem ``` The output shows a `status_request` extension in the `CertificateRequest` as follows: Received Record Header: Version = TLS 1.2 (0x303) Content Type = ApplicationData (23) Length = 1591 Inner Content Type = Handshake (22) CertificateRequest, Length=1570 request_context (len=0): extensions, length = 1567 extension_type=status_request(5), length=1521 - 01 00 05 ed 30 82 05 e9-0a 01 00 a0 82 05 e2 0.. 000f - 30 82 05 de 06 09 2b 06-01 05 05 07 30 01 01 0.+.0.. 001e - 04 82 05 cf 30 82 05 cb-30 82 01 1a a1 81 86 0...0.. 002d - 30 81 83 31 0b 30 09 06-03 55 04 06 13 02 47 0..1.0...UG ...more lines omitted... If the `status_request` extension is present in a `CertificateRequest` then it must be empty according to RFC8446, Sec. 4.4.2.1. [Where problems could occur] The patch disables the `status_request` extension inside a `CertificateRequest`. Applications expecting the incorrect, non-empty reply for the `status_request` extension will break with this patch. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1940141/+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 1945066] Re: package udev 245.4-4ubuntu3.11 failed to install/upgrade: installed udev package post-installation script subprocess returned error exit status 1
your system has kernel warnings and hung task errors, and you appear to be using an unsupported 5.9 kernel, it seems the problem is there, not with systemd/udevd. ** Package changed: systemd (Ubuntu) => linux (Ubuntu) ** Changed in: linux (Ubuntu) Status: New => Invalid -- 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/1945066 Title: package udev 245.4-4ubuntu3.11 failed to install/upgrade: installed udev package post-installation script subprocess returned error exit status 1 Status in linux package in Ubuntu: Invalid Bug description: The error explains itself, I think. Best regards. ProblemType: Package DistroRelease: Ubuntu 20.04 Package: udev 245.4-4ubuntu3.11 Uname: Linux 5.9.10-050910-generic x86_64 NonfreeKernelModules: nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu27.18 AptOrdering: udev:amd64: Install libudev1:amd64: Install libudev1:amd64: Configure NULL: ConfigurePending Architecture: amd64 CasperMD5CheckResult: skip CustomUdevRuleFiles: 70-snap.stellarium-daily.rules 70-snap.hw-probe.rules 70-snap.snapd.rules 70-snap.snap-store.rules 70-snap.zoom-client.rules 70-snap.acestreamplayer.rules 70-snap.brave.rules Date: Sat Sep 25 16:37:14 2021 ErrorMessage: installed udev package post-installation script subprocess returned error exit status 1 InstallationDate: Installed on 2020-11-06 (323 days ago) InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Release amd64 (20200423) MachineType: LENOVO 82B5 ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.9.10-050910-generic root=UUID=4ebadc28-5f91-4ef7-84ea-9f51b6e6b941 ro quiet splash amdgpu.exp_hw_support=1 vt.handoff=7 Python3Details: /usr/bin/python3.8, Python 3.8.10, python3-minimal, 3.8.2-0ubuntu2 PythonDetails: N/A RelatedPackageVersions: dpkg 1.19.7ubuntu3 apt 2.0.4 SourcePackage: systemd Title: package udev 245.4-4ubuntu3.11 failed to install/upgrade: installed udev package post-installation script subprocess returned error exit status 1 UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 01/01/2021 dmi.bios.release: 1.31 dmi.bios.vendor: LENOVO dmi.bios.version: EUCN31WW dmi.board.asset.tag: NO Asset Tag dmi.board.name: LNVNB161216 dmi.board.vendor: LENOVO dmi.board.version: SDK0J40709 WIN dmi.chassis.asset.tag: NO Asset Tag dmi.chassis.type: 10 dmi.chassis.vendor: LENOVO dmi.chassis.version: Lenovo Legion 5 15ARH05 dmi.ec.firmware.release: 1.31 dmi.modalias: dmi:bvnLENOVO:bvrEUCN31WW:bd01/01/2021:br1.31:efr1.31:svnLENOVO:pn82B5:pvrLenovoLegion515ARH05:rvnLENOVO:rnLNVNB161216:rvrSDK0J40709WIN:cvnLENOVO:ct10:cvrLenovoLegion515ARH05: dmi.product.family: Legion 5 15ARH05 dmi.product.name: 82B5 dmi.product.sku: LENOVO_MT_82B5_BU_idea_FM_Legion 5 15ARH05 dmi.product.version: Lenovo Legion 5 15ARH05 dmi.sys.vendor: LENOVO To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1945066/+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 1944459] Re: systemd-udevd NamePolicy= warning issue
> "ubuntu systemd-udevd[911]: Network interface NamePolicy= disabled on kernel command line, ignoring." yes..you have disabled it on the kernel command line. I don't understand what the bug is here? ** Changed in: systemd (Ubuntu) Status: New => Invalid -- 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/1944459 Title: systemd-udevd NamePolicy= warning issue Status in systemd package in Ubuntu: Invalid Bug description: So I'm getting a warning on syslog: "ubuntu systemd-udevd[911]: Network interface NamePolicy= disabled on kernel command line, ignoring." I've seen another similar report which seems to be fixed back in 2015: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1411992 ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd 245.4-4ubuntu3.13 ProcVersionSignature: Ubuntu 5.4.0-1043.47-raspi 5.4.133 Uname: Linux 5.4.0-1043-raspi armv7l ApportVersion: 2.20.11-0ubuntu27.20 Architecture: armhf CasperMD5CheckResult: skip Date: Tue Sep 21 20:46:59 2021 ImageMediaBuild: 20210819.1 Lspci-vt: -[:00]---00.0-[01]00.0 VIA Technologies, Inc. VL805 USB 3.0 Host Controller Lsusb: Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 003: ID 0bda:2838 Realtek Semiconductor Corp. RTL2838 DVB-T Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Lsusb-t: /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=usbfs, 480M |__ Port 2: Dev 3, If 1, Class=Vendor Specific Class, Driver=, 480M ProcEnviron: TERM=xterm PATH=(custom, no user) LANG=C.UTF-8 SHELL=/bin/bash ProcKernelCmdLine: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 bcm2708_fb.fbwidth=0 bcm2708_fb.fbheight=0 bcm2708_fb.fbswap=1 smsc95xx.macaddr=DC:A6:32:66:9F:A2 vc_mem.mem_base=0x3ec0 vc_mem.mem_size=0x4000 net.ifnames=0 dwc_otg.lpm_enable=0 console=ttyS0,115200 console=tty1 root=LABEL=writable rootfstype=ext4 elevator=deadline rootwait fixrtc fsck.mode=auto fsck.repair=yes ipv6.disable=1 bcm2835_wdt.nowayout=1 bcm2835_wdt.heartbeat=10 quiet splash SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) acpidump: mtime.conffile..etc.systemd.resolved.conf: 2021-09-21T18:08:30.647280 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1944459/+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 1910769] Re: systemd-logind: loss of input devices when logging in after restart
*** This bug is a duplicate of bug 1944711 *** https://bugs.launchpad.net/bugs/1944711 I suspect this is due to bug 1944711, which i'll dup this one to; i know your bug is far older, but since i couldn't reproduce your bug and i'm not sure if it's the same, i didn't want to take it over with the fix for that bug. If that one turns out not to fix this please feel free to un-dup this bug. ** This bug has been marked a duplicate of bug 1944711 restarting systemd-logind loses all existing sessions -- 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/1910769 Title: systemd-logind: loss of input devices when logging in after restart Status in systemd package in Ubuntu: New Bug description: # Steps to reproduce 1) Login as a regular user. 2) `sudo systemctl restart systemd-logind` This boots you back to GDM, as you would expect. 3) Login as a user. 4) Wait a few seconds. # Expected behaviour I can continue to use my system normally. # Actual behaviour My keyboard and mouse stop working; unplugging/replugging has no effect. Everything on screen continues to behave normally. # Debugging Notes I noticed, when Ctrl-Alt-F'ing around trying to figure out what was going on, that there are _two_ GDM sessions apparently running after the logind restart. Furthermore, I logged in on a console (Ctrl-Alt-F2) before performing the restart of logind, and when my keyboard stopped working in my graphical session, typing commands still worked! (I couldn't see this console, obviously, but I tested it by typing `mplayer Music/*/*` and observing music start playing.) ProblemType: Bug DistroRelease: Ubuntu 20.10 Package: systemd 246.6-1ubuntu1 ProcVersionSignature: Ubuntu 5.8.0-36.40-generic 5.8.18 Uname: Linux 5.8.0-36-generic x86_64 NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair nvidia_modeset nvidia ApportVersion: 2.20.11-0ubuntu50.3 Architecture: amd64 CasperMD5CheckResult: skip Date: Fri Jan 8 10:06:56 2021 InstallationDate: Installed on 2019-05-07 (611 days ago) InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210) MachineType: Gigabyte Technology Co., Ltd. B450M DS3H ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.8.0-36-generic root=/dev/mapper/ubuntu--vg-root ro quiet splash resume=UUID=73909634-a75d-42c9-8f66-a69138690756 pcie_aspm=off vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /lib/systemd/system/rc-local.service → /lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /lib/systemd/system/systemd-logind.service → /etc/systemd/system/systemd-logind.service.d/override.conf [EXTENDED] /lib/systemd/system/user@.service → /lib/systemd/system/user@.service.d/timeout.conf 3 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. -- Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: Upgraded to groovy on 2020-06-22 (199 days ago) dmi.bios.date: 01/25/2019 dmi.bios.release: 5.13 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F4 dmi.board.asset.tag: Default string dmi.board.name: B450M DS3H-CF dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: Default string dmi.chassis.type: 3 dmi.chassis.vendor: Default string dmi.chassis.version: Default string dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF4:bd01/25/2019:br5.13:svnGigabyteTechnologyCo.,Ltd.:pnB450MDS3H:pvrDefaultstring:rvnGigabyteTechnologyCo.,Ltd.:rnB450MDS3H-CF:rvrx.x:cvnDefaultstring:ct3:cvrDefaultstring: dmi.product.family: Default string dmi.product.name: B450M DS3H dmi.product.sku: Default string dmi.product.version: Default string dmi.sys.vendor: Gigabyte Technology Co., Ltd. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1910769/+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 1944711] Re: restarting systemd-logind loses all existing sessions
** Changed in: systemd (Ubuntu) Status: New => Fix Released ** Description changed: [impact] restarting the systemd-logind service loses all existing sessions [test case] ubuntu@test-f:~$ loginctl list-sessions - SESSION UID USER SEAT TTY -3789 1000 ubuntu pts/0 + SESSION UID USER SEAT TTY + 3789 1000 ubuntu pts/0 1 sessions listed. ubuntu@test-f:~$ journalctl -b -u systemd-logind -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:22:55 UTC. -- Sep 23 11:22:51 test-f systemd[1]: Starting Login Service... Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0. Sep 23 11:22:51 test-f systemd[1]: Started Login Service. Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu. ubuntu@test-f:~$ sudo systemctl restart systemd-logind ubuntu@test-f:~$ journalctl -b -u systemd-logind -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:23:07 UTC. -- Sep 23 11:22:51 test-f systemd[1]: Starting Login Service... Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0. Sep 23 11:22:51 test-f systemd[1]: Started Login Service. Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu. Sep 23 11:23:07 test-f systemd[1]: Stopping Login Service... Sep 23 11:23:07 test-f systemd[1]: systemd-logind.service: Succeeded. Sep 23 11:23:07 test-f systemd[1]: Stopped Login Service. Sep 23 11:23:07 test-f systemd[1]: Starting Login Service... Sep 23 11:23:07 test-f systemd-logind[469]: Failed to add user by file name 1000, ignoring: Invalid argument Sep 23 11:23:07 test-f systemd-logind[469]: User enumeration failed: Invalid argument Sep 23 11:23:07 test-f systemd-logind[469]: User of session 3789 not known. Sep 23 11:23:07 test-f systemd-logind[469]: Session enumeration failed: No such file or directory Sep 23 11:23:07 test-f systemd-logind[469]: New seat seat0. Sep 23 11:23:07 test-f systemd[1]: Started Login Service. ubuntu@test-f:~$ loginctl list-sessions No sessions. [regression potential] any regression would likely occur during a systemd-logind restart, likely causing a loss of current login sessions. [scope] - this is needed in f and earlier + this is needed only in f this is fixed upstream by commit ac4e03d45bcf4ad2e570cabdb218e9bac003cc80 which is included in v246, so this is fixed in h and later already. + + in b, the function used to parse the /run/systemd/users/* files allows + either usernames or uids, so this bug does not exist there ** Changed in: systemd (Ubuntu Focal) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Focal) Importance: Undecided => High ** Changed in: systemd (Ubuntu Focal) Status: New => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1944711 Title: restarting systemd-logind loses all existing sessions Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: In Progress Bug description: [impact] restarting the systemd-logind service loses all existing sessions [test case] ubuntu@test-f:~$ loginctl list-sessions SESSION UID USER SEAT TTY 3789 1000 ubuntu pts/0 1 sessions listed. ubuntu@test-f:~$ journalctl -b -u systemd-logind -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:22:55 UTC. -- Sep 23 11:22:51 test-f systemd[1]: Starting Login Service... Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0. Sep 23 11:22:51 test-f systemd[1]: Started Login Service. Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu. ubuntu@test-f:~$ sudo systemctl restart systemd-logind ubuntu@test-f:~$ journalctl -b -u systemd-logind -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:23:07 UTC. -- Sep 23 11:22:51 test-f systemd[1]: Starting Login Service... Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0. Sep 23 11:22:51 test-f systemd[1]: Started Login Service. Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu. Sep 23 11:23:07 test-f systemd[1]: Stopping Login Service... Sep 23 11:23:07 test-f systemd[1]: systemd-logind.service: Succeeded. Sep 23 11:23:07 test-f systemd[1]: Stopped Login Service. Sep 23 11:23:07 test-f systemd[1]: Starting Login Service... Sep 23 11:23:07 test-f systemd-logind[469]: Failed to add user by file name 1000, ignoring: Invalid argument Sep 23 11:23:07 test-f systemd-logind[469]: User enumeration failed: Invalid argument Sep 23 11:23:07 test-f systemd-logind[469]: User of session 3789 not known. Sep 23 11:23:07 test-f systemd-logind[469]: Session enumeration failed: No such file or directory Sep 23 11:23:07 test-f systemd-logind[469]: New seat seat0.
[Touch-packages] [Bug 1944711] [NEW] restarting systemd-logind loses all existing sessions
Public bug reported: [impact] restarting the systemd-logind service loses all existing sessions [test case] ubuntu@test-f:~$ loginctl list-sessions SESSION UID USER SEAT TTY 3789 1000 ubuntu pts/0 1 sessions listed. ubuntu@test-f:~$ journalctl -b -u systemd-logind -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:22:55 UTC. -- Sep 23 11:22:51 test-f systemd[1]: Starting Login Service... Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0. Sep 23 11:22:51 test-f systemd[1]: Started Login Service. Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu. ubuntu@test-f:~$ sudo systemctl restart systemd-logind ubuntu@test-f:~$ journalctl -b -u systemd-logind -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:23:07 UTC. -- Sep 23 11:22:51 test-f systemd[1]: Starting Login Service... Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0. Sep 23 11:22:51 test-f systemd[1]: Started Login Service. Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu. Sep 23 11:23:07 test-f systemd[1]: Stopping Login Service... Sep 23 11:23:07 test-f systemd[1]: systemd-logind.service: Succeeded. Sep 23 11:23:07 test-f systemd[1]: Stopped Login Service. Sep 23 11:23:07 test-f systemd[1]: Starting Login Service... Sep 23 11:23:07 test-f systemd-logind[469]: Failed to add user by file name 1000, ignoring: Invalid argument Sep 23 11:23:07 test-f systemd-logind[469]: User enumeration failed: Invalid argument Sep 23 11:23:07 test-f systemd-logind[469]: User of session 3789 not known. Sep 23 11:23:07 test-f systemd-logind[469]: Session enumeration failed: No such file or directory Sep 23 11:23:07 test-f systemd-logind[469]: New seat seat0. Sep 23 11:23:07 test-f systemd[1]: Started Login Service. ubuntu@test-f:~$ loginctl list-sessions No sessions. [regression potential] any regression would likely occur during a systemd-logind restart, likely causing a loss of current login sessions. [scope] this is needed in f and earlier this is fixed upstream by commit ac4e03d45bcf4ad2e570cabdb218e9bac003cc80 which is included in v246, so this is fixed in h and later already. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1944711 Title: restarting systemd-logind loses all existing sessions Status in systemd package in Ubuntu: New Status in systemd source package in Focal: New Bug description: [impact] restarting the systemd-logind service loses all existing sessions [test case] ubuntu@test-f:~$ loginctl list-sessions SESSION UID USER SEAT TTY 3789 1000 ubuntu pts/0 1 sessions listed. ubuntu@test-f:~$ journalctl -b -u systemd-logind -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:22:55 UTC. -- Sep 23 11:22:51 test-f systemd[1]: Starting Login Service... Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0. Sep 23 11:22:51 test-f systemd[1]: Started Login Service. Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu. ubuntu@test-f:~$ sudo systemctl restart systemd-logind ubuntu@test-f:~$ journalctl -b -u systemd-logind -- Logs begin at Thu 2021-09-23 11:11:57 UTC, end at Thu 2021-09-23 11:23:07 UTC. -- Sep 23 11:22:51 test-f systemd[1]: Starting Login Service... Sep 23 11:22:51 test-f systemd-logind[198]: New seat seat0. Sep 23 11:22:51 test-f systemd[1]: Started Login Service. Sep 23 11:22:52 test-f systemd-logind[198]: New session 3789 of user ubuntu. Sep 23 11:23:07 test-f systemd[1]: Stopping Login Service... Sep 23 11:23:07 test-f systemd[1]: systemd-logind.service: Succeeded. Sep 23 11:23:07 test-f systemd[1]: Stopped Login Service. Sep 23 11:23:07 test-f systemd[1]: Starting Login Service... Sep 23 11:23:07 test-f systemd-logind[469]: Failed to add user by file name 1000, ignoring: Invalid argument Sep 23 11:23:07 test-f systemd-logind[469]: User enumeration failed: Invalid argument Sep 23 11:23:07 test-f systemd-logind[469]: User of session 3789 not known. Sep 23 11:23:07 test-f systemd-logind[469]: Session enumeration failed: No such file or directory Sep 23 11:23:07 test-f systemd-logind[469]: New seat seat0. Sep 23 11:23:07 test-f systemd[1]: Started Login Service. ubuntu@test-f:~$ loginctl list-sessions No sessions. [regression potential] any regression would likely occur during a systemd-logind restart, likely causing a loss of current login sessions. [scope] this is needed in f and earlier this is fixed upstream by commit ac4e03d45bcf4ad2e570cabdb218e9bac003cc80 which is included in v246,
[Touch-packages] [Bug 1934393] Re: systemd-logind network access is blocked, and breaks remote authentication configurations
One good point in favor of including systemd-userdbd in Debian/Ubuntu would be that we only need to adjust the restrictions for that service; all other systemd-provided services would use (or at least, *should* use...) systemd-userdbd to get user records. I'm not sure if that is actually worth including and using systemd-userdbd to the distro. Putting that aside for now, I think the only options to fix this all involve removing the systemd-logind restriction(s). The only question seems to be what/who removes the restrictions. 1) We could simply remove the restrictions for systemd-logind in the Debian/Ubuntu package, for everyone. This would (theoretically) reduce the security of systemd-logind by allowing it to access the network, but also it would allow network-based NSS lookups to work in all situations (meaning, for all possible NSS modules, not only NIS and/or select other packages/modules). 2) We could add drop-in files to remove the restrictions for systemd- logind, for the 'nis' package (which I think has been split out in later releases and in Debian, so we'd need to pick the correct client package). We would also need to include drop-in files for any other package that provides an NSS module that needs to perform network lookups, such as the 'libnss-ldap' package (I haven't verified this needs network access but I believe it does, e.g. comment 7 above). 3) We could simply add documentation to the README and/or man pages and/or other docs and leave it up to the system admin to add the systemd-logind drop-in file when they set up NIS or LDAP or whatever other network-based auth provider. Personally, I think #3 is barely better than the current situation; there's just far too many setup guides and other documentation out there for us to expect all Debian/Ubuntu users to notice the additional step we might add to our own docs, even if it's in the package README and man pages. However, if we think that NSS-based network auth services are a thing of the past (as seems to be the upstream position on this), then maybe just adding docs is the right way to handle this. I'm not too enthusiastic about option #2 either. While it would help with users of specific packages, without those users needing to know any specific details about the workaround, it won't cover all use cases - since we don't necessarily know all the different packages that might need to provide a drop-in - and also it could *add* confusion in some cases. For example, if someone is using a custom network-based libnss module, it would work on any system where they had the 'nis' package installed, but fail on any system where it wasn't installed - regardless of whether they are actually using nis for anything at all. That's the kind of thing that is incredibly painful to debug. This option also would require the 'nis' and 'libnss-ldap' packages to restart systemd- logind when they are installed, which (in the past at least) has sometimes been problematic. I know that option #1 is kind of the 'worst', since it essentially just gives up and removes the restriction from systemd-logind for everyone. However, I personally think it's the best option. If/when we do start providing systemd-userdbd (and it's enabled by default), I think we should move the lifted restriction over to it, instead of systemd- logind. But for now we should just modify systemd-logind to allow network access, IMHO. Since this is *theoretically* related to security, I'd like to get the Ubuntu security team's opinion on the change. I've cc'ed them on this bug. @mbiebl, what do you think? I really don't know what the best approach is, either for Debian or for Ubuntu. And obviously, if you (or anyone) has other suggestions I'm happy to hear them. And finally just FTR, I personally think upstream systemd should just remove the restriction (specifically, I mean remove IPAddressDeny=any) from systemd-userdbd.service. That service already funnels all systemd requests for user data into a single isolated process, I think it's overkill to also restrict that process from network access, when it's so common to have NSS-based network authentication mechanisms. However, Lennart's made his opinion known[1], and I'd prefer not to be the person who tries to argue with him to change his mind. [1]: https://github.com/systemd/systemd/issues/15705#issuecomment-624125354 ** Changed in: systemd (Ubuntu) Status: Won't Fix => Confirmed ** Description changed: [impact] starting in focal, systemd-logind runs sandboxed without any network access, which breaks any configuration that uses remote servers for user data, e.g. ldap, nis, etc A more full discussion is available in the upstream bug report as well as the debian bug report, see other info section below [test case] many possible ways to reproduce this; there are reproducers in some of the bugs reported before that are caused by this, e.g. bug 1915502 or bug 1916235 [regression
[Touch-packages] [Bug 1934393] Re: systemd-logind network access is blocked, and breaks remote authentication configurations
** Description changed: [impact] starting in focal, systemd-logind runs sandboxed without any network access, which breaks any configuration that uses remote servers for user data, e.g. ldap, nis, etc A more full discussion is available in the upstream bug report as well as the debian bug report, see other info section below [test case] many possible ways to reproduce this; there are reproducers in some of the bugs reported before that are caused by this, e.g. bug 1915502 or bug 1916235 [regression potential] failure to authenticate when using remote user data, incorrect authentication, security issues due to un-sandboxing of systemd-logind [scope] this is needed in f and later before focal, systemd-logind was not sandboxed so this did not apply [other info] - this isn't actually a bug in systemd, this is a by-design security - feature, and the intended upstream design is for systemd-logind to talk - to systemd-userdb, so that systemd-logind can remain network-sandboxed - while systemd-userdb performs any needed network access for user/auth - data. However, Debian and Ubuntu don't enable/provide systemd-userdb, so - that design does not work for Debian/Ubuntu. + this isn't actually a bug in systemd, this is a by-design security feature; see links below (and/or comment 13 in this bug) to upstream comments about how systemd's position is that no NSS module should ever perform network access, and any NSS module that does needs to also adjust the restrictions of systemd services such as systemd-logind, systemd-userdbd, and possibly others that might need to make NSS calls into glibc. + https://github.com/systemd/systemd/issues/7074#issuecomment-338157851 + https://github.com/systemd/systemd/issues/15705#issuecomment-624125354 - this also can cause systemd-udevd failures in some cases as well, - apparently (based on upstream and debian discussion comments) + this may also can cause systemd-udevd failures in some cases as well. + https://github.com/systemd/systemd/pull/7343#issuecomment-344800313 For reference, upstream discussion around the systemd-logind sandboxing specifically: https://github.com/systemd/systemd/issues/7074 upstream updated doc PR explaining the upstream position: https://github.com/systemd/systemd/pull/7343 Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1934393 Title: systemd-logind network access is blocked, and breaks remote authentication configurations Status in systemd: Fix Released Status in nis package in Ubuntu: Confirmed Status in openldap package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Won't Fix Status in nis package in Debian: Fix Released Bug description: [impact] starting in focal, systemd-logind runs sandboxed without any network access, which breaks any configuration that uses remote servers for user data, e.g. ldap, nis, etc A more full discussion is available in the upstream bug report as well as the debian bug report, see other info section below [test case] many possible ways to reproduce this; there are reproducers in some of the bugs reported before that are caused by this, e.g. bug 1915502 or bug 1916235 [regression potential] failure to authenticate when using remote user data, incorrect authentication, security issues due to un-sandboxing of systemd-logind [scope] this is needed in f and later before focal, systemd-logind was not sandboxed so this did not apply [other info] this isn't actually a bug in systemd, this is a by-design security feature; see links below (and/or comment 13 in this bug) to upstream comments about how systemd's position is that no NSS module should ever perform network access, and any NSS module that does needs to also adjust the restrictions of systemd services such as systemd-logind, systemd-userdbd, and possibly others that might need to make NSS calls into glibc. https://github.com/systemd/systemd/issues/7074#issuecomment-338157851 https://github.com/systemd/systemd/issues/15705#issuecomment-624125354 this may also can cause systemd-udevd failures in some cases as well. https://github.com/systemd/systemd/pull/7343#issuecomment-344800313 For reference, upstream discussion around the systemd-logind sandboxing specifically: https://github.com/systemd/systemd/issues/7074 upstream updated doc PR explaining the upstream position: https://github.com/systemd/systemd/pull/7343 Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1934393/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to :
[Touch-packages] [Bug 1934393] Re: systemd-logind network access is blocked, and breaks remote authentication configurations
> @Dan: have you actually confirmed, that building and running userdbd solves those issues with NIS and LDAP? sorry for the delay in getting back to this. So, you're correct, userdb doesn't actually help this, it only moves the problem. While systemd-userdbd.service does (currently, at least) allow AF_INET and AF_INET6, I missed that it also includes IPAddressDeny=any which results in the problem existing there as well. So if we include systemd-userdbd in Debian/Ubuntu, then the network- restricted systemd-logind problem is simply moved to systemd-userdbd. I will note that I did verify, if systemd-logind is running with its default restrictions and systemd-userdbd is also running without its IPAddressDeny=any restriction, the issue is fixed; systemd-logind does correctly get the user record from NIS through systemd-userdbd. I also seem to have misunderstood Lennart's position on this; after re- reading his statements[1] it seems that his position is that *all* systemd services should be locked down (or at least, both systemd-logind and systemd-userdbd) and the responsibility for poking holes in one (or both, or more) of those services' restrictions is on NIS and any other NSS library that requires network access. So enabling systemd-userdbd won't help with this bug, unless we want to diverge from upstream by removing its IPAddressDeny=any restriction. But we could just as easily remove that from systemd-logind (along with adding AF_INET and AF_INET6 to it). [1]: https://github.com/systemd/systemd/issues/7074#issuecomment-338157851 https://github.com/systemd/systemd/issues/15705#issuecomment-624125354 ** Bug watch added: github.com/systemd/systemd/issues #15705 https://github.com/systemd/systemd/issues/15705 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1934393 Title: systemd-logind network access is blocked, and breaks remote authentication configurations Status in systemd: Fix Released Status in nis package in Ubuntu: Confirmed Status in openldap package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Won't Fix Status in nis package in Debian: Fix Released Bug description: [impact] starting in focal, systemd-logind runs sandboxed without any network access, which breaks any configuration that uses remote servers for user data, e.g. ldap, nis, etc A more full discussion is available in the upstream bug report as well as the debian bug report, see other info section below [test case] many possible ways to reproduce this; there are reproducers in some of the bugs reported before that are caused by this, e.g. bug 1915502 or bug 1916235 [regression potential] failure to authenticate when using remote user data, incorrect authentication, security issues due to un-sandboxing of systemd-logind [scope] this is needed in f and later before focal, systemd-logind was not sandboxed so this did not apply [other info] this isn't actually a bug in systemd, this is a by-design security feature; see links below (and/or comment 13 in this bug) to upstream comments about how systemd's position is that no NSS module should ever perform network access, and any NSS module that does needs to also adjust the restrictions of systemd services such as systemd-logind, systemd-userdbd, and possibly others that might need to make NSS calls into glibc. https://github.com/systemd/systemd/issues/7074#issuecomment-338157851 https://github.com/systemd/systemd/issues/15705#issuecomment-624125354 this may also can cause systemd-udevd failures in some cases as well. https://github.com/systemd/systemd/pull/7343#issuecomment-344800313 For reference, upstream discussion around the systemd-logind sandboxing specifically: https://github.com/systemd/systemd/issues/7074 upstream updated doc PR explaining the upstream position: https://github.com/systemd/systemd/pull/7343 Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1934393/+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 1943990] Re: After updating systemd packages to 245.4-4ubuntu3.13 and libvirt packages to 6.0.0-0ubuntu8.14, it is no longer possible to start kvm virtual machines
you state you have systemd version 245.4-4ubuntu3.13 installed, but your description shows otherwise: Package: systemd-container 245.4-4ubuntu3.11 ** Changed in: systemd (Ubuntu) Status: New => Incomplete -- 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/1943990 Title: After updating systemd packages to 245.4-4ubuntu3.13 and libvirt packages to 6.0.0-0ubuntu8.14, it is no longer possible to start kvm virtual machines Status in systemd package in Ubuntu: Incomplete Bug description: # systemctl status systemd-machined.service ● systemd-machined.service - Virtual Machine and Container Registration Service Loaded: loaded (/lib/systemd/system/systemd-machined.service; static; vendor preset: enabled) Active: inactive (dead) Docs: man:systemd-machined.service(8) https://www.freedesktop.org/wiki/Software/systemd/machined Sep 17 15:40:42 MGL1-SRV-0006 systemd[1]: Dependency failed for Virtual Machine and Container Registration Service. Sep 17 15:40:42 MGL1-SRV-0006 systemd[1]: systemd-machined.service: Job systemd-machined.service/start failed with result 'dependency'. Sep 17 15:42:26 MGL1-SRV-0006 systemd[1]: Dependency failed for Virtual Machine and Container Registration Service. Sep 17 15:42:26 MGL1-SRV-0006 systemd[1]: systemd-machined.service: Job systemd-machined.service/start failed with result 'dependency'. Sep 17 16:02:55 MGL1-SRV-0006 systemd[1]: Dependency failed for Virtual Machine and Container Registration Service. Sep 17 16:02:55 MGL1-SRV-0006 systemd[1]: systemd-machined.service: Job systemd-machined.service/start failed with result 'dependency'. Sep 17 16:04:39 MGL1-SRV-0006 systemd[1]: Dependency failed for Virtual Machine and Container Registration Service. Sep 17 16:04:39 MGL1-SRV-0006 systemd[1]: systemd-machined.service: Job systemd-machined.service/start failed with result 'dependency'. Trying to start a virtual machine from openstack, it defines the machine, but is not able to execute it. I used to have libvirt apparmor errors, but disabling libvirt in apparmor didn't solve the problem: [ 27.785713] audit: type=1400 audit(1631888214.441:67): apparmor="DENIED" operation="capable" profile="libvirtd" pid=4817 comm="libvirtd" capability=17 capname="sys_rawio" ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: systemd-container 245.4-4ubuntu3.11 ProcVersionSignature: Ubuntu 5.11.0-34.36~20.04.1-generic 5.11.22 Uname: Linux 5.11.0-34-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.20 Architecture: amd64 CasperMD5CheckResult: skip Date: Fri Sep 17 16:23:39 2021 SourcePackage: systemd UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1943990/+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 1938259] Re: Add ACCEL_LOCATION=base property for Dell clamshell models
this was marked fix-released for f/h just due to the tooling matching the bug number; this was actually reverted as shown in the changelogs posted in the above comments. I'll just correct f/h to indicate this is wontfix, and a new bug will or has been opened to fix this correctly. ** Changed in: systemd (Ubuntu Hirsute) Status: Fix Released => Won't Fix ** Changed in: systemd (Ubuntu Focal) Status: Fix Released => Won't Fix -- 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/1938259 Title: Add ACCEL_LOCATION=base property for Dell clamshell models Status in OEM Priority Project: Won't Fix Status in systemd package in Ubuntu: Won't Fix Status in systemd source package in Focal: Won't Fix Status in systemd source package in Hirsute: Won't Fix Status in systemd source package in Impish: Won't Fix Bug description: We are planning to do SRU to systemd in focal, to avoid unwanted screen rotations on some Dell laptop models. [Impact] * This fixes unwanted rotations on certain Dell clamshell laptop models with accelerometer. [Test Plan] * On Dell laptops with model SKU 0A3E or 0E0E, install this package and kernel 5.13, or kernel with this patch backported: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e26f023e01ef26b4138bc1099af309bdc4523d23 * Rotate the laptop and the display should not be rotated. [Where problems could occur] * This is to add parameters for certain models in hwdb, and does not affect any other part of systemd. * This fix would only take effect with kernel 5.13 or the above patch backported. [scope] this is needed for all releases this is being fixed upstream by https://github.com/systemd/systemd/pull/20314 [Other info] * The patch mentioned above is going to have a separated SRU for linux-oem-5.10 and linux-hwe-5.11 (LP: #1938143) To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1938259/+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 1939255] Re: dhclient triggers systemd-resolved start limit when processing more than 5 interfaces at once
as systemd was respun (for focal) due to bug 1942899, and only the one udev (hwdb) patch was reverted which shouldn't affect this at all, I'm remarking this as verified still based on testing for the previous version above. ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done 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/1939255 Title: dhclient triggers systemd-resolved start limit when processing more than 5 interfaces at once Status in systemd package in Ubuntu: Invalid Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Bug description: [impact] on a system where systemd-resolved is running, if dhclient is used on more than 5 interfaces, it calls the '/etc/dhcp/dhclient-enter- hooks.d/resolved' script multiple times, which then restarts systemd- resolved multiple times, triggering the unit's start-limit throttle which results in the unit entering failed state [test case] on a system with more than 5 available interfaces to run dhclient on (where all the interfaces will get a dhcp response), run dhclient with the interfaces: $ dhclient ens8 ens9 ens10 ens11 ens12 ens13 ens14 ens15 check if systemd-resolved failed: $ journalctl -b -1 -u systemd-resolved ... Aug 09 00:38:08 sf316232-b systemd[1]: systemd-resolved.service: Start request repeated too quickly. Aug 09 00:38:08 sf316232-b systemd[1]: systemd-resolved.service: Failed with result 'start-limit-hit'. Aug 09 00:38:08 sf316232-b systemd[1]: Failed to start Network Name Resolution. [regression potential] failure to start/stop/restart systemd-resolved, or problems adding dhclient-provided DNS nameservers to systemd-resolved [scope] this is needed only for b/f the dhclient 'hook' script is provided by the systemd package in focal and earlier, and needs fixing in those releases in h and later, the 'hook' script is included in the isc-dhcp-client package and notifies systemd-resolved in a more direct way without requiring restarting, and so doesn't trigger the restart limiting. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1939255/+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 1937238] Re: systemd-time-wait-sync.service stuck in "activating" state after boot, blocks timers from starting
as systemd was respun due to bug 1942899, and only the one udev (hwdb) patch was reverted which shouldn't affect this at all, I'm remarking this as verified still based on testing for the previous version above. ** Tags removed: verification-needed verification-needed-focal ** Tags added: verification-done 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/1937238 Title: systemd-time-wait-sync.service stuck in "activating" state after boot, blocks timers from starting Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Focal: Fix Committed Bug description: [impact] systemd-time-wait-sync service sometimes misses sync completed event and remains in 'activating' state [test case] this isn't consistently reproducable, see original description for test case [regression potential] possible problems with the systemd-time-wait-sync service completing too early or not completing on time [scope] this is needed only for f this is fixed upstream with commit f6f4f5fe5395a57f10dd446c7266c53f0673eaac which is in v246, so this is fixed in h and later already the service does not exist in b so this does not apply there [original description] When I start my server running Ubuntu 20.04 the systemd-time-wait- sync.service is stuck in "activating" state. I noticed this because none of the systemd timer units triggered, because all the timers depend on systemd-time-wait-sync.service. Running "systemctl restart systemd-time-wait-sync.service" manually works around the problem. Some logs and command outputs: raek@mizar:~$ lsb_release -rd Description:Ubuntu 20.04.2 LTS Release:20.04 raek@mizar:~$ systemctl | grep systemd-time-wait-sync.service systemd-time-wait-sync.service loaded activating start start Wait Until Kernel Time Synchronized raek@mizar:~$ systemctl status systemd-time-wait-sync.service ● systemd-time-wait-sync.service - Wait Until Kernel Time Synchronized Loaded: loaded (/lib/systemd/system/systemd-time-wait-sync.service; enabled; vendor preset: enabled) Active: activating (start) since Thu 2021-07-22 11:06:52 CEST; 27min ago Docs: man:systemd-time-wait-sync.service(8) Main PID: 514 (systemd-time-wa) Tasks: 1 (limit: 9415) Memory: 972.0K CGroup: /system.slice/systemd-time-wait-sync.service └─514 /lib/systemd/systemd-time-wait-sync Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 time Thu 2021-07-22 09:06:52.216338 UTC Warning: journal has been rotated since unit was started, output may be incomplete. raek@mizar:~$ journalctl -b -u systemd-time-wait-sync.service -- Logs begin at Wed 2020-07-08 16:34:13 CEST, end at Thu 2021-07-22 11:36:44 CEST. -- Jul 22 11:06:52 mizar systemd-time-wait-sync[514]: adjtime state 5 status 40 time Thu 2021-07-22 09:06:52.216338 UTC raek@mizar:~$ dpkg -S /lib/systemd/system/systemd-time-wait-sync.service systemd: /lib/systemd/system/systemd-time-wait-sync.service raek@mizar:~$ apt-cache policy systemd systemd: Installed: 245.4-4ubuntu3.11 Candidate: 245.4-4ubuntu3.11 Version table: *** 245.4-4ubuntu3.11 500 500 http://se.archive.ubuntu.com/ubuntu focal-security/main amd64 Packages 100 /var/lib/dpkg/status 245.4-4ubuntu3.10 500 500 http://se.archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages 245.4-4ubuntu3.8 400 400 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages 245.4-4ubuntu3 500 500 http://se.archive.ubuntu.com/ubuntu focal/main amd64 Packages To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1937238/+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 1853164] Re: systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error
root@lp1853164-b:~# dpkg -l systemd|grep systemd ii systemd237-3ubuntu10.51 amd64system and service manager root@lp1853164-b:~# dpkg -l | grep -E 'ifupdown|resolvconf' ii ifupdown 0.8.17ubuntu1.1 amd64 high level tools to configure network interfaces ii resolvconf 1.79ubuntu10.18.04.3all name server information handler root@lp1853164-b:~# grep eth0 /etc/network/interfaces auto eth0 iface eth0 inet dhcp root@lp1853164-b:~# ip a show dev eth0 222: eth0@if223: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:16:3e:16:1c:78 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.202.51.62/24 brd 10.202.51.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::216:3eff:fe16:1c78/64 scope link valid_lft forever preferred_lft forever root@lp1853164-b:~# systemctl is-enabled systemd-resolved disabled root@lp1853164-b:~# systemctl is-enabled systemd-networkd disabled root@lp1853164-b:~# cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. root@lp1853164-b:~# root@lp1853164-b:~# dpkg -l systemd|grep systemd ii systemd237-3ubuntu10.52 amd64system and service manager root@lp1853164-b:~# dpkg -l | grep -E 'ifupdown|resolvconf' ii ifupdown 0.8.17ubuntu1.1 amd64 high level tools to configure network interfaces ii resolvconf 1.79ubuntu10.18.04.3all name server information handler root@lp1853164-b:~# grep eth0 /etc/network/interfaces auto eth0 iface eth0 inet dhcp root@lp1853164-b:~# ip a show dev eth0 224: eth0@if225: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 00:16:3e:16:1c:78 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 10.202.51.62/24 brd 10.202.51.255 scope global eth0 valid_lft forever preferred_lft forever inet6 fe80::216:3eff:fe16:1c78/64 scope link valid_lft forever preferred_lft forever root@lp1853164-b:~# systemctl is-enabled systemd-resolved disabled root@lp1853164-b:~# systemctl is-enabled systemd-networkd disabled root@lp1853164-b:~# cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 10.202.51.1 search lxd root@lp1853164-b:~# ** 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/1853164 Title: systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error 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 Released Bug description: [impact] with systemd-resolved disabled, dhclient doesn't correctly notify resolvconf about dns server(s) [test case] install resolvconf and ifupdown and disable systemd-resolved and systemd-networkd, use ifupdown to get a dhcp address where the lease includes a dns nameserver, verify resolvconf is using that dhcp- provided nameserver [regression potential] failure to correctly notify systemd-resolved about new dhclient- provided nameserver(s) [scope] this is needed for f and earlier in g and later the hook script is moved to the isc-dhcp package, and edited to correctly check is-enabled systemd-resolved instead of only checking for the existence of the binary [original description] The functionality exists to allow users to revert to the traditional ifupdown package for network configuration. Alongside this, systemd's often-buggy resolver can be disabled. However, there's a logic error in the systemd- supplied /etc/dhcp/dhclient-enter-hooks.d/resolved that prevents the system from populating /etc/resolv.conf properly when systemd-resolved is disabled. The issue is here: if [ -x /lib/systemd/systemd-resolved ] ; then Instead of checking to see if the systemd-resolved service is enabled or active, which would be the correct behaviour, this checks for the existence of a binary, assuming that if it exists it's supposed to be used. I've not tested this in the absence of resolvconf, but if systemd-resolved isn't enabled, it's difficult to imagine this code wanting to run. I've tested this with resolvconf and ifupdown
[Touch-packages] [Bug 1853164] Re: systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error
as systemd was respun due to bug 1942899, and only the one udev (hwdb)
patch was reverted which shouldn't affect this at all, I'm remarking
this as verified still based on testing for the previous version above.
--
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/1853164
Title:
systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error
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 Released
Bug description:
[impact]
with systemd-resolved disabled, dhclient doesn't correctly notify
resolvconf about dns server(s)
[test case]
install resolvconf and ifupdown and disable systemd-resolved and
systemd-networkd, use ifupdown to get a dhcp address where the lease
includes a dns nameserver, verify resolvconf is using that dhcp-
provided nameserver
[regression potential]
failure to correctly notify systemd-resolved about new dhclient-
provided nameserver(s)
[scope]
this is needed for f and earlier
in g and later the hook script is moved to the isc-dhcp package, and
edited to correctly check is-enabled systemd-resolved instead of only
checking for the existence of the binary
[original description]
The functionality exists to allow users to revert to the traditional ifupdown
package for network configuration. Alongside this, systemd's often-buggy
resolver can be disabled. However, there's a logic error in the systemd-
supplied /etc/dhcp/dhclient-enter-hooks.d/resolved that prevents the system
from populating /etc/resolv.conf properly when systemd-resolved is disabled.
The issue is here:
if [ -x /lib/systemd/systemd-resolved ] ; then
Instead of checking to see if the systemd-resolved service is enabled or
active, which would be the correct behaviour, this checks for the existence of
a binary, assuming that if it exists it's supposed to be used.
I've not tested this in the absence of resolvconf, but if systemd-resolved
isn't enabled, it's difficult to imagine this code wanting to run. I've tested
this with resolvconf and ifupdown driving dhclient, and it corrects the
behaviour that was broken with the introduction of systemd-resolved.
I'm attaching a patch, and am also including it here for easy access:
*** resolved.broken 2019-11-19 15:01:28.785588838 +
--- resolved2019-11-19 15:08:06.519430073 +
***
*** 14,20
# (D) = master script downs interface
# (-) = master script does nothing with this
! if [ -x /lib/systemd/systemd-resolved ] ; then
# For safety, first undefine the nasty default make_resolv_conf()
make_resolv_conf() { : ; }
case "$reason" in
--- 14,21
# (D) = master script downs interface
# (-) = master script does nothing with this
! systemctl is-active systemd-resolved > /dev/null 2>&1
! if [ $? -eq 0 ]; then
# For safety, first undefine the nasty default make_resolv_conf()
make_resolv_conf() { : ; }
case "$reason" in
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853164/+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 1853164] Re: systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error
heh, please ignore the above comment, the current focal systemd was
respun, but the fix for this was already released for focal, this only
needs bionic verified now :)
--
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/1853164
Title:
systemd: /etc/dhcp/dhclient-enter-hooks.d/resolved error
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 Released
Bug description:
[impact]
with systemd-resolved disabled, dhclient doesn't correctly notify
resolvconf about dns server(s)
[test case]
install resolvconf and ifupdown and disable systemd-resolved and
systemd-networkd, use ifupdown to get a dhcp address where the lease
includes a dns nameserver, verify resolvconf is using that dhcp-
provided nameserver
[regression potential]
failure to correctly notify systemd-resolved about new dhclient-
provided nameserver(s)
[scope]
this is needed for f and earlier
in g and later the hook script is moved to the isc-dhcp package, and
edited to correctly check is-enabled systemd-resolved instead of only
checking for the existence of the binary
[original description]
The functionality exists to allow users to revert to the traditional ifupdown
package for network configuration. Alongside this, systemd's often-buggy
resolver can be disabled. However, there's a logic error in the systemd-
supplied /etc/dhcp/dhclient-enter-hooks.d/resolved that prevents the system
from populating /etc/resolv.conf properly when systemd-resolved is disabled.
The issue is here:
if [ -x /lib/systemd/systemd-resolved ] ; then
Instead of checking to see if the systemd-resolved service is enabled or
active, which would be the correct behaviour, this checks for the existence of
a binary, assuming that if it exists it's supposed to be used.
I've not tested this in the absence of resolvconf, but if systemd-resolved
isn't enabled, it's difficult to imagine this code wanting to run. I've tested
this with resolvconf and ifupdown driving dhclient, and it corrects the
behaviour that was broken with the introduction of systemd-resolved.
I'm attaching a patch, and am also including it here for easy access:
*** resolved.broken 2019-11-19 15:01:28.785588838 +
--- resolved2019-11-19 15:08:06.519430073 +
***
*** 14,20
# (D) = master script downs interface
# (-) = master script does nothing with this
! if [ -x /lib/systemd/systemd-resolved ] ; then
# For safety, first undefine the nasty default make_resolv_conf()
make_resolv_conf() { : ; }
case "$reason" in
--- 14,21
# (D) = master script downs interface
# (-) = master script does nothing with this
! systemctl is-active systemd-resolved > /dev/null 2>&1
! if [ $? -eq 0 ]; then
# For safety, first undefine the nasty default make_resolv_conf()
make_resolv_conf() { : ; }
case "$reason" in
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1853164/+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 1942899] Re: Revert Add ACCEL_LOCATION=base property for Dell clamshell models
for the verifications above, i also updated the 'udev' package to the same version as systemd ** Tags removed: verification-needed verification-needed-focal verification-needed-hirsute ** Tags added: verification-done verification-done-focal verification-done-hirsute -- 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/1942899 Title: Revert Add ACCEL_LOCATION=base property for Dell clamshell models Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Hirsute: Fix Committed Status in systemd source package in Impish: Fix Committed Bug description: [impact] initial patch for LP: #1938259 was incorrect. [test case] this bug is only to revert the previous patch the upstream commit is:https://github.com/systemd/systemd/pull/20314/commits/55b29d8f130684bf1fd9fdfaef3bcca64b66930e checking for lack of the new 'sku' lines, and presence of the old lines, should be enough to verify this revert is correct [regression potential] any regression would likely be restricted to dell clamshell models matching the modified config settings [scope] the incorrect patch was added in f/h/i so only those need the patch removed/reverted [other info] this only reverts the patch that was added for bug 1938259, as the bug reporter indicated in that bug in comment 15 that the patch did not actually work correctly. a correct patch will need to go upstream first, so this bug is just to revert the last patch and respin systemd for all releases To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1942899/+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 1942899] Re: Revert Add ACCEL_LOCATION=base property for Dell clamshell models
commit to focal that needed reverting: https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?h=ubuntu-focal=5c1be33900edee94da0dc9a4ade8edcd079b4c85 ubuntu@lp1942899-f:~$ dpkg -l systemd|grep systemd ii systemd245.4-4ubuntu3.11 amd64system and service manager ubuntu@lp1942899-f:~$ grep -E 'sku0A3E|sku0B0B' /lib/udev/hwdb.d/60-sensor.hwdb ubuntu@lp1942899-f:~$ ubuntu@lp1942899-f:~$ dpkg -l systemd|grep systemd ii systemd245.4-4ubuntu3.13 amd64system and service manager ubuntu@lp1942899-f:~$ grep -E 'sku0A3E|sku0B0B' /lib/udev/hwdb.d/60-sensor.hwdb ubuntu@lp1942899-f:~$ -- 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/1942899 Title: Revert Add ACCEL_LOCATION=base property for Dell clamshell models Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Hirsute: Fix Committed Status in systemd source package in Impish: Fix Committed Bug description: [impact] initial patch for LP: #1938259 was incorrect. [test case] this bug is only to revert the previous patch the upstream commit is:https://github.com/systemd/systemd/pull/20314/commits/55b29d8f130684bf1fd9fdfaef3bcca64b66930e checking for lack of the new 'sku' lines, and presence of the old lines, should be enough to verify this revert is correct [regression potential] any regression would likely be restricted to dell clamshell models matching the modified config settings [scope] the incorrect patch was added in f/h/i so only those need the patch removed/reverted [other info] this only reverts the patch that was added for bug 1938259, as the bug reporter indicated in that bug in comment 15 that the patch did not actually work correctly. a correct patch will need to go upstream first, so this bug is just to revert the last patch and respin systemd for all releases To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1942899/+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 1942899] Re: Revert Add ACCEL_LOCATION=base property for Dell clamshell models
commit to hirsute that needed reverting: https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=a21edd743408b5603b0177e9c230c6d6b919e589 ubuntu@lp1942899-h:~$ dpkg -l systemd|grep systemd ii systemd247.3-3ubuntu3.4 amd64system and service manager ubuntu@lp1942899-h:~$ grep -E 'pnLatitude7420|pnLatitude9520|sku0B0B|sku0A3E' /lib/udev/hwdb.d/60-sensor.hwdb sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:pnLatitude9520:*:ct10:* sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:pnLatitude7420:* ubuntu@lp1942899-h:~$ ubuntu@lp1942899-h:~$ dpkg -l systemd|grep systemd ii systemd247.3-3ubuntu3.6 amd64system and service manager ubuntu@lp1942899-h:~$ grep -E 'pnLatitude7420|pnLatitude9520|sku0B0B|sku0A3E' /lib/udev/hwdb.d/60-sensor.hwdb sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:pnLatitude9520:*:ct10:* sensor:modalias:platform:HID-SENSOR-200073:dmi:*svnDell*:pnLatitude7420:* ubuntu@lp1942899-h:~$ -- 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/1942899 Title: Revert Add ACCEL_LOCATION=base property for Dell clamshell models Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Hirsute: Fix Committed Status in systemd source package in Impish: Fix Committed Bug description: [impact] initial patch for LP: #1938259 was incorrect. [test case] this bug is only to revert the previous patch the upstream commit is:https://github.com/systemd/systemd/pull/20314/commits/55b29d8f130684bf1fd9fdfaef3bcca64b66930e checking for lack of the new 'sku' lines, and presence of the old lines, should be enough to verify this revert is correct [regression potential] any regression would likely be restricted to dell clamshell models matching the modified config settings [scope] the incorrect patch was added in f/h/i so only those need the patch removed/reverted [other info] this only reverts the patch that was added for bug 1938259, as the bug reporter indicated in that bug in comment 15 that the patch did not actually work correctly. a correct patch will need to go upstream first, so this bug is just to revert the last patch and respin systemd for all releases To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1942899/+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 1942899] Re: Revert Add ACCEL_LOCATION=base property for Dell clamshell models
** Description changed: [impact] initial patch for LP: #1938259 was incorrect. [test case] this bug is only to revert the previous patch + + the upstream commit + is:https://github.com/systemd/systemd/pull/20314/commits/55b29d8f130684bf1fd9fdfaef3bcca64b66930e + + checking for lack of the new 'sku' lines, and presence of the old lines, + should be enough to verify this revert is correct [regression potential] any regression would likely be restricted to dell clamshell models matching the modified config settings [scope] the incorrect patch was added in f/h/i so only those need the patch removed/reverted [other info] this only reverts the patch that was added for bug 1938259, as the bug reporter indicated in that bug in comment 15 that the patch did not actually work correctly. a correct patch will need to go upstream first, so this bug is just to revert the last patch and respin systemd for all releases -- 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/1942899 Title: Revert Add ACCEL_LOCATION=base property for Dell clamshell models Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Focal: Fix Committed Status in systemd source package in Hirsute: Fix Committed Status in systemd source package in Impish: Fix Committed Bug description: [impact] initial patch for LP: #1938259 was incorrect. [test case] this bug is only to revert the previous patch the upstream commit is:https://github.com/systemd/systemd/pull/20314/commits/55b29d8f130684bf1fd9fdfaef3bcca64b66930e checking for lack of the new 'sku' lines, and presence of the old lines, should be enough to verify this revert is correct [regression potential] any regression would likely be restricted to dell clamshell models matching the modified config settings [scope] the incorrect patch was added in f/h/i so only those need the patch removed/reverted [other info] this only reverts the patch that was added for bug 1938259, as the bug reporter indicated in that bug in comment 15 that the patch did not actually work correctly. a correct patch will need to go upstream first, so this bug is just to revert the last patch and respin systemd for all releases To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1942899/+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 1934981] Re: systemctl suspend-then-hibernate attempts hybrid-sleep instead
ubuntu@lp1934981-f:~$ dpkg -l systemd|grep systemd ii systemd245.4-4ubuntu3.11 amd64system and service manager ubuntu@lp1934981-f:~$ grep -E '^Allow' /etc/systemd/sleep.conf AllowSuspendThenHibernate=yes AllowHybridSleep=no ubuntu@lp1934981-f:~$ sudo systemctl suspend-then-hibernate Failed to suspend system, hibernate later via logind: Sleep verb "hybrid-sleep" not supported ubuntu@lp1934981-f:~$ ubuntu@lp1934981-f:~$ dpkg -l systemd|grep systemd ii systemd245.4-4ubuntu3.13 amd64system and service manager ubuntu@lp1934981-f:~$ grep -E '^Allow' /etc/systemd/sleep.conf AllowSuspendThenHibernate=yes AllowHybridSleep=no ubuntu@lp1934981-f:~$ sudo systemctl suspend-then-hibernate ubuntu@lp1934981-f:~$ ** Tags removed: verification-needed verification-needed-focal verification-needed-hirsute ** Tags added: verification-done verification-done-focal verification-done-hirsute -- 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/1934981 Title: systemctl suspend-then-hibernate attempts hybrid-sleep instead Status in systemd package in Ubuntu: Fix Committed 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: Won't Fix Status in systemd source package in Hirsute: Fix Committed Status in systemd source package in Impish: Fix Committed Bug description: [impact] suspend-then-hibernate not possible using systemctl [test case] configure a system (that has enough swap to be able to hibernate) to allow suspend-then-hibernate but not hybrid-sleep, e.g. by editing /etc/systemd/sleep.conf to set AllowSuspendThenHibernate=yes and AllowHybridSleep=no, then try it: $ sudo systemctl suspend-then-hibernate Failed to suspend system, hibernate later via logind: Sleep verb "hybrid-sleep" not supported note that on bionic, the Allow...= params do not exist, instead we can reproduce the error by setting one of the hybrid parameters to an invalid value, e.g. HybridSleepState=bugverification [regression potential] failure to correctly enter hybrid-sleep and/or suspend-then-hibernate, or other issues around suspending/hibernating [scope] This is needed in b and later. The bug appears to have been introduced by a typo in the original suspend-then-hibernate commit c58493c00af, and then fixed with larger changes in commit c8cd8ca3986. this is also present in b, by a backport of the functionality [other info] note that if hybrid-sleep is allowed/possible, then calling 'systemctl suspend-then-hibernate' does actually perform suspend-then-hibernate; this typo only controls what suspend action logind checks for support of, not what suspend action it actually performs. [original description] ``` systemctl suspend-then-hibernate Failed to suspend system, hibernate later via logind: Sleep verb "hybrid-sleep" not supported ``` Note the verb change! ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: systemd 247.3-3ubuntu3 ProcVersionSignature: Ubuntu 5.11.0-22.23-generic 5.11.21 Uname: Linux 5.11.0-22-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Jul 8 08:54:01 2021 InstallationDate: Installed on 2021-07-06 (1 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) MachineType: Dell Inc. XPS 13 9300 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-22-generic root=/dev/mapper/username-root ro quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /usr/lib/systemd/system/systemd-localed.service → /usr/lib/systemd/system/systemd-localed.service.d/locale-gen.conf [EXTENDED] /usr/lib/systemd/system/user@.service → /usr/lib/systemd/system/user@.service.d/timeout.conf 3 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/03/2021 dmi.bios.release: 1.5 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.5.0 dmi.board.name: 0PP9G2 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.5.0:bd02/03/2021:br1.5:svnDellInc.:pnXPS139300:pvr:rvnDellInc.:rn0PP9G2:rvrA00:cvnDellInc.:ct10:cvr: dmi.product.family: XPS dmi.product.name: XPS 13 9300 dmi.product.sku: 096D dmi.sys.vendor: Dell
[Touch-packages] [Bug 1934981] Re: systemctl suspend-then-hibernate attempts hybrid-sleep instead
ubuntu@lp1934981-h:~$ dpkg -l systemd|grep systemd ii systemd247.3-3ubuntu3.4 amd64system and service manager ubuntu@lp1934981-h:~$ grep -E '^Allow' /etc/systemd/sleep.conf AllowSuspendThenHibernate=yes AllowHybridSleep=no ubuntu@lp1934981-h:~$ sudo systemctl suspend-then-hibernate Failed to suspend system, hibernate later via logind: Sleep verb "hybrid-sleep" not supported ubuntu@lp1934981-h:~$ ubuntu@lp1934981-h:~$ dpkg -l systemd|grep systemd ii systemd247.3-3ubuntu3.6 amd64system and service manager ubuntu@lp1934981-h:~$ grep -E '^Allow' /etc/systemd/sleep.conf AllowSuspendThenHibernate=yes AllowHybridSleep=no ubuntu@lp1934981-h:~$ sudo systemctl suspend-then-hibernate ubuntu@lp1934981-h:~$ -- 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/1934981 Title: systemctl suspend-then-hibernate attempts hybrid-sleep instead Status in systemd package in Ubuntu: Fix Committed 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: Won't Fix Status in systemd source package in Hirsute: Fix Committed Status in systemd source package in Impish: Fix Committed Bug description: [impact] suspend-then-hibernate not possible using systemctl [test case] configure a system (that has enough swap to be able to hibernate) to allow suspend-then-hibernate but not hybrid-sleep, e.g. by editing /etc/systemd/sleep.conf to set AllowSuspendThenHibernate=yes and AllowHybridSleep=no, then try it: $ sudo systemctl suspend-then-hibernate Failed to suspend system, hibernate later via logind: Sleep verb "hybrid-sleep" not supported note that on bionic, the Allow...= params do not exist, instead we can reproduce the error by setting one of the hybrid parameters to an invalid value, e.g. HybridSleepState=bugverification [regression potential] failure to correctly enter hybrid-sleep and/or suspend-then-hibernate, or other issues around suspending/hibernating [scope] This is needed in b and later. The bug appears to have been introduced by a typo in the original suspend-then-hibernate commit c58493c00af, and then fixed with larger changes in commit c8cd8ca3986. this is also present in b, by a backport of the functionality [other info] note that if hybrid-sleep is allowed/possible, then calling 'systemctl suspend-then-hibernate' does actually perform suspend-then-hibernate; this typo only controls what suspend action logind checks for support of, not what suspend action it actually performs. [original description] ``` systemctl suspend-then-hibernate Failed to suspend system, hibernate later via logind: Sleep verb "hybrid-sleep" not supported ``` Note the verb change! ProblemType: Bug DistroRelease: Ubuntu 21.04 Package: systemd 247.3-3ubuntu3 ProcVersionSignature: Ubuntu 5.11.0-22.23-generic 5.11.21 Uname: Linux 5.11.0-22-generic x86_64 ApportVersion: 2.20.11-0ubuntu65.1 Architecture: amd64 CasperMD5CheckResult: pass CurrentDesktop: ubuntu:GNOME Date: Thu Jul 8 08:54:01 2021 InstallationDate: Installed on 2021-07-06 (1 days ago) InstallationMedia: Ubuntu 21.04 "Hirsute Hippo" - Release amd64 (20210420) MachineType: Dell Inc. XPS 13 9300 ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-5.11.0-22-generic root=/dev/mapper/username-root ro quiet splash vt.handoff=7 SourcePackage: systemd SystemdDelta: [EXTENDED] /usr/lib/systemd/system/rc-local.service → /usr/lib/systemd/system/rc-local.service.d/debian.conf [EXTENDED] /usr/lib/systemd/system/systemd-localed.service → /usr/lib/systemd/system/systemd-localed.service.d/locale-gen.conf [EXTENDED] /usr/lib/systemd/system/user@.service → /usr/lib/systemd/system/user@.service.d/timeout.conf 3 overridden configuration files found. SystemdFailedUnits: Error: command ['systemctl', 'status', '--full', '●'] failed with exit code 4: Invalid unit name "●" escaped as "\xe2\x97\x8f" (maybe you should use systemd-escape?). Unit \xe2\x97\x8f.service could not be found. UpgradeStatus: No upgrade log present (probably fresh install) dmi.bios.date: 02/03/2021 dmi.bios.release: 1.5 dmi.bios.vendor: Dell Inc. dmi.bios.version: 1.5.0 dmi.board.name: 0PP9G2 dmi.board.vendor: Dell Inc. dmi.board.version: A00 dmi.chassis.type: 10 dmi.chassis.vendor: Dell Inc. dmi.modalias: dmi:bvnDellInc.:bvr1.5.0:bd02/03/2021:br1.5:svnDellInc.:pnXPS139300:pvr:rvnDellInc.:rn0PP9G2:rvrA00:cvnDellInc.:ct10:cvr: dmi.product.family: XPS dmi.product.name: XPS 13 9300 dmi.product.sku: 096D dmi.sys.vendor: Dell Inc. mtime.conffile..etc.systemd.sleep.conf: 2021-07-08T08:51:57.213321 To manage notifications about this bug go to:
[Touch-packages] [Bug 1934147] Re: systemd leaks abandoned session scopes
ubuntu@lp1934147-f:~$ dpkg -l systemd|grep systemd
ii systemd245.4-4ubuntu3.11 amd64system and service manager
ubuntu@lp1934147-f:~$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 1000 ubuntu ttyS0
1 sessions listed.
ubuntu@lp1934147-f:~$ for i in {1..100}; do sudo -b -i -u ubuntu ssh localhost
-- sleep 1; done; for i in {1..20}; do echo 'Reloading...'; sudo systemctl
daemon-reload; done
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
ubuntu@lp1934147-f:~$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 1000 ubuntu ttyS0
64 1000 ubuntu
69 1000 ubuntu
74 1000 ubuntu
76 1000 ubuntu
82 1000 ubuntu
88 1000 ubuntu
94 1000 ubuntu
95 1000 ubuntu
9 sessions listed.
ubuntu@lp1934147-f:~$ dpkg -l systemd|grep systemd
ii systemd245.4-4ubuntu3.13 amd64system and service manager
ubuntu@lp1934147-f:~$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 1000 ubuntu ttyS0
1 sessions listed.
ubuntu@lp1934147-f:~$ for i in {1..100}; do sudo -b -i -u ubuntu ssh localhost
-- sleep 1; done; for i in {1..20}; do echo 'Reloading...'; sudo systemctl
daemon-reload; done
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
ubuntu@lp1934147-f:~$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 1000 ubuntu ttyS0
1 sessions listed.
** Tags removed: verification-needed verification-needed-focal
verification-needed-hirsute
** Tags added: verification-done verification-done-focal
verification-done-hirsute
--
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/1934147
Title:
systemd leaks abandoned session scopes
Status in snapd:
New
Status in systemd:
New
Status in systemd package in Ubuntu:
Fix Committed
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:
Won't Fix
Status in systemd source package in Hirsute:
Fix Committed
Status in systemd source package in Impish:
Fix Committed
Bug description:
[impact]
systemd may leak sessions, leaving empty cgroups around as well as
abandoned session scopes.
[test case]
on a system where the user has a ssh key that allows noninteractive
login to localhost, and also has noninteractive sudo, run:
$ for i in {1..100}; do sudo -b -i -u ubuntu ssh localhost -- sleep 1;
done; for i in {1..20}; do echo 'Reloading...'; sudo systemctl daemon-
reload; done
check the sessions to see there have been leaked sessions:
$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 1000 ubuntu ttyS0
350 1000 ubuntu
351 1000 ubuntu
360 1000 ubuntu
...
to verify the sessions were leaked, clear them out with:
$ echo '' | sudo tee
/sys/fs/cgroup/unified/user.slice/user-1000.slice/session-*.scope/cgroup.events
that should result in all the leaked sessions being cleaned up.
[regression potential]
issues during systemd pid1 reexec/reload, or issues while cleaning up
sessions, including leaking sessions/cgroups
[scope]
this is needed for all releases
upstream bug linked above, and upstream PR:
https://github.com/systemd/systemd/pull/20199
[original description]
On a system that is monitored via telegraf I found many abandoned
systemd session which I believe are created by a potential race where
systemd is reloading unit files and at the same time a user is
connecting to the system via ssh or is executing the su command.
The simple reproducer
$ for i in {1..100}; do sleep 0.2; ssh localhost sudo systemctl
daemon-reload & ssh localhost sleep 1 & done
Wait > 1 second
$ jobs -p | xargs --verbose --no-run-if-empty kill -KILL
To clean out STOPPED jobs and
$ systemctl status --all 2> /dev/null | grep --before-context 3
abandoned
will produce something similar to
│ ├─ 175 su - ubuntu
│ ├─ 178 -su
│ ├─62375 systemctl status --all
│ └─62376 grep --color=auto --before-context 3 abandoned
--
● session-273.scope - Session 273 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-273.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
--
● session-274.scope -
[Touch-packages] [Bug 1934147] Re: systemd leaks abandoned session scopes
ubuntu@lp1934147-h:~$ dpkg -l systemd|grep systemd
ii systemd247.3-3ubuntu3.4 amd64system and service manager
ubuntu@lp1934147-h:~$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 1000 ubuntu ttyS0
1 sessions listed.
ubuntu@lp1934147-h:~$ for i in {1..100}; do sudo -b -i -u ubuntu ssh localhost
-- sleep 1; done; for i in {1..20}; do echo 'Reloading...'; sudo systemctl
daemon-reload; done
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
ubuntu@lp1934147-h:~$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 1000 ubuntu ttyS0
54 1000 ubuntu
67 1000 ubuntu
71 1000 ubuntu
77 1000 ubuntu
5 sessions listed.
ubuntu@lp1934147-h:~$
ubuntu@lp1934147-h:~$ dpkg -l systemd|grep systemd
ii systemd247.3-3ubuntu3.6 amd64system and service manager
ubuntu@lp1934147-h:~$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 1000 ubuntu ttyS0
1 sessions listed.
ubuntu@lp1934147-h:~$ for i in {1..100}; do sudo -b -i -u ubuntu ssh localhost
-- sleep 1; done; for i in {1..20}; do echo 'Reloading...'; sudo systemctl
daemon-reload; done
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
Reloading...
ubuntu@lp1934147-h:~$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 1000 ubuntu ttyS0
1 sessions listed.
--
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/1934147
Title:
systemd leaks abandoned session scopes
Status in snapd:
New
Status in systemd:
New
Status in systemd package in Ubuntu:
Fix Committed
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:
Won't Fix
Status in systemd source package in Hirsute:
Fix Committed
Status in systemd source package in Impish:
Fix Committed
Bug description:
[impact]
systemd may leak sessions, leaving empty cgroups around as well as
abandoned session scopes.
[test case]
on a system where the user has a ssh key that allows noninteractive
login to localhost, and also has noninteractive sudo, run:
$ for i in {1..100}; do sudo -b -i -u ubuntu ssh localhost -- sleep 1;
done; for i in {1..20}; do echo 'Reloading...'; sudo systemctl daemon-
reload; done
check the sessions to see there have been leaked sessions:
$ loginctl list-sessions
SESSION UID USER SEAT TTY
1 1000 ubuntu ttyS0
350 1000 ubuntu
351 1000 ubuntu
360 1000 ubuntu
...
to verify the sessions were leaked, clear them out with:
$ echo '' | sudo tee
/sys/fs/cgroup/unified/user.slice/user-1000.slice/session-*.scope/cgroup.events
that should result in all the leaked sessions being cleaned up.
[regression potential]
issues during systemd pid1 reexec/reload, or issues while cleaning up
sessions, including leaking sessions/cgroups
[scope]
this is needed for all releases
upstream bug linked above, and upstream PR:
https://github.com/systemd/systemd/pull/20199
[original description]
On a system that is monitored via telegraf I found many abandoned
systemd session which I believe are created by a potential race where
systemd is reloading unit files and at the same time a user is
connecting to the system via ssh or is executing the su command.
The simple reproducer
$ for i in {1..100}; do sleep 0.2; ssh localhost sudo systemctl
daemon-reload & ssh localhost sleep 1 & done
Wait > 1 second
$ jobs -p | xargs --verbose --no-run-if-empty kill -KILL
To clean out STOPPED jobs and
$ systemctl status --all 2> /dev/null | grep --before-context 3
abandoned
will produce something similar to
│ ├─ 175 su - ubuntu
│ ├─ 178 -su
│ ├─62375 systemctl status --all
│ └─62376 grep --color=auto --before-context 3 abandoned
--
● session-273.scope - Session 273 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-273.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
--
● session-274.scope - Session 274 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-274.scope; transient)
Transient: yes
Active: active (abandoned) since Wed 2021-06-30 13:32:03 UTC; 4min 7s ago
--
● session-30.scope - Session 30 of user ubuntu
Loaded: loaded (/run/systemd/transient/session-30.scope;
[Touch-packages] [Bug 1934393] Re: systemd-logind network access is blocked, and breaks remote authentication configurations
Just to summarize the specific flow of this bug: 1. an application is started for a user session, e.g. sshd handles a user connecting. 2. the application uses pam for authentication, which by default includes pam_systemd as an (optional) module. 3. pam invokes pam_systemd as part of session creation. 4. pam_systemd calls into systemd-logind, over dbus with CreateSession. 5. the running systemd-logind process receives the dbus request and begins setting up the session. 6. systemd-logind attempts to get the full user info via NSS, e.g. getpwuid_r() or similar call 7. glibc attempts the user lookup, doesn't find the UID or username in /etc/passwd using the normal "files" based lookup 8. since nsswitch.conf is configured with network-based authentication (an essential part of this bug), glibc attempts (either through its "compat" mechanism, or separate nss module like libnss_ldap) to open a network connection to the remote authentication server to get the user info 9. since the glibc code, as well as any libnss module loaded by glibc, is running under the systemd-logind process, the network connection fails due to systemd-logind RestrictAddressFamilies= setting 10. nss returns a result of "no user found" to systemd-logind 11. systemd-logind determines it was unable to find the user data for the requested session, so it returns failure over dbus to the pam_systemd module 12. the pam_systemd module returns failure, but since it's marked "optional" (by default) in the pam common-session config file, the application isn't stopped from finishing successful auth 13. the application finishes pam authentication and opens a shell, but without a successful systemd-logind session note that if there is a local caching component to whatever network authentication is configured - e.g. nscd - glibc might attempt to check that locally first, and if the user is located and no remote connection is needed, the lookup will succeed. also note that this bug only applies for nss modules that actually perform network connections directly from the nss module; if the nss module calls a local unix socket into a separate locally running process, that won't be blocked, since systemd-logind is allowed to do AF_UNIX. As has been pointed out and discussed, it really doesn't seem like there are any options to address this other than 1) open up systemd-logind to AF_INET and/or AF_INET6, or 2) provide systemd-logind with a way to perform nss lookups outside of direct nss calls, e.g. userdb. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openldap in Ubuntu. https://bugs.launchpad.net/bugs/1934393 Title: systemd-logind network access is blocked, and breaks remote authentication configurations Status in systemd: Fix Released Status in nis package in Ubuntu: Confirmed Status in openldap package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Won't Fix Status in nis package in Debian: Fix Released Bug description: [impact] starting in focal, systemd-logind runs sandboxed without any network access, which breaks any configuration that uses remote servers for user data, e.g. ldap, nis, etc A more full discussion is available in the upstream bug report as well as the debian bug report, see other info section below [test case] many possible ways to reproduce this; there are reproducers in some of the bugs reported before that are caused by this, e.g. bug 1915502 or bug 1916235 [regression potential] failure to authenticate when using remote user data, incorrect authentication, security issues due to un-sandboxing of systemd-logind [scope] this is needed in f and later before focal, systemd-logind was not sandboxed so this did not apply [other info] this isn't actually a bug in systemd, this is a by-design security feature, and the intended upstream design is for systemd-logind to talk to systemd-userdb, so that systemd-logind can remain network- sandboxed while systemd-userdb performs any needed network access for user/auth data. However, Debian and Ubuntu don't enable/provide systemd-userdb, so that design does not work for Debian/Ubuntu. this also can cause systemd-udevd failures in some cases as well, apparently (based on upstream and debian discussion comments) For reference, upstream discussion around the systemd-logind sandboxing specifically: https://github.com/systemd/systemd/issues/7074 upstream updated doc PR explaining the upstream position: https://github.com/systemd/systemd/pull/7343 Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=878625 To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1934393/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help :
[Touch-packages] [Bug 1938259] Re: Add ACCEL_LOCATION=base property for Dell clamshell models
opened bug 1942899 to revert your patch please open a new bug to track adding your correct patch in to later systemd uploads ** Changed in: systemd (Ubuntu Impish) Status: In Progress => Won't Fix ** Changed in: systemd (Ubuntu Hirsute) Status: In Progress => Won't Fix ** Changed in: systemd (Ubuntu Focal) Status: In Progress => Won't Fix ** Changed in: systemd (Ubuntu) Status: In Progress => Won't Fix -- 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/1938259 Title: Add ACCEL_LOCATION=base property for Dell clamshell models Status in OEM Priority Project: New Status in systemd package in Ubuntu: Won't Fix Status in systemd source package in Focal: Won't Fix Status in systemd source package in Hirsute: Won't Fix Status in systemd source package in Impish: Won't Fix Bug description: We are planning to do SRU to systemd in focal, to avoid unwanted screen rotations on some Dell laptop models. [Impact] * This fixes unwanted rotations on certain Dell clamshell laptop models with accelerometer. [Test Plan] * On Dell laptops with model SKU 0A3E or 0E0E, install this package and kernel 5.13, or kernel with this patch backported: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e26f023e01ef26b4138bc1099af309bdc4523d23 * Rotate the laptop and the display should not be rotated. [Where problems could occur] * This is to add parameters for certain models in hwdb, and does not affect any other part of systemd. * This fix would only take effect with kernel 5.13 or the above patch backported. [scope] this is needed for all releases this is being fixed upstream by https://github.com/systemd/systemd/pull/20314 [Other info] * The patch mentioned above is going to have a separated SRU for linux-oem-5.10 and linux-hwe-5.11 (LP: #1938143) To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1938259/+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 1942899] Re: Revert Add ACCEL_LOCATION=base property for Dell clamshell models
** Changed in: systemd (Ubuntu Focal) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: systemd (Ubuntu Hirsute) Assignee: (unassigned) => Dan Streetman (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/1942899 Title: Revert Add ACCEL_LOCATION=base property for Dell clamshell models Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Focal: In Progress Status in systemd source package in Hirsute: In Progress Status in systemd source package in Impish: Fix Committed Bug description: [impact] initial patch for LP: #1938259 was incorrect. [test case] this bug is only to revert the previous patch [regression potential] any regression would likely be restricted to dell clamshell models matching the modified config settings [scope] the incorrect patch was added in f/h/i so only those need the patch removed/reverted [other info] this only reverts the patch that was added for bug 1938259, as the bug reporter indicated in that bug in comment 15 that the patch did not actually work correctly. a correct patch will need to go upstream first, so this bug is just to revert the last patch and respin systemd for all releases To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1942899/+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 1942899] Re: Revert Add ACCEL_LOCATION=base property for Dell clamshell models
pushed to git repo for impish https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/commit/?id=f34e9c33209ad9bf3ec807e3b7b9cd22dc8d155d -- 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/1942899 Title: Revert Add ACCEL_LOCATION=base property for Dell clamshell models Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Focal: In Progress Status in systemd source package in Hirsute: In Progress Status in systemd source package in Impish: Fix Committed Bug description: [impact] initial patch for LP: #1938259 was incorrect. [test case] this bug is only to revert the previous patch [regression potential] any regression would likely be restricted to dell clamshell models matching the modified config settings [scope] the incorrect patch was added in f/h/i so only those need the patch removed/reverted [other info] this only reverts the patch that was added for bug 1938259, as the bug reporter indicated in that bug in comment 15 that the patch did not actually work correctly. a correct patch will need to go upstream first, so this bug is just to revert the last patch and respin systemd for all releases To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1942899/+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 1942899] [NEW] Revert Add ACCEL_LOCATION=base property for Dell clamshell models
Public bug reported: [impact] initial patch for LP: #1938259 was incorrect. [test case] this bug is only to revert the previous patch [regression potential] any regression would likely be restricted to dell clamshell models matching the modified config settings [scope] the incorrect patch was added in f/h/i so only those need the patch removed/reverted [other info] this only reverts the patch that was added for bug 1938259, as the bug reporter indicated in that bug in comment 15 that the patch did not actually work correctly. a correct patch will need to go upstream first, so this bug is just to revert the last patch and respin systemd for all releases ** Affects: systemd (Ubuntu) Importance: Medium Status: Fix Committed ** Affects: systemd (Ubuntu Focal) Importance: Medium Status: In Progress ** Affects: systemd (Ubuntu Hirsute) Importance: Medium Status: In Progress ** Affects: systemd (Ubuntu Impish) Importance: Medium Status: Fix Committed ** Tags: regression-proposed ** Also affects: systemd (Ubuntu Impish) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Hirsute) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu Focal) Status: New => In Progress ** Changed in: systemd (Ubuntu Hirsute) Status: New => In Progress ** Changed in: systemd (Ubuntu Impish) Status: New => In Progress ** Changed in: systemd (Ubuntu Focal) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Hirsute) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Impish) Importance: Undecided => Medium ** Tags added: regression-proposed ** Changed in: systemd (Ubuntu Impish) Status: In Progress => Fix Committed -- 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/1942899 Title: Revert Add ACCEL_LOCATION=base property for Dell clamshell models Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Focal: In Progress Status in systemd source package in Hirsute: In Progress Status in systemd source package in Impish: Fix Committed Bug description: [impact] initial patch for LP: #1938259 was incorrect. [test case] this bug is only to revert the previous patch [regression potential] any regression would likely be restricted to dell clamshell models matching the modified config settings [scope] the incorrect patch was added in f/h/i so only those need the patch removed/reverted [other info] this only reverts the patch that was added for bug 1938259, as the bug reporter indicated in that bug in comment 15 that the patch did not actually work correctly. a correct patch will need to go upstream first, so this bug is just to revert the last patch and respin systemd for all releases To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1942899/+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 1938259] Re: Add ACCEL_LOCATION=base property for Dell clamshell models
> We found that Dell Latitude 7420 is not actually fixed, and may cause Impish to have regression due to the removal of the product name modalias. ok, well i guess we have to revert your patch and respin all the releases then. please, next time, test your change before things get into -proposed. ** Tags removed: verification-needed verification-needed-focal verification-needed-hirsute ** Tags added: verification-failed verification-failed-hirsute -- 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/1938259 Title: Add ACCEL_LOCATION=base property for Dell clamshell models Status in OEM Priority Project: New Status in systemd package in Ubuntu: In Progress Status in systemd source package in Focal: In Progress Status in systemd source package in Hirsute: In Progress Status in systemd source package in Impish: In Progress Bug description: We are planning to do SRU to systemd in focal, to avoid unwanted screen rotations on some Dell laptop models. [Impact] * This fixes unwanted rotations on certain Dell clamshell laptop models with accelerometer. [Test Plan] * On Dell laptops with model SKU 0A3E or 0E0E, install this package and kernel 5.13, or kernel with this patch backported: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e26f023e01ef26b4138bc1099af309bdc4523d23 * Rotate the laptop and the display should not be rotated. [Where problems could occur] * This is to add parameters for certain models in hwdb, and does not affect any other part of systemd. * This fix would only take effect with kernel 5.13 or the above patch backported. [scope] this is needed for all releases this is being fixed upstream by https://github.com/systemd/systemd/pull/20314 [Other info] * The patch mentioned above is going to have a separated SRU for linux-oem-5.10 and linux-hwe-5.11 (LP: #1938143) To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/1938259/+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 1785383] Re: missing EDNS0 record confuses systemd-resolved
> This is related to the ubuntu server (bug) maintenance
ah, https://wiki.ubuntu.com/ServerTeam#Daily_Bug_Expiration
just part of the internal canonical server team bug tracking, got it.
--
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/1785383
Title:
missing EDNS0 record confuses systemd-resolved
Status in systemd:
Fix Released
Status in dnsmasq package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in dnsmasq source package in Bionic:
Triaged
Status in systemd source package in Bionic:
Fix Released
Status in dnsmasq source package in Focal:
Fix Released
Status in systemd source package in Focal:
Fix Released
Status in dnsmasq source package in Groovy:
Fix Released
Status in systemd source package in Groovy:
Fix Released
Status in dnsmasq source package in Hirsute:
Fix Released
Status in systemd source package in Hirsute:
Fix Released
Status in dnsmasq source package in Impish:
Fix Released
Status in systemd source package in Impish:
Fix Released
Bug description:
[Impact]
dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer
for a domain it is authoritative for. systemd-resolved seems to get confused by
this in certain circumstances; when using the stub resolver and requesting an
address for which there are no records, there can sometimes be a five
second hang in resolution.
[Fix]
This is fixed by upstream commit
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
Not sure if it is worth cherry picking? I imagine the most likely
trigger will be dnsmasq on routers which are not likely to be running
Ubuntu, but maybe just in case.
I also think there are some logic issues in systemd-resolved, upstream
bug filed:
https://github.com/systemd/systemd/issues/9785
[Test Case]
Simple-ish test case for bionic:
---
IFACE=dummy0
SUBNET=10.0.0
ip link add $IFACE type dummy
ifconfig $IFACE ${SUBNET}.1/24
dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo
--host-record=test.test,${SUBNET}.1 --server=/test/ &
dig -t a test.test @10.0.0.1 | grep EDNS
# should return "; EDNS ..."
dig -t test.test @10.0.0.1 | grep EDNS
# again, should return "; EDNS ..." but doesn't
---
To reproduce the systemd-resolved side of the problem
---
# as above, but
# now configure systemd-resolved to look at only 10.0.0.1, then
systemd-resolve --reset-server-features
# should exhibit five second delay then connect, assuming sshd is running :)
ssh test.test
---
More detailed test case for focal and later:
install dnsmasq on a bionic system and start it, listening to an
interface that is externally reachable, e.g. for a normal libvirt vm
with interface name 'ens3':
IFACE=ens3
dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo
--host-record=test.test,1.2.3.4 --server=/test/
note that the '1.2.3.4' address doesn't matter, any addr is ok.
then setup a test system that can reach the dnsmasq system, and
configure networkd to use the dnsmasq server, e.g. using config like:
[Match]
Name=ens3
[Network]
DHCP=yes
DNS=DNSMASQ_IP_ADDRESS
Domains=test
[DHCPv4]
UseDNS=no
UseDomains=no
replace 'DNSMASQ_IP_ADDRESS' with the addr of the bionic system where
dnsmasq is running, and replace 'ens3' with whatever the test system
interface name is. Then restart systemd-networkd, and test:
systemd-resolve --reset-server-features
systemd-resolve --flush-caches
host test.test
The lookup using 'host' should complete immediately;.
[Discussion]
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: dnsmasq-base 2.79-1
ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
Date: Sat Aug 4 11:33:56 2018
InstallationDate: Installed on 2018-05-31 (64 days ago)
InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64
(20180426)
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: dnsmasq
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1785383/+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 1785383] Re: missing EDNS0 record confuses systemd-resolved
> [commenting so the bug doesn't get expired as we still need to look at
the Bionic fix for dnsmasq]
AFAIK, launchpad bugs only auto-expire if set to 'incomplete'. bugs set
to anything else, like this one set to 'triaged', won't auto-expire and
don't need comments added to keep them from auto-expiring, unless there
is something i'm missing.
--
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/1785383
Title:
missing EDNS0 record confuses systemd-resolved
Status in systemd:
Fix Released
Status in dnsmasq package in Ubuntu:
Fix Released
Status in systemd package in Ubuntu:
Fix Released
Status in dnsmasq source package in Bionic:
Triaged
Status in systemd source package in Bionic:
Fix Released
Status in dnsmasq source package in Focal:
Fix Released
Status in systemd source package in Focal:
Fix Released
Status in dnsmasq source package in Groovy:
Fix Released
Status in systemd source package in Groovy:
Fix Released
Status in dnsmasq source package in Hirsute:
Fix Released
Status in systemd source package in Hirsute:
Fix Released
Status in dnsmasq source package in Impish:
Fix Released
Status in systemd source package in Impish:
Fix Released
Bug description:
[Impact]
dnsmasq 2.79 and below omits EDNS0 OPT records when returning an empty answer
for a domain it is authoritative for. systemd-resolved seems to get confused by
this in certain circumstances; when using the stub resolver and requesting an
address for which there are no records, there can sometimes be a five
second hang in resolution.
[Fix]
This is fixed by upstream commit
http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=1682d15a744880b0398af75eadf68fe66128af78
Not sure if it is worth cherry picking? I imagine the most likely
trigger will be dnsmasq on routers which are not likely to be running
Ubuntu, but maybe just in case.
I also think there are some logic issues in systemd-resolved, upstream
bug filed:
https://github.com/systemd/systemd/issues/9785
[Test Case]
Simple-ish test case for bionic:
---
IFACE=dummy0
SUBNET=10.0.0
ip link add $IFACE type dummy
ifconfig $IFACE ${SUBNET}.1/24
dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo
--host-record=test.test,${SUBNET}.1 --server=/test/ &
dig -t a test.test @10.0.0.1 | grep EDNS
# should return "; EDNS ..."
dig -t test.test @10.0.0.1 | grep EDNS
# again, should return "; EDNS ..." but doesn't
---
To reproduce the systemd-resolved side of the problem
---
# as above, but
# now configure systemd-resolved to look at only 10.0.0.1, then
systemd-resolve --reset-server-features
# should exhibit five second delay then connect, assuming sshd is running :)
ssh test.test
---
More detailed test case for focal and later:
install dnsmasq on a bionic system and start it, listening to an
interface that is externally reachable, e.g. for a normal libvirt vm
with interface name 'ens3':
IFACE=ens3
dnsmasq -h -R -d -C /dev/null -2 $IFACE -z -i $IFACE -I lo
--host-record=test.test,1.2.3.4 --server=/test/
note that the '1.2.3.4' address doesn't matter, any addr is ok.
then setup a test system that can reach the dnsmasq system, and
configure networkd to use the dnsmasq server, e.g. using config like:
[Match]
Name=ens3
[Network]
DHCP=yes
DNS=DNSMASQ_IP_ADDRESS
Domains=test
[DHCPv4]
UseDNS=no
UseDomains=no
replace 'DNSMASQ_IP_ADDRESS' with the addr of the bionic system where
dnsmasq is running, and replace 'ens3' with whatever the test system
interface name is. Then restart systemd-networkd, and test:
systemd-resolve --reset-server-features
systemd-resolve --flush-caches
host test.test
The lookup using 'host' should complete immediately;.
[Discussion]
ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: dnsmasq-base 2.79-1
ProcVersionSignature: Ubuntu 4.15.0-23.25-generic 4.15.18
Uname: Linux 4.15.0-23-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.2
Architecture: amd64
Date: Sat Aug 4 11:33:56 2018
InstallationDate: Installed on 2018-05-31 (64 days ago)
InstallationMedia: Xubuntu 18.04 LTS "Bionic Beaver" - Release amd64
(20180426)
ProcEnviron:
TERM=xterm
PATH=(custom, no user)
LANG=en_GB.UTF-8
SHELL=/bin/bash
SourcePackage: dnsmasq
UpgradeStatus: No upgrade log present (probably fresh install)
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1785383/+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 1935051] Re: systemd pid 1 memory leak
** 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/1935051
Title:
systemd pid 1 memory leak
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Focal:
Fix Committed
Bug description:
[impact]
pid1 leaks memory when rebuilding unit path cache
[test case]
see original description.
also, the patch contains an example of how to reproduce:
$ for i in {1..300}; do cp ~/.config/systemd/user/test0001.service
~/.config/systemd/user/test$(printf %04d $i).service; systemctl --user
start test$(printf %04d $i).service;done
[regression]
any problems would occur when rebuilding the path cache, possibly
resulting in memory leaks or pid1 crashes.
[scope]
this is needed only in f
fixed upstream by 3fb2326f3ed87aa0b26078d307ebfb299e36286d which is
included in v246, so fixed in h and later
the code in b is very different and doesn't appear to have the leak,
per original report
[original description]
Hi everybody.
We've meet a memory leak of pid1 process on the focal release.
When we launch chef-client, several systemd .service and .timers are checked
for state.
Every time of this run pid1 increase VSZ/RSS on ~ 232 Kb, this don't happen
on xenial and bionic releases.
I straced pid1 when that leak happen and found brk call.
On pmap view of pid 1 it's anon memory grow on the same address and all
marked as dirty.
All that leak memory can be freed by calling systemctl daemon-reexec.
Searching in systemd github repo i found this commit
https://github.com/systemd/systemd/commit/3fb2326f3ed87aa0b26078d307ebfb299e36286d
- it may be related to this leak.
Environment:
Distributor ID: Ubuntu
Description:Ubuntu 20.04.2 LTS
Release:20.04
Codename: focal
Uname: 5.4.0-77-generic #83-Ubuntu SMP Sat May 8 02:35:39 UTC 2021
x86_64
Package:
systemd:
Installed: 245.4-4ubuntu3.7
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1935051/+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 1935051] Re: systemd pid 1 memory leak
@bocmanpy, can you check with the version of systemd from -proposed
(instructions for how to install it are in comment 7) and verify it
still fixes the issue for you?
--
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/1935051
Title:
systemd pid 1 memory leak
Status in systemd package in Ubuntu:
Fix Released
Status in systemd source package in Focal:
Fix Committed
Bug description:
[impact]
pid1 leaks memory when rebuilding unit path cache
[test case]
see original description.
also, the patch contains an example of how to reproduce:
$ for i in {1..300}; do cp ~/.config/systemd/user/test0001.service
~/.config/systemd/user/test$(printf %04d $i).service; systemctl --user
start test$(printf %04d $i).service;done
[regression]
any problems would occur when rebuilding the path cache, possibly
resulting in memory leaks or pid1 crashes.
[scope]
this is needed only in f
fixed upstream by 3fb2326f3ed87aa0b26078d307ebfb299e36286d which is
included in v246, so fixed in h and later
the code in b is very different and doesn't appear to have the leak,
per original report
[original description]
Hi everybody.
We've meet a memory leak of pid1 process on the focal release.
When we launch chef-client, several systemd .service and .timers are checked
for state.
Every time of this run pid1 increase VSZ/RSS on ~ 232 Kb, this don't happen
on xenial and bionic releases.
I straced pid1 when that leak happen and found brk call.
On pmap view of pid 1 it's anon memory grow on the same address and all
marked as dirty.
All that leak memory can be freed by calling systemctl daemon-reexec.
Searching in systemd github repo i found this commit
https://github.com/systemd/systemd/commit/3fb2326f3ed87aa0b26078d307ebfb299e36286d
- it may be related to this leak.
Environment:
Distributor ID: Ubuntu
Description:Ubuntu 20.04.2 LTS
Release:20.04
Codename: focal
Uname: 5.4.0-77-generic #83-Ubuntu SMP Sat May 8 02:35:39 UTC 2021
x86_64
Package:
systemd:
Installed: 245.4-4ubuntu3.7
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1935051/+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 1939255] Re: dhclient triggers systemd-resolved start limit when processing more than 5 interfaces at once
ubuntu@lp1939255-b:~$ dpkg -l systemd|grep systemd ii systemd237-3ubuntu10.51 amd64system and service manager ubuntu@lp1939255-b:~$ sudo dhclient ens8 ens9 ens10 ens11 ens12 ens13 ens14 ens15 ubuntu@lp1939255-b:~$ journalctl --no-pager -b -u systemd-resolved -- Logs begin at Sun 2021-09-05 21:36:12 UTC, end at Sun 2021-09-05 21:41:06 UTC. -- ... Sep 05 21:40:57 lp1939255-b systemd[1]: systemd-resolved.service: Start request repeated too quickly. Sep 05 21:40:57 lp1939255-b systemd[1]: systemd-resolved.service: Failed with result 'start-limit-hit'. Sep 05 21:40:57 lp1939255-b systemd[1]: Failed to start Network Name Resolution. ubuntu@lp1939255-b:~$ dpkg -l systemd|grep systemd ii systemd237-3ubuntu10.52 amd64system and service manager ubuntu@lp1939255-b:~$ sudo dhclient ens8 ens9 ens10 ens11 ens12 ens13 ens14 ens15 ubuntu@lp1939255-b:~$ journalctl --no-pager -b -u systemd-resolved -- Logs begin at Sun 2021-09-05 21:36:12 UTC, end at Sun 2021-09-05 21:50:57 UTC. -- ... Sep 05 21:50:57 lp1939255-b systemd[1]: Started Network Name Resolution. ** Tags removed: verification-needed verification-needed-bionic verification-needed-focal ** Tags added: verification-done verification-done-bionic 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/1939255 Title: dhclient triggers systemd-resolved start limit when processing more than 5 interfaces at once Status in systemd package in Ubuntu: Invalid Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Bug description: [impact] on a system where systemd-resolved is running, if dhclient is used on more than 5 interfaces, it calls the '/etc/dhcp/dhclient-enter- hooks.d/resolved' script multiple times, which then restarts systemd- resolved multiple times, triggering the unit's start-limit throttle which results in the unit entering failed state [test case] on a system with more than 5 available interfaces to run dhclient on (where all the interfaces will get a dhcp response), run dhclient with the interfaces: $ dhclient ens8 ens9 ens10 ens11 ens12 ens13 ens14 ens15 check if systemd-resolved failed: $ journalctl -b -1 -u systemd-resolved ... Aug 09 00:38:08 sf316232-b systemd[1]: systemd-resolved.service: Start request repeated too quickly. Aug 09 00:38:08 sf316232-b systemd[1]: systemd-resolved.service: Failed with result 'start-limit-hit'. Aug 09 00:38:08 sf316232-b systemd[1]: Failed to start Network Name Resolution. [regression potential] failure to start/stop/restart systemd-resolved, or problems adding dhclient-provided DNS nameservers to systemd-resolved [scope] this is needed only for b/f the dhclient 'hook' script is provided by the systemd package in focal and earlier, and needs fixing in those releases in h and later, the 'hook' script is included in the isc-dhcp-client package and notifies systemd-resolved in a more direct way without requiring restarting, and so doesn't trigger the restart limiting. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1939255/+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 1939255] Re: dhclient triggers systemd-resolved start limit when processing more than 5 interfaces at once
ubuntu@lp1939255-f:~$ dpkg -l systemd|grep systemd ii systemd245.4-4ubuntu3.11 amd64system and service manager ubuntu@lp1939255-f:~$ sudo dhclient ens8 ens9 ens10 ens11 ens12 ens13 ens14 ens15 ubuntu@lp1939255-f:~$ journalctl --no-pager -b -u systemd-resolved -- Logs begin at Sun 2021-09-05 21:35:56 UTC, end at Sun 2021-09-05 21:40:13 UTC. -- ... Sep 05 21:40:13 lp1939255-f systemd[1]: systemd-resolved.service: Start request repeated too quickly. Sep 05 21:40:13 lp1939255-f systemd[1]: systemd-resolved.service: Failed with result 'start-limit-hit'. Sep 05 21:40:13 lp1939255-f systemd[1]: Failed to start Network Name Resolution. ubuntu@lp1939255-f:~$ dpkg -l systemd|grep systemd ii systemd245.4-4ubuntu3.12 amd64system and service manager ubuntu@lp1939255-f:~$ sudo dhclient ens8 ens9 ens10 ens11 ens12 ens13 ens14 ens15 ubuntu@lp1939255-f:~$ journalctl --no-pager -b -u systemd-resolved -- Logs begin at Sun 2021-09-05 21:35:56 UTC, end at Sun 2021-09-05 21:44:25 UTC. -- ... Sep 05 21:44:23 lp1939255-f systemd[1]: Started Network Name Resolution. -- 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/1939255 Title: dhclient triggers systemd-resolved start limit when processing more than 5 interfaces at once Status in systemd package in Ubuntu: Invalid Status in systemd source package in Bionic: Fix Committed Status in systemd source package in Focal: Fix Committed Bug description: [impact] on a system where systemd-resolved is running, if dhclient is used on more than 5 interfaces, it calls the '/etc/dhcp/dhclient-enter- hooks.d/resolved' script multiple times, which then restarts systemd- resolved multiple times, triggering the unit's start-limit throttle which results in the unit entering failed state [test case] on a system with more than 5 available interfaces to run dhclient on (where all the interfaces will get a dhcp response), run dhclient with the interfaces: $ dhclient ens8 ens9 ens10 ens11 ens12 ens13 ens14 ens15 check if systemd-resolved failed: $ journalctl -b -1 -u systemd-resolved ... Aug 09 00:38:08 sf316232-b systemd[1]: systemd-resolved.service: Start request repeated too quickly. Aug 09 00:38:08 sf316232-b systemd[1]: systemd-resolved.service: Failed with result 'start-limit-hit'. Aug 09 00:38:08 sf316232-b systemd[1]: Failed to start Network Name Resolution. [regression potential] failure to start/stop/restart systemd-resolved, or problems adding dhclient-provided DNS nameservers to systemd-resolved [scope] this is needed only for b/f the dhclient 'hook' script is provided by the systemd package in focal and earlier, and needs fixing in those releases in h and later, the 'hook' script is included in the isc-dhcp-client package and notifies systemd-resolved in a more direct way without requiring restarting, and so doesn't trigger the restart limiting. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1939255/+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
