** Description changed: + What's known so far: + - 24.04 desktop deployed with TPM+FDE shows this bug + - services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode + - only after running aa-disable <path> can the service start fine + - paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......" + - other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism + - comment #2 also states that azure CVM images are also impacted + + + Original description follows: + This might be related to #2064088 The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally. In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: rsyslog 8.2312.0-3ubuntu9 ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1 Uname: Linux 6.8.0-31-generic x86_64 ApportVersion: 2.28.1-0ubuntu2 Architecture: amd64 CasperMD5CheckMismatches: ./boot/grub/grub.cfg CasperMD5CheckResult: fail CurrentDesktop: ubuntu:GNOME Date: Mon Apr 29 10:37:46 2024 ProcEnviron: - LANG=en_GB.UTF-8 - PATH=(custom, no user) - SHELL=/bin/bash - TERM=xterm-256color - XDG_RUNTIME_DIR=<set> + LANG=en_GB.UTF-8 + PATH=(custom, no user) + SHELL=/bin/bash + TERM=xterm-256color + XDG_RUNTIME_DIR=<set> SourcePackage: rsyslog UpgradeStatus: No upgrade log present (probably fresh install)
** Description changed: What's known so far: - 24.04 desktop deployed with TPM+FDE shows this bug - services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode - only after running aa-disable <path> can the service start fine - paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......" - other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism - comment #2 also states that azure CVM images are also impacted - + - comment #4 has instructions on how to create such a VM locally with LXD vms Original description follows: This might be related to #2064088 The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally. In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: rsyslog 8.2312.0-3ubuntu9 ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1 Uname: Linux 6.8.0-31-generic x86_64 ApportVersion: 2.28.1-0ubuntu2 Architecture: amd64 CasperMD5CheckMismatches: ./boot/grub/grub.cfg CasperMD5CheckResult: fail CurrentDesktop: ubuntu:GNOME Date: Mon Apr 29 10:37:46 2024 ProcEnviron: LANG=en_GB.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> SourcePackage: rsyslog UpgradeStatus: No upgrade log present (probably fresh install) ** Description changed: What's known so far: - 24.04 desktop deployed with TPM+FDE shows this bug - - services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode + - services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode. And the apparmor profile does already have rules to allow that access - only after running aa-disable <path> can the service start fine - - paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......" + - paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......". When we add rules to the profile using "/systemd/...." (i.e., also dropping the /run prefix), then it works - other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism - comment #2 also states that azure CVM images are also impacted - comment #4 has instructions on how to create such a VM locally with LXD vms Original description follows: This might be related to #2064088 The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally. In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: rsyslog 8.2312.0-3ubuntu9 ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1 Uname: Linux 6.8.0-31-generic x86_64 ApportVersion: 2.28.1-0ubuntu2 Architecture: amd64 CasperMD5CheckMismatches: ./boot/grub/grub.cfg CasperMD5CheckResult: fail CurrentDesktop: ubuntu:GNOME Date: Mon Apr 29 10:37:46 2024 ProcEnviron: LANG=en_GB.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> SourcePackage: rsyslog UpgradeStatus: No upgrade log present (probably fresh install) ** Description changed: What's known so far: - 24.04 desktop deployed with TPM+FDE shows this bug - services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode. And the apparmor profile does already have rules to allow that access - only after running aa-disable <path> can the service start fine - - paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......". When we add rules to the profile using "/systemd/...." (i.e., also dropping the /run prefix), then it works + - paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......". + - When we add rules to the profile using "/systemd/...." (i.e., also dropping the /run prefix), then it works - other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism - comment #2 also states that azure CVM images are also impacted - comment #4 has instructions on how to create such a VM locally with LXD vms Original description follows: This might be related to #2064088 The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally. In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: rsyslog 8.2312.0-3ubuntu9 ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1 Uname: Linux 6.8.0-31-generic x86_64 ApportVersion: 2.28.1-0ubuntu2 Architecture: amd64 CasperMD5CheckMismatches: ./boot/grub/grub.cfg CasperMD5CheckResult: fail CurrentDesktop: ubuntu:GNOME Date: Mon Apr 29 10:37:46 2024 ProcEnviron: LANG=en_GB.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> SourcePackage: rsyslog UpgradeStatus: No upgrade log present (probably fresh install) -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to cups in Ubuntu. https://bugs.launchpad.net/bugs/2064096 Title: Services fail to start in noble deployed with TPM+FDE Status in cups package in Ubuntu: Confirmed Status in rsyslog package in Ubuntu: Confirmed Status in sssd package in Ubuntu: Confirmed Bug description: What's known so far: - 24.04 desktop deployed with TPM+FDE shows this bug - services confined with apparmor that need to access something in /run/systemd (like the notify socket) fail to do so, even if the apparmor profile is in complain mode. And the apparmor profile does already have rules to allow that access - only after running aa-disable <path> can the service start fine - paths logged by the apparmor DENIED or ALLOWED messages are missing the "/run" prefix from "/run/systemd/......". - When we add rules to the profile using "/systemd/...." (i.e., also dropping the /run prefix), then it works - other access in /run/systemd/ are also blocked, but the most noticeable one is the notify mechanism - comment #2 also states that azure CVM images are also impacted - comment #4 has instructions on how to create such a VM locally with LXD vms Original description follows: This might be related to #2064088 The rsyslog service is continually timing out and restarting. If I use a service drop-in file and change the 'Type' from 'notify' to 'simple', the service starts and appears to work normally. In the journal, I can see the attached apparmor errors. I can't make sense of them, but if it's a similar issue to #2064088, then I suspect apparmor is preventing the systemd notify function from alerting systemd that the service is up and running. ProblemType: Bug DistroRelease: Ubuntu 24.04 Package: rsyslog 8.2312.0-3ubuntu9 ProcVersionSignature: Ubuntu 6.8.0-31.31-generic 6.8.1 Uname: Linux 6.8.0-31-generic x86_64 ApportVersion: 2.28.1-0ubuntu2 Architecture: amd64 CasperMD5CheckMismatches: ./boot/grub/grub.cfg CasperMD5CheckResult: fail CurrentDesktop: ubuntu:GNOME Date: Mon Apr 29 10:37:46 2024 ProcEnviron: LANG=en_GB.UTF-8 PATH=(custom, no user) SHELL=/bin/bash TERM=xterm-256color XDG_RUNTIME_DIR=<set> SourcePackage: rsyslog UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups/+bug/2064096/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
