On 25-11-2020 02:11, Michael Biebl wrote:
Can you break this down to a more minimal test case which would make
this easily reproducible with systemd from unstable?
This reproduces the issue with 246.6-2~bpo10+1:
1) Create a normal unit file /etc/systemd/system/test-start.service with
contents
[Unit]
Description=Test start
[Service]
Type=oneshot
ExecStart=/usr/bin/mailx -s "message from test-start.service" root <
/dev/null
2) Create an instantiated unit file
/etc/systemd/system/test-warning@.service with contents
[Unit]
Description=test warning
[Service]
Type=oneshot
ExecStart=/usr/bin/mailx -s "service %i at %H has failed" root < /dev/null
3) Create a system wide drop-in
/etc/systemd/system/service.d/test-warning.conf with contents
[Unit]
OnFailure=test-warning@%p.service
4) Create drop-in /etc/systemd/system/test-start.service.d/override.conf
(by executing "systemctl edit test-start") with contents
[Service]
ExecStartPost=/usr/bin/mailx -s "message from override.conf" root <
/dev/null
5) systemctl daemon-reload
6) systemctl status test-start
7) goto 5
The "Run 'systemctl daemon-reload' to reload units." warning persists as
long as /etc/systemd/system/test-start.service.d/override.conf is newer
than /etc/systemd/system/service.d/test-warning.conf and can be cleared by:
touch /etc/systemd/system/service.d/test-warning.conf
systemctl daemon-reload
