Warning: The unit file, source configuration file or drop-ins of {apt-news,esm-cache}.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
snapd |
New
|
Undecided
|
Zygmunt Krynicki | ||
ubuntu-advantage-tools (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
I recently started seeing the following warning messages when I run `apt update`.
$ sudo apt update
Warning: The unit file, source configuration file or drop-ins of apt-news.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Warning: The unit file, source configuration file or drop-ins of esm-cache.service changed on disk. Run 'systemctl daemon-reload' to reload units.
...
apt-news.service for example is in /lib/systemd/
$ systemctl cat apt-news.service
# /usr/lib/
# APT News is hosted at https:/
# timely information related to apt updates available to your system.
...
$ dpkg -S /lib/systemd/
ubuntu-pro-client: /lib/systemd/
ProblemType: BugDistroRelease: Ubuntu 24.04
Package: ubuntu-pro-client 31.1
ProcVersionSign
Uname: Linux 6.6.0-14-generic x86_64
NonfreeKernelMo
ApportVersion: 2.28.0-0ubuntu1
Architecture: amd64
CasperMD5CheckR
CurrentDesktop: ubuntu:GNOME
Date: Wed Feb 28 13:06:35 2024
InstallationDate: Installed on 2024-01-08 (51 days ago)
InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Daily amd64 (20240104)
ProcEnviron:
LANG=en_US.UTF-8
PATH=(custom, no user)
SHELL=/bin/bash
TERM=xterm-
XDG_RUNTIME_
UpgradeStatus: No upgrade log present (probably fresh install)
apparmor_logs.txt:
cloud-id.txt-error:
Failed running command 'cloud-id' [exit(2)]. Message: REDACTED config part /etc/cloud/
REDACTED config part /etc/cloud/
REDACTED config part /etc/cloud/
REDACTED config part /etc/cloud/
livepatch-
uaclient.conf:
contract_url: https:/
log_level: debug
Nobuto Murata (nobuto) wrote : | #1 |
- Dependencies.txt Edit (2.5 KiB, text/plain; charset="utf-8")
- ProcCpuinfoMinimal.txt Edit (1.6 KiB, text/plain; charset="utf-8")
- pro-journal.txt.txt Edit (58.0 KiB, text/plain; charset="utf-8")
- ua-status.json.txt Edit (1.7 KiB, text/plain; charset="utf-8")
- ubuntu-advantage.log.txt Edit (87.8 KiB, text/plain; charset="utf-8")
- ubuntu_pro_apt_news.txt Edit (944 bytes, text/plain; charset="utf-8")
information type: | Private → Public |
tags: | removed: need-amd64-retrace |
Renan Rodrigo (renanrodrigo) wrote : | #2 |
Changed in ubuntu-advantage-tools (Ubuntu): | |
status: | New → Incomplete |
Nobuto Murata (nobuto) wrote : | #3 |
- apt-terminal.log Edit (21.5 KiB, text/plain)
It was puzzling indeed, but now I have a reproduction step.
$ sudo apt update
-> no warning
$ sudo apt upgrade
-> to install something to invoke the rsyslog trigger.
Processing triggers for rsyslog (8.2312.0-3ubuntu3) ...
Warning: The unit file, source configuration file or drop-ins of rsyslog.service changed on disk. Run 'systemctl daemon-reload' to reload units.
$ sudo apt update
-> will see the warning.
The warning happens with every systemctl commands so it's not really ubuntu-pro-tools specific issue. However, systemctl warnings are not expected with `apt` commands usually so that's why this could be considered as a surprise. For fixing this properly, the place may not be in pro-tools itself but somewhere else.
Changed in ubuntu-advantage-tools (Ubuntu): | |
status: | Incomplete → New |
Alberto Contreras (aciba) wrote : | #4 |
Hello Nobutu. Thanks again for reporting this.
I have been trying to reproduce the error with no success. I tried some combinations of:
- In lxd container with [jammy, noble]
- [pro downgrade / upgrade targeting 31.1]
- pro enable / disable
- [pro downgrade / upgrade targeting 31.1]
- apt updadate
- apt upgrade
Could you please provide more information about it?
Many thanks.
Changed in ubuntu-advantage-tools (Ubuntu): | |
status: | New → Incomplete |
Nobuto Murata (nobuto) wrote : | #5 |
I tried to minimize the test case but no luck so far. I will report it back whenever I find something additional.
Paride Legovini (paride) wrote : | #6 |
Interestingly this is now happening on my Noble system:
$ sudo apt update
Warning: The unit file, source configuration file or drop-ins of apt-news.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Warning: The unit file, source configuration file or drop-ins of esm-cache.service changed on disk. Run 'systemctl daemon-reload' to reload units.
I'm quite sure I didn't manually touch those units.
I first noticed this yesterday 2024-03-03, where apparently nothing relevant happened wrt the u-a-t package. I have 31.1 installed, from the release pocket.
Paride Legovini (paride) wrote : | #7 |
Now I remember one relevant thing that happened in the past 48h: I rebooted the affected system.
Christian Ehrhardt (paelzer) wrote : | #8 |
Whoever hits this please help us to spot the difference that happened as we still lack a reproducer.
# check if it has been changed
dpkg --verify ubuntu-
# check if there are drop ins that got added
systemctl cat apt-news.service
@nobotu - was yours really an empty file or did you not copy more than one?
description: | updated |
Nobuto Murata (nobuto) wrote : | #9 |
> @nobotu - was yours really an empty file or did you not copy more than one?
Are you referring to the `systemctl cat apt-news.service` in the bug description? If so, my apologies. I just pasted the file line of the content on purpose just for confirming the full path of the service. The flie wasn't empty at all and I didn't touch the file manually at all either.
Nobuto Murata (nobuto) wrote : | #10 |
Just for completeness.
$ sudo apt update
Warning: The unit file, source configuration file or drop-ins of apt-news.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Warning: The unit file, source configuration file or drop-ins of esm-cache.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Hit:1 http://
Hit:2 http://
Hit:3 http://
Hit:4 http://
Hit:5 https:/
Hit:6 https:/
Hit:7 http://
Get:8 https:/
Fetched 6,563 B in 1s (6,699 B/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
67 packages can be upgraded. Run 'apt list --upgradable' to see them.
$ dpkg --verify ubuntu-
0
$ apt policy ubuntu-
ubuntu-
Installed: 31.1
Candidate: 31.1
Version table:
31.2 100
100 http://
100 http://
*** 31.1 500
500 http://
500 http://
100 /var/lib/
$ systemctl cat apt-news.service
# /usr/lib/
# APT News is hosted at https:/
# timely information related to apt updates available to your system.
# This service runs in the background during an `apt update` to download the
# latest news and set it to appear in the output of the next `apt upgrade`.
# The script won't do anything if you've run: `pro config set apt_news=false`.
# The script will limit network requests to at most once per 24 hours.
# You can also host your own aptnews.json and configure your system to use it
# with the command:
# `pro config set apt_news_url=https:/
[Unit]
Description=Update APT News
[Service]
Type=oneshot
ExecStart=
AppArmorProfile
CapabilityBound
CapabilityBound
CapabilityBound
CapabilityBound
CapabilityBound
PrivateTmp=true
RestrictAddress
RestrictAddress
# These may break some tests, and should be enabled carefully
#NoNewPrivilege
#PrivateDevices
#ProtectControl
# ProtectHome=true seems to reliably break the GH integration test with a lunar lxd on jammy host
#ProtectHome=true
#ProtectKernelM
#ProtectKernelT
#ProtectSystem=full
#RestrictSUIDSG
# Unsupported in bionic
# Suggestion from systemd.exec(5) manpage on SystemCallFilter
#SystemCallFilt
#SystemCallFilt
#SystemC...
Nobuto Murata (nobuto) wrote : | #11 |
The list of files modified in the last two hours (if I increase the range to the last 2 days, it lists almost everything).
$ find /etc/systemd /lib/systemd/ -mmin -7200
/etc/systemd/system
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/lib/systemd/system
/lib/systemd/
/lib/systemd/
Nobuto Murata (nobuto) wrote (last edit ): | #12 |
Hmm, it happened again between those two `apt update`. It might be snapd related.
2024-03-
2024-03-
$ uptime
11:01:51 up 14 min, 1 user, load average: 0.91, 0.90, 0.75
$ find /etc/systemd /lib/systemd -mmin -15
/etc/systemd/system
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
/etc/systemd/
$ snap refresh --time
timer: 00:00~24:00/4
last: today at 10:53 JST
next: today at 17:07 JST
Grant Orndorff (orndorffgrant) wrote : | #13 |
Thank you nobuto! With that I was able to reproduce the issue.
lxc launch ubuntu-daily:noble test
lxc exec test -- apt update # this one works as expected
lxc exec test -- snap install snapd
lxc exec test -- apt update # this one has the warnings in the bug report
assigning this bug to snapd
Haw Loeung (hloeung) wrote : | #14 |
Seeing this myself:
| $ sudo apt-get update
| Warning: The unit file, source configuration file or drop-ins of apt-news.service changed on disk. Run 'systemctl daemon-reload' to reload units.
| Warning: The unit file, source configuration file or drop-ins of esm-cache.service changed on disk. Run 'systemctl daemon-reload' to reload units.
zeroc (zero-c) wrote : | #15 |
I get the same warnings after editing 3 files /etc/apt/
Warning: The unit file, source configuration file or drop-ins of apt-news.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Warning: The unit file, source configuration file or drop-ins of esm-cache.service changed on disk. Run 'systemctl daemon-reload' to reload units.
OK:1 http://
Holen:2 https:/
OK:3 https:/
OK:4 https:/
OK:5 http://
OK:6 https:/
OK:7 https:/
OK:8 https:/
Holen:9 https:/
OK:10 http://
OK:11 http://
OK:12 https:/
OK:13 https:/
OK:14 https:/
OK:15 https:/
Holen:16 https:/
Holen:17 https:/
Holen:18 https:/
Es wurden 77,8 kB in 2 s geholt (38,7 kB/s).
Changed in snapd: | |
assignee: | nobody → Zygmunt Krynicki (zyga) |
Zygmunt Krynicki (zyga) wrote : | #16 |
I've reproduced this and collected forkstat logs from installation of snapd snap on an otherwise pristine "noble" system. I think what is going on is that systemd stays in a mode where it knows that units on disk have changed vs units in memory and will print the warning until re-loaded. The fact that apt hooks fiddle with systemd units is sufficient for printing the warning:
apt update causes this thing to execute:
10:37:56 exec 3523 sh -c -- [ ! -e /run/systemd/system ] || [ $(id -u) -ne 0 ] || systemctl start --no-block apt-news.service esm-cache.service || true
This is enough for the warning.
The remaining question is where in the installation of snapd do we modify units after last daemon-reload. I'm focusing on that aspect now.
Zygmunt Krynicki (zyga) wrote : | #17 |
Snapd touches neither apt-news.service nor esm-cache.service.
On my system the only mention of esm-cache.service is in uaclient/
zyga@ciri:/$ grep -FR esm-cache.service usr/ 2>/dev/null
usr/lib/
I've increased systemd logging to debug to see what is replacing the service but I cannot find any evidence of that in the logs.
Zygmunt Krynicki (zyga) wrote : | #18 |
Removing ubuntu-pro-client silences this, so that installation of snapd snap no longer causes any side-effects. While I can see that installation of snapd has some impact on ubuntu-pro-client, I cannot yet understand how.
Andreas Hasenack (ahasenack) wrote : | #19 |
Check the postinst script of the binary packages produced by src:ubuntu-
Nobuto Murata (nobuto) wrote : | #20 |
It's not the apt-news nor esm-cache service that was modified.
It looks like systemd warns about daemon-reload in any cases if any of the systemd unit files are modified and daemon-reload wasn't called after that.
https:/
Andreas Hasenack (ahasenack) wrote : | #21 |
> It's not the apt-news nor esm-cache service that was modified.
> It looks like systemd warns about daemon-reload in any cases if any of the systemd unit files are
> modified and daemon-reload wasn't called after that.
I understand, but in comment #14 the warning is very specific about the unit files that changed: apt-news.service and esm-cache.service
Could it be that something else installed an override config for those units elsewhere (/run, or /etc), and then didn't issue the daemon-reload?
Could we get an "systemctl cat apt-news.service esm-cache.service" output after this warning? It will say which files exactly are being considered, if it's just /lib/systemd/
Zygmunt Krynicki (zyga) wrote : | #22 |
With a closer look I ended up running this loop while looking at systemd debug logs:
sudo snap remove --purge snapd && sudo systemctl daemon-reload && sudo systemctl restart snapd && snap version && sudo apt update && echo "ALOHA: installing snapd" | systemd-cat && sudo snap install snapd && echo "ALOHA: done installing snapd" | systemd-cat
This causes the following log file to show up:
mar 13 13:02:52 ciri systemd[1]: Looking for unit files in (higher priority first):
mar 13 13:02:52 ciri systemd[1]: /etc/systemd/
mar 13 13:02:52 ciri systemd[1]: /run/systemd/
mar 13 13:02:52 ciri systemd[1]: /run/systemd/
mar 13 13:02:52 ciri systemd[1]: /run/systemd/
mar 13 13:02:52 ciri systemd[1]: /etc/systemd/system
mar 13 13:02:52 ciri systemd[1]: /etc/systemd/
mar 13 13:02:52 ciri systemd[1]: /run/systemd/system
mar 13 13:02:52 ciri systemd[1]: /run/systemd/
mar 13 13:02:52 ciri systemd[1]: /run/systemd/
mar 13 13:02:52 ciri systemd[1]: /usr/local/
mar 13 13:02:52 ciri systemd[1]: /usr/lib/
mar 13 13:02:52 ciri systemd[1]: /run/systemd/
mar 13 13:02:52 ciri systemd[1]: Modification times have changed, need to update cache.
The message at the bottom of the log comes from systemd's src/basic/
bool lookup_
struct siphash state;
if (lookup_
/* Determine the latest lookup path modification time */
if (stat(*dir, &st) < 0) {
}
}
uint64_t updated = siphash24_
if (ret_new)
if (updated != timestamp_hash)
return updated == timestamp_hash;
}
Modification of mtime of any of the directories above is sufficient to cause this to differ.
I've patched systemd to tell us why systemd thinks it needs to be reloaded (additional printfs) to get an idea what might be the trigger that is left stale.
Zygmunt Krynicki (zyga) wrote : | #23 |
Both before and after daemon-reload the units have the same definition:
$ systemctl cat apt-news.service esm-cache.service
# /usr/lib/
# APT News is hosted at https:/
# timely information related to apt updates available to your system.
# This service runs in the background during an `apt update` to download the
# latest news and set it to appear in the output of the next `apt upgrade`.
# The script won't do anything if you've run: `pro config set apt_news=false`.
# The script will limit network requests to at most once per 24 hours.
# You can also host your own aptnews.json and configure your system to use it
# with the command:
# `pro config set apt_news_url=https:/
[Unit]
Description=Update APT News
[Service]
Type=oneshot
ExecStart=
AppArmorProfile
CapabilityBound
CapabilityBound
CapabilityBound
CapabilityBound
CapabilityBound
PrivateTmp=true
RestrictAddress
RestrictAddress
# These may break some tests, and should be enabled carefully
#NoNewPrivilege
#PrivateDevices
#ProtectControl
# ProtectHome=true seems to reliably break the GH integration test with a lunar lxd on jammy host
#ProtectHome=true
#ProtectKernelM
#ProtectKernelT
#ProtectSystem=full
#RestrictSUIDSG
# Unsupported in bionic
# Suggestion from systemd.exec(5) manpage on SystemCallFilter
#SystemCallFilt
#SystemCallFilt
#SystemCallErro
#ProtectClock=true
#ProtectKernelL
# /usr/lib/
# The ESM apt cache will maintain information about what ESM updates are
# available to a system. This information will be presented to users in the apt
# output, or when running pro security-status. These caches are maintained
# entirely outside the system apt configuration to avoid interference with user
# definitions. This service updates those caches. This will only have effect
# on releases where ESM is applicable, starting from Xenial: esm-apps for
# every LTS, and esm-infra for systems in expanded support period after the LTS
# expires.
[Unit]
Description=Update the local ESM caches
[Service]
Type=oneshot
ExecStart=
Grant Orndorff (orndorffgrant) wrote : | #24 |
Thanks for all the investigation and discussion!
Just to close out the ubuntu-pro-client related questions:
ubuntu-pro-client does run daemon-reload in postinst.
and here is a reproducer that doesn't involve ubuntu-pro-client services
```
lxc launch ubuntu-daily:noble test
lxc shell test
# now in the noble container
cat > /usr/lib/
[Unit]
Description=Hello
[Service]
Type=oneshot
ExecStart=echo hello
EOF
systemctl start hello
systemctl status hello
snap install snapd
systemctl start hello # this will show the warning
systemctl cat hello.service # no noticeable change
```
So I'll mark this invalid for u-a-t.
This also demonstrates that a totally new systemd service is affected. Does snapd iterate over all systemd units to check something? Then maybe it is accidentally updating mtime even though it doesn't change contents?
Changed in ubuntu-advantage-tools (Ubuntu): | |
status: | Incomplete → Invalid |
Zygmunt Krynicki (zyga) wrote : | #25 |
Yes, I think we may be enumerating a directory / statting files. I don't believe we open anything unless we want to have a look but I _could_ be wrong and I'm still investigating things (with interruptions to attend calls).
I don't believe it is related to ubuntu-pro-client, the only reason it is in the report is that "apt update" hook calls into systemctl so the warning is printed there.
Heinrich Schuchardt (xypron) wrote : | #26 |
Today I saw the warning on an riscv64 Ubuntu 24.04 system booted from https:/
Eccentric Orange (eccentricorange) wrote (last edit ): | #27 |
I am seeing this message on Ubuntu 24.04 Beta x64. I did an apt update and apt upgrade yesterday without any issues, and got this message out of the blue today.
Sorry, I might not have been able to follow this entire discussion, but if you need any logs/info from me and can guide me on providing them, I'll happily oblige.
**Edit:** Reboot fixed it
Islam (islam) wrote (last edit ): | #28 |
Same thing on 24.04 and rebooting doesn't fix it.
Seems those unit files belongs to: ubuntu-pro-client
Christian Ehrhardt (paelzer) wrote : | #29 |
TL;DR:
As many I've gone deeper, but none of the times in `stat` nor the
checksums of /usr/lib/
Turns out this wasn't even about their file states.
And additionally my understanding was wrong, and potentially yours as well.
The state if this is outdated is not only per service via `struct UnitStatusInfo`,
but also globally across all services via `struct Manager`.
Snapd's way to enable its mount unit sets that global state and
therefore either needs to change how it enables units or run
a daemon-reload afterwards just like most .deb package installs do.
Details:
First we need to be careful, there are two ambiguous paths here that
can trigger the same message:
a) on service start
start_unit_one
-> if (need_daemon_
-> warn_unit_
This is a function:
int need_daemon_
It will call out via dbus asking for the attribute NeedDaemonReload
b) on service status
print_status_info
-> if (i->need_
-> warn_unit_
Also for storage, there are two:
c) `struct Manager` containing `unit_file_
state for all units in that manager
d) Each `struct UnitStatusInfo` has a field `need_daemon_
named like the function above) that can flag this per unit.
And (a) isn't even per service.
The value of that can be fetched per service via dbus like:
$ dbus-send --system --print-reply --dest=
method return time=1713787033
variant boolean false
And the same can be fetched via `systemctl show` as well:
root@test:~# systemctl show hello | grep '^NeedDaemonReload'
NeedDaemonReloa
With the above in mind we can see that installing snapd renders ALL of them
as outdated. It was spotted with pro, reproduced with a simple example
and if you check the system it is all of them.
root@test:~# for u in $(systemctl list-units --output json | jq '.[].unit' | tr -d '"'); do systemctl show $u | grep '^NeedDaemonRel
143 NeedDaemonReload=no
root@test:~# snap install snapd
2024-04-
snapd 2.62 from Canonical✓ installed
root@test:~# for u in $(systemctl list-units --output json | jq '.[].unit' | tr -d '"'); do systemctl show $u | grep '^NeedDaemonRel
144 NeedDaemonReloa
Still the question is, which of the two data points is it switching?
It could be the global setting, but as well iterating and setting it per service.
I found that the global state could get changed in src/core/
in very similarly named methods:
- method_
- method_
- method_
- method_
- method_
- method_
All of them do eventually the same:
m->un...
J (picea-sitchensis) wrote : | #30 |
Hello. I'm also running into this problem:
sudo apt update && sudo apt upgrade
Warning: The unit file, source configuration file or drop-ins of apt-news.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Warning: The unit file, source configuration file or drop-ins of esm-cache.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Hit:1 http://
Hit:2 http://
Hit:3 http://
Hit:4 http://
Hit:5 https:/
Hit:6 https:/
Hit:7 https:/
Ign:8 https:/
Hit:9 https:/
Err:10 https:/
404 Not Found [IP: 45.149.104.1 443]
Reading package lists... Done
W: https:/
E: The repository 'https:/
N: Updating from such a repository can't be done securely, and is therefore disabled by default.
N: See apt-secure(8) manpage for repository creation and user configuration details.
I have no idea what it even means. Any suggestions? Should I even be concerned about this?
Bass Ackwards (bassackwards) wrote (last edit ): | #31 |
Fixed
Fixed
Fixed
Fixed after reboot.
Did reboot work for any others?
Happened to me after clearing out games,then apt purge hexchat.
Machine is all enterprise gear. Dell poweredge r730xd
my cli error is:
sudo apt update
[sudo] password for xxxxxx:
Sorry, try again.
[sudo] password for xxxxxx:
Warning: The unit file, source configuration file or drop-ins of apt-news.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Warning: The unit file, source configuration file or drop-ins of esm-cache.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Hit:1 http://
Hit:2 http://
Get:3 http://
Hit:4 http://
Fetched 89.7 kB in 1s (113 kB/s)
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
All packages are up to date.
Grant Orndorff (orndorffgrant) wrote : | #32 |
It looks like the global need-reload state that Christian investigated that is being set by a snapd operation was added recently in systemd.
https:/
That is likely why we're only seeing this issue in noble.
From reading the commit message there, it sounds like the right thing to do is for snapd to issue a daemon-reload after it sets up all its units.
Paul White (paulw2u) wrote (last edit ): | #33 |
I'm sorry if this comment isn't helpful but I'm only seeing this on a new noble installation but never on another installation which was upgraded from mantic some time ago but early on during the noble development period.
corrado venturini (corradoventu) wrote : | #34 |
Also in Ubuntu 24.10 Oracular installed from ISO, not upgraded from Noble:
corrado@
[sudo] password for corrado:
Warning: The unit file, source configuration file or drop-ins of apt-news.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Warning: The unit file, source configuration file or drop-ins of esm-cache.service changed on disk. Run 'systemctl daemon-reload' to reload units.
Hit:1 http://
Get:2 http://
.....
Thank you but I never reported this bug
On May 20, 2024 9:40:38 a.m. corrado venturini <email address hidden>
wrote:
> Also in Ubuntu 24.10 Oracular installed from ISO, not upgraded from Noble:
> corrado@
> [sudo] password for corrado:
> Warning: The unit file, source configuration file or drop-ins of
> apt-news.service changed on disk. Run 'systemctl daemon-reload' to reload
> units.
> Warning: The unit file, source configuration file or drop-ins of
> esm-cache.service changed on disk. Run 'systemctl daemon-reload' to reload
> units.
> Hit:1 http://
> Get:2 http://
> .....
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (2065717).
> https:/
>
> Title:
> Warning: The unit file, source configuration file or drop-ins of {apt-
> news,esm-
> to reload units.
>
> Status in snapd:
> New
> Status in ubuntu-
> Invalid
>
> Bug description:
> I recently started seeing the following warning messages when I run
> `apt update`.
>
> $ sudo apt update
> Warning: The unit file, source configuration file or drop-ins of
> apt-news.service changed on disk. Run 'systemctl daemon-reload' to reload
> units.
> Warning: The unit file, source configuration file or drop-ins of
> esm-cache.service changed on disk. Run 'systemctl daemon-reload' to reload
> units.
> ...
>
> apt-news.service for example is in /lib/systemd/
> news.service and it's a static file managed by the package. Does the
> package maintenance script call systemd related hooks to reload the
> config whenever the package gets updated?
>
> $ systemctl cat apt-news.service
> # /usr/lib/
> # APT News is hosted at https:/
> # timely information related to apt updates available to your system.
> ...
>
> $ dpkg -S /lib/systemd/
> ubuntu-pro-client: /lib/systemd/
>
> ProblemType: BugDistroRelease: Ubuntu 24.04
> Package: ubuntu-pro-client 31.1
> ProcVersionSign
> Uname: Linux 6.6.0-14-generic x86_64
> NonfreeKernelMo
> ApportVersion: 2.28.0-0ubuntu1
> Architecture: amd64
> CasperMD5CheckR
> CurrentDesktop: ubuntu:GNOME
> Date: Wed Feb 28 13:06:35 2024
> InstallationDate: Installed on 2024-01-08 (51 days ago)
> InstallationMedia: Ubuntu 24.04 LTS "Noble Numbat" - Daily amd64 (20240104)
> ProcEnviron:
> LANG=en_US.UTF-8
> PATH=(custom, no user)
> SHELL=/bin/bash
> TERM=xterm-256color
> XDG_RUNTIME_
> UpgradeStatus: No upgrade log present (probably fresh install)
> apparmor_logs.txt:
>
> cloud-id.txt-error:
> Failed running command 'cloud-id' [exit(2)]. Message: REDACTED config part
> /etc/cloud/
> REDACTED config...
Phil O (po5857) wrote : | #36 |
Possibly related to this:
Hello, Nobuto,
First of all, thanks for reporting this issue.
We did changes to the apt news service file - we added the apparmor profiles and systemd security config there - and no, we didn't reload it by default, which may be causing those warnings.
However, I could not reproduce this behavior. Do you have steps to reproduce it on a fresh system?
I will bring this to the team.