[Touch-packages] [Bug 2040525] [NEW] running on LTS shouldn't warn because the devel branch can't be determined by distro-info
Public bug reported: Running on 22.04.3 LTS, specifically package version 2.8ubuntu1. The unattended-upgrades.log is full of WARNING Could not figure out development release: Distribution data outdated. Please check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for details. The note in README.Debian boils down to "make sure -updates is in sources.list", which it already is. This warning is triggered by the Unattended-Upgrade::DevRelease setting in /etc/apt/50unattended-upgrades being set to auto (the default). The code in /usr/bin/unattended-upgrades then calls distro_info.UbuntuDistroInfo().devel() which then throws a DistroDataOutdated. (I don't know *why* it's throwing that, as... $ distro-info --devel noble ...but that's neither here nor there for purposes of this bug report.) Can the "Unattended-Upgrade::DevRelease == auto" code path be made a little smarter for LTS releases? Testing "if currently running LTS then we're definitely not 'devel' in any case, so it doesn't matter how recent the distro-data file is, don't even bother checking it" seems reasonable. Or possibly 'Unattended-Upgrade::DevRelease' should default to false on LTS releases, although I appreciate that changing the default conffiles based on LTS-or-not can easily lead to some surprises. ** Affects: unattended-upgrades (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to unattended-upgrades in Ubuntu. https://bugs.launchpad.net/bugs/2040525 Title: running on LTS shouldn't warn because the devel branch can't be determined by distro-info Status in unattended-upgrades package in Ubuntu: New Bug description: Running on 22.04.3 LTS, specifically package version 2.8ubuntu1. The unattended-upgrades.log is full of WARNING Could not figure out development release: Distribution data outdated. Please check for an update for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for details. The note in README.Debian boils down to "make sure -updates is in sources.list", which it already is. This warning is triggered by the Unattended-Upgrade::DevRelease setting in /etc/apt/50unattended-upgrades being set to auto (the default). The code in /usr/bin/unattended-upgrades then calls distro_info.UbuntuDistroInfo().devel() which then throws a DistroDataOutdated. (I don't know *why* it's throwing that, as... $ distro-info --devel noble ...but that's neither here nor there for purposes of this bug report.) Can the "Unattended-Upgrade::DevRelease == auto" code path be made a little smarter for LTS releases? Testing "if currently running LTS then we're definitely not 'devel' in any case, so it doesn't matter how recent the distro-data file is, don't even bother checking it" seems reasonable. Or possibly 'Unattended-Upgrade::DevRelease' should default to false on LTS releases, although I appreciate that changing the default conffiles based on LTS-or-not can easily lead to some surprises. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/unattended-upgrades/+bug/2040525/+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 2011628] Re: Apparmor Disallows Disabling Dhclient Scripts
> Cloud-init users on these releases that wish to see no apparmour warnings
> might locally include this rule themselves via:
>
> echo " /bin/true Uxr," > /etc/apparmor.d/local/sbin.dhclient
Note for other users finding their way here via googling for error
messages: On jammy (22.04) at least, you will need to account for /bin
being a symlink to /usr/bin, and thus the line becomes (following the
standard brace syntax and also the ordering conventions in the default
apparmor profiles):
echo ' /{,usr/}bin/true Uxr,' > /etc/apparmor.d/local/sbin.dhclient
This will silence the execve warnings in 22.04.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.
https://bugs.launchpad.net/bugs/2011628
Title:
Apparmor Disallows Disabling Dhclient Scripts
Status in isc-dhcp package in Ubuntu:
Fix Released
Status in isc-dhcp source package in Focal:
New
Status in isc-dhcp source package in Jammy:
New
Status in isc-dhcp source package in Lunar:
New
Status in isc-dhcp package in Debian:
New
Bug description:
In some cases, it may be desirable to disable dhclient scripts. By
default /sbin/dhclient-script is used, and some others are allowed by
the apparmor profile.
Without Apparmor, disabling hook scripts can be accomplished with
flags -sf /bin/true, but with apparmor enabled this gets blocked:
execve (/bin/true, ...): Permission denied
Unfortunately dhclient doesn't appear to provide any other mechanism
for disabling hook scripts.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/2011628/+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 2035233] [NEW] install: -D ignores --owner/--group for intermediate directories
Public bug reported: This is on 22.04.3, using coreutils 8.32-4.1ubuntu1. We're wanting to populate an existing home directory with some starting example files. The system will be running on an AWS EC2 instance, so I'll use their default username "ubuntu" for this example: # touch sourcefile # mkdir -m 0755 existingdest # chown ubuntu:ubuntu existingdest We use install(1) to do the copying, permission and ownership management, and creating intermediate directories with its -D option: # install -vD --owner=ubuntu --group=ubuntu --mode=0644 sourcefile existingdest/intermediate/destfile install: creating directory 'existingdest/intermediate' 'sourcefile' -> 'existingdest/intermediate/destfile' That part looks good, however... # ls -lFd existingdest drwxr-xr-x 3 ubuntu ubuntu 4096 Sep 12 15:54 existingdest/ # ls -lF existingdest total 4 drwxr-xr-x 2 root root 4096 Sep 12 15:54 intermediate/ # ls -lF existingdest/intermediate/ total 0 -rw-r--r-- 1 ubuntu ubuntu 0 Sep 12 15:54 destfile ...while the pre-existing directory was left alone (correct) and the newly-created file has the specified ownership and permissions (also correct), the intermediate directories it created are still owned by root. I would not expect the creation of 'intermediate' to use the specified --mode because a directory with 0644 would be hilariously unhelpful. I would, however, expect the given --owner and --group to have played a part. That they didn't is violating the Law of Least Surprise, at least to me; if this isn't a bug, it should at least be documented. (I tried looking around https://github.com/coreutils/coreutils/blob/master/src/install.c to see if there was something obvious I was missing, but their coding style is not easy to read on a webpage.) ** Affects: coreutils (Ubuntu) Importance: Undecided Status: New ** Description changed: - This is on 22.04.2, using coreutils 8.32-4.1ubuntu1. + This is on 22.04.3, using coreutils 8.32-4.1ubuntu1. We're wanting to populate an existing home directory with some starting example files. The system will be running on an AWS EC2 instance, so I'll use their default username "ubuntu" for this example: # touch sourcefile # mkdir -m 0755 existingdest # chown ubuntu:ubuntu existingdest - - We use install(1) to do the copying, permission and ownership management, and creating intermediate directories with its -D option: + We use install(1) to do the copying, permission and ownership + management, and creating intermediate directories with its -D option: # install -vD --owner=ubuntu --group=ubuntu --mode=0644 sourcefile existingdest/intermediate/destfile install: creating directory 'existingdest/intermediate' 'sourcefile' -> 'existingdest/intermediate/destfile' That part looks good, however... # ls -lFd existingdest drwxr-xr-x 3 ubuntu ubuntu 4096 Sep 12 15:54 existingdest/ # ls -lF existingdest total 4 drwxr-xr-x 2 root root 4096 Sep 12 15:54 intermediate/ # ls -lF existingdest/intermediate/ total 0 -rw-r--r-- 1 ubuntu ubuntu 0 Sep 12 15:54 destfile ...while the pre-existing directory was left alone (correct) and the newly-created file has the specified ownership and permissions (also correct), the intermediate directories it created are still owned by root. I would not expect the creation of 'intermediate' to use the specified --mode because a directory with 0644 would be hilariously unhelpful. I would, however, expect the given --owner and --group to have played a part. That they didn't is violating the Law of Least Surprise, at least to me; if this isn't a bug, it should at least be documented. (I tried looking around https://github.com/coreutils/coreutils/blob/master/src/install.c to see if there was something obvious I was missing, but their coding style is not easy to read on a webpage.) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to coreutils in Ubuntu. https://bugs.launchpad.net/bugs/2035233 Title: install: -D ignores --owner/--group for intermediate directories Status in coreutils package in Ubuntu: New Bug description: This is on 22.04.3, using coreutils 8.32-4.1ubuntu1. We're wanting to populate an existing home directory with some starting example files. The system will be running on an AWS EC2 instance, so I'll use their default username "ubuntu" for this example: # touch sourcefile # mkdir -m 0755 existingdest # chown ubuntu:ubuntu existingdest We use install(1) to do the copying, permission and ownership management, and creating intermediate directories with its -D option: # install -vD --owner=ubuntu --group=ubuntu --mode=0644 sourcefile existingdest/intermediate/destfile install: creating directory 'existingdest/intermediate' 'sourcefile' -> 'existingdest/intermediate/destfile' That part looks good, however... # ls -lFd existingdest
[Touch-packages] [Bug 2018330] Re: routel script gives shift errors
Web form kept defaulting to package "avahi" no matter how many times I typed in iproute2... ** Package changed: avahi (Ubuntu) => iproute2 (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to iproute2 in Ubuntu. https://bugs.launchpad.net/bugs/2018330 Title: routel script gives shift errors Status in iproute2 package in Ubuntu: New Bug description: The routel(8) shell script is meant to format the output of ip(8) commands for human viewing, but the script is not robust enough. Running 22.04.2 LTS jammy jellyfish, freshly installed on an AWS EC2 instance and then "apt upgrade"d. (It's headless and remote, so it can't submit bug reports. I generated an apport file, but have no other Ubuntu system that could re-parse it to submit the report. But it's here if it would be useful.) The iproute2 package is: iproute2: Installed: 5.15.0-1ubuntu2 Candidate: 5.15.0-1ubuntu2 Version table: *** 5.15.0-1ubuntu2 500 500 http://us-east-2.ec2.archive.ubuntu.com/ubuntu jammy/main amd64 Packages 100 /var/lib/dpkg/status Here's the raw output of ip(8): $ ip route list table 0 default via 10.37.67.1 dev eth0 proto dhcp src 10.37.67.187 metric 100 10.37.64.2 via 10.37.67.1 dev eth0 proto dhcp src 10.37.67.187 metric 100 10.37.64.231 via 10.37.67.1 dev eth0 proto dhcp src 10.37.67.187 metric 100 10.37.65.30 via 10.37.67.1 dev eth0 proto dhcp src 10.37.67.187 metric 100 10.37.67.0/24 dev eth0 proto kernel scope link src 10.37.67.187 metric 100 10.37.67.1 dev eth0 proto dhcp scope link src 10.37.67.187 metric 100 local 10.37.67.187 dev eth0 table local proto kernel scope host src 10.37.67.187 broadcast 10.37.67.255 dev eth0 table local proto kernel scope link src 10.37.67.187 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 ::1 dev lo proto kernel metric 256 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium local ::1 dev lo table local proto kernel metric 0 pref medium local fe80::458:96ff:fe61:6829 dev eth0 table local proto kernel metric 0 pref medium multicast ff00::/8 dev eth0 table local proto kernel metric 256 pref medium Running routel, however, yields this: $ routel targetgateway sourceprotoscopedev tbl default 10.37.67.110.37.67.187 dhcpeth0 10.37.64.2 10.37.67.110.37.67.187 dhcpeth0 10.37.64.231 10.37.67.110.37.67.187 dhcpeth0 10.37.65.30 10.37.67.110.37.67.187 dhcpeth0 10.37.67.0/ 2410.37.67.187 kernel link eth0 10.37.67.1 10.37.67.187 dhcp link eth0 10.37.67.187 local10.37.67.187 kernel host eth0 local 10.37.67.255 broadcast10.37.67.187 kernel link eth0 local 127.0.0.0/ 8local 127.0.0.1 kernel host lo local 127.0.0.1 local 127.0.0.1 kernel host lo local 127.255.255.255 broadcast 127.0.0.1 kernel link lo local /usr/bin/routel: 48: shift: ::1 kernel lo fe80::/ 64 kerneleth0 ::1 local kernel lo local fe80::458:96ff:fe61:6829 local kernel eth0 local can't shift that many Splitting stdout and stderr for readability: $ routel 2> /tmp/err targetgateway sourceprotoscopedev tbl default 10.37.67.110.37.67.187 dhcpeth0 10.37.64.2 10.37.67.110.37.67.187 dhcpeth0 10.37.64.231 10.37.67.110.37.67.187 dhcpeth0 10.37.65.30 10.37.67.110.37.67.187 dhcpeth0 10.37.67.0/ 2410.37.67.187 kernel link eth0 10.37.67.1 10.37.67.187 dhcp link eth0 10.37.67.187 local10.37.67.187 kernel host eth0 local 10.37.67.255 broadcast10.37.67.187 kernel link eth0 local 127.0.0.0/ 8local 127.0.0.1 kernel host lo local 127.0.0.1 local 127.0.0.1 kernel host lo local 127.255.255.255 broadcast 127.0.0.1 kernel link lo local ::1 kernel lo fe80::/ 64
[Touch-packages] [Bug 2018330] [NEW] routel script gives shift errors
Public bug reported: The routel(8) shell script is meant to format the output of ip(8) commands for human viewing, but the script is not robust enough. Running 22.04.2 LTS jammy jellyfish, freshly installed on an AWS EC2 instance and then "apt upgrade"d. (It's headless and remote, so it can't submit bug reports. I generated an apport file, but have no other Ubuntu system that could re-parse it to submit the report. But it's here if it would be useful.) The iproute2 package is: iproute2: Installed: 5.15.0-1ubuntu2 Candidate: 5.15.0-1ubuntu2 Version table: *** 5.15.0-1ubuntu2 500 500 http://us-east-2.ec2.archive.ubuntu.com/ubuntu jammy/main amd64 Packages 100 /var/lib/dpkg/status Here's the raw output of ip(8): $ ip route list table 0 default via 10.37.67.1 dev eth0 proto dhcp src 10.37.67.187 metric 100 10.37.64.2 via 10.37.67.1 dev eth0 proto dhcp src 10.37.67.187 metric 100 10.37.64.231 via 10.37.67.1 dev eth0 proto dhcp src 10.37.67.187 metric 100 10.37.65.30 via 10.37.67.1 dev eth0 proto dhcp src 10.37.67.187 metric 100 10.37.67.0/24 dev eth0 proto kernel scope link src 10.37.67.187 metric 100 10.37.67.1 dev eth0 proto dhcp scope link src 10.37.67.187 metric 100 local 10.37.67.187 dev eth0 table local proto kernel scope host src 10.37.67.187 broadcast 10.37.67.255 dev eth0 table local proto kernel scope link src 10.37.67.187 local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1 local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1 broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1 ::1 dev lo proto kernel metric 256 pref medium fe80::/64 dev eth0 proto kernel metric 256 pref medium local ::1 dev lo table local proto kernel metric 0 pref medium local fe80::458:96ff:fe61:6829 dev eth0 table local proto kernel metric 0 pref medium multicast ff00::/8 dev eth0 table local proto kernel metric 256 pref medium Running routel, however, yields this: $ routel targetgateway sourceprotoscopedev tbl default 10.37.67.110.37.67.187 dhcpeth0 10.37.64.2 10.37.67.110.37.67.187 dhcpeth0 10.37.64.231 10.37.67.110.37.67.187 dhcpeth0 10.37.65.30 10.37.67.110.37.67.187 dhcpeth0 10.37.67.0/ 2410.37.67.187 kernel link eth0 10.37.67.1 10.37.67.187 dhcp link eth0 10.37.67.187 local10.37.67.187 kernel host eth0 local 10.37.67.255 broadcast10.37.67.187 kernel link eth0 local 127.0.0.0/ 8local 127.0.0.1 kernel host lo local 127.0.0.1 local 127.0.0.1 kernel host lo local 127.255.255.255 broadcast 127.0.0.1 kernel link lo local /usr/bin/routel: 48: shift: ::1 kernel lo fe80::/ 64 kerneleth0 ::1 local kernel lo local fe80::458:96ff:fe61:6829 local kernel eth0 local can't shift that many Splitting stdout and stderr for readability: $ routel 2> /tmp/err targetgateway sourceprotoscopedev tbl default 10.37.67.110.37.67.187 dhcpeth0 10.37.64.2 10.37.67.110.37.67.187 dhcpeth0 10.37.64.231 10.37.67.110.37.67.187 dhcpeth0 10.37.65.30 10.37.67.110.37.67.187 dhcpeth0 10.37.67.0/ 2410.37.67.187 kernel link eth0 10.37.67.1 10.37.67.187 dhcp link eth0 10.37.67.187 local10.37.67.187 kernel host eth0 local 10.37.67.255 broadcast10.37.67.187 kernel link eth0 local 127.0.0.0/ 8local 127.0.0.1 kernel host lo local 127.0.0.1 local 127.0.0.1 kernel host lo local 127.255.255.255 broadcast 127.0.0.1 kernel link lo local ::1 kernel lo fe80::/ 64 kerneleth0 ::1 local kernel lo local fe80::458:96ff:fe61:6829 local kernel eth0 local $ cat /tmp/err /usr/bin/routel: 48: shift: can't shift that many $ It's giving the same errors as in Debian bug 875476 some six years ago, which was "fixed in upstream" and then apparently broken again. ** Affects: avahi (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because
[Touch-packages] [Bug 1958676] Re: error: too early for operation, device not yet seeded or device model not acknowledged Install failed
I see the same "could not execute" error on a fresh 22.04 Jammy system, when installing the 'sssd' metapackage. The install ends with: Created symlink /etc/systemd/system/sssd.service.wants/sssd-autofs.socket → /lib/systemd/system/sssd-autofs.socket. Created symlink /etc/systemd/system/sssd.service.wants/sssd-nss.socket → /lib/systemd/system/sssd-nss.socket. Created symlink /etc/systemd/system/sssd.service.wants/sssd-pam-priv.socket → /lib/systemd/system/sssd-pam-priv.socket. Created symlink /etc/systemd/system/sssd.service.wants/sssd-pam.socket → /lib/systemd/system/sssd-pam.socket. Created symlink /etc/systemd/system/sssd.service.wants/sssd-ssh.socket → /lib/systemd/system/sssd-ssh.socket. Created symlink /etc/systemd/system/sssd.service.wants/sssd-sudo.socket → /lib/systemd/system/sssd-sudo.socket. Created symlink /etc/systemd/system/multi-user.target.wants/sssd.service → /lib/systemd/system/sssd.service. sssd-autofs.service is a disabled or a static unit, not starting it. sssd-nss.service is a disabled or a static unit, not starting it. sssd-pam.service is a disabled or a static unit, not starting it. sssd-ssh.service is a disabled or a static unit, not starting it. sssd-sudo.service is a disabled or a static unit, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142. Setting up sssd-proxy (2.6.3-1ubuntu3.1) ... Setting up sssd-ad-common (2.6.3-1ubuntu3.1) ... Created symlink /etc/systemd/system/sssd.service.wants/sssd-pac.socket → /lib/systemd/system/sssd-pac.socket. sssd-pac.service is a disabled or a static unit, not starting it. Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142. Setting up sssd-krb5-common (2.6.3-1ubuntu3.1) ... Setting up libsmbclient:amd64 (2:4.15.5~dfsg-0ubuntu5.1) ... Setting up sssd-krb5 (2.6.3-1ubuntu3.1) ... Setting up sssd-ldap (2.6.3-1ubuntu3.1) ... Setting up sssd-ad (2.6.3-1ubuntu3.1) ... Setting up sssd-ipa (2.6.3-1ubuntu3.1) ... Setting up sssd (2.6.3-1ubuntu3.1) ... ** Also affects: sssd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1958676 Title: error: too early for operation, device not yet seeded or device model not acknowledged Install failed Status in launchpad-buildd: New Status in init-system-helpers package in Ubuntu: New Status in snapd package in Ubuntu: New Status in sssd package in Ubuntu: New Status in systemd package in Ubuntu: New Bug description: https://launchpad.net/~ubuntu-core-service/+snap/core22/+build/1650565 New deb-systemd-invoke added functionality for systemd v250 which ubuntu does not have yet. But it also appears to break postinst calls to deb-systemd-invoke, at least as seen during snap builds in lxd containers operated by launchpad-buildd. I wonder if there is a regression in new code, or new systemd, which may warrant a revert. To manage notifications about this bug go to: https://bugs.launchpad.net/launchpad-buildd/+bug/1958676/+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 1803601] Re: motd-news.service scheduled even when /etc/update-motd.d/50-motd-news is not executable
I should also have mentioned that 'ubuntu-server' has a hard dependency on 'motd-news-config', so anybody wanting a standard server-type installation will automatically get the advert updater and /etc/default/motd-news. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to base-files in Ubuntu. https://bugs.launchpad.net/bugs/1803601 Title: motd-news.service scheduled even when /etc/update-motd.d/50-motd-news is not executable Status in base-files package in Ubuntu: Triaged Bug description: update-motd(5) says: Executable scripts in /etc/update-motd.d/* are executed by pam_motd(8) as the root user at each login, and this information is concatenated in /run/motd.dynamic. The order of script execu‐ tion is determined by the run-parts(8) --lsbsysinit option (basically alphabetical order, with a few caveats). So sysadmins are used to "chmod -x" motd fragments from /etc/update- motd.d/ to prevent their execution. When doing so for /etc/update- motd.d/50-motd-news, I noticed that motd-news.timer was still trying to execute the motd-news.service unit which then logged a failure: systemd[3704]: motd-news.service: Failed to execute command: Permission denied systemd[3704]: motd-news.service: Failed at step EXEC spawning /etc/update-motd.d/50-motd-news: Permission denied systemd[1]: motd-news.service: Main process exited, code=exited, status=203/EXEC systemd[1]: motd-news.service: Failed with result 'exit-code'. systemd[1]: Failed to start Message of the Day. The motd-news.service unit looks like this: $ systemctl cat motd-news.service # /lib/systemd/system/motd-news.service [Unit] Description=Message of the Day After=network-online.target Documentation=man:update-motd(8) [Service] Type=oneshot ExecStart=/etc/update-motd.d/50-motd-news --force This problem was observed on a Bionic system: $ lsb_release -rd Description: Ubuntu 18.04.1 LTS Release: 18.04 $ apt-cache policy base-files base-files: Installed: 10.1ubuntu2.3 Candidate: 10.1ubuntu2.3 Version table: *** 10.1ubuntu2.3 500 500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 10.1ubuntu2.2 500 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 10.1ubuntu2 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages But the problem also exist in Disco. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1803601/+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 1803601] Re: motd-news.service scheduled even when /etc/update-motd.d/50-motd-news is not executable
Simon Déziel (sdeziel) wrote: > IIRC, `chmod -x` snippets from /etc/update-motd.d/ was the way to go a > few releases ago when it was consumed by run-parts. In 22.04 it's still handled by run-parts, and the man page documents it as such. Specifically by $ strings /lib/x86_64-linux-gnu/security/pam_motd.so | grep run-parts /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new in its primary use case. The "fetch new ads on boot" motd-news.service for this bug report runs one of the scripts directly, but the directory is still a run-parts input. We could disable scripts by renaming them to something that won't be found by the '--lsbsysinit' file patterns, but that would only solve the problem for "at login" updates, not the "at boot" updates through systemd. > It's merely to avoid harmless surprise and keep the old sysadmins happy, Service errors is hardly a "surprise", and you don't need to be condescending about it. wontfix (wontfix) wrote: > and that is to set ENABLED=0 in /etc/default/motd-news." > > This file no longer exists by default in Ubuntu 22.04 Jammy. $ grep VERSION /etc/os-release VERSION_ID="22.04" VERSION="22.04 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy $ dpkg -S /etc/default/motd-news motd-news-config: /etc/default/motd-news $ apt show motd-news-config Package: motd-news-config Priority: optional Source: base-files Task: cloud-image, ubuntu-wsl, server, ubuntu-server-raspi APT-Manual-Installed: no [several header elided] It certainly existed by default from the beginning of the server installation I'm working with. However, it's "priority: optional" so perhaps that's what you mean by "not default"; it likely wouldn't be there for a standard desktop installation. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to base-files in Ubuntu. https://bugs.launchpad.net/bugs/1803601 Title: motd-news.service scheduled even when /etc/update-motd.d/50-motd-news is not executable Status in base-files package in Ubuntu: Triaged Bug description: update-motd(5) says: Executable scripts in /etc/update-motd.d/* are executed by pam_motd(8) as the root user at each login, and this information is concatenated in /run/motd.dynamic. The order of script execu‐ tion is determined by the run-parts(8) --lsbsysinit option (basically alphabetical order, with a few caveats). So sysadmins are used to "chmod -x" motd fragments from /etc/update- motd.d/ to prevent their execution. When doing so for /etc/update- motd.d/50-motd-news, I noticed that motd-news.timer was still trying to execute the motd-news.service unit which then logged a failure: systemd[3704]: motd-news.service: Failed to execute command: Permission denied systemd[3704]: motd-news.service: Failed at step EXEC spawning /etc/update-motd.d/50-motd-news: Permission denied systemd[1]: motd-news.service: Main process exited, code=exited, status=203/EXEC systemd[1]: motd-news.service: Failed with result 'exit-code'. systemd[1]: Failed to start Message of the Day. The motd-news.service unit looks like this: $ systemctl cat motd-news.service # /lib/systemd/system/motd-news.service [Unit] Description=Message of the Day After=network-online.target Documentation=man:update-motd(8) [Service] Type=oneshot ExecStart=/etc/update-motd.d/50-motd-news --force This problem was observed on a Bionic system: $ lsb_release -rd Description: Ubuntu 18.04.1 LTS Release: 18.04 $ apt-cache policy base-files base-files: Installed: 10.1ubuntu2.3 Candidate: 10.1ubuntu2.3 Version table: *** 10.1ubuntu2.3 500 500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages 100 /var/lib/dpkg/status 10.1ubuntu2.2 500 500 http://security.ubuntu.com/ubuntu bionic-security/main amd64 Packages 10.1ubuntu2 500 500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages But the problem also exist in Disco. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1803601/+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
