Bug#967906: systemd 246 resolvconf path unit

Michael Biebl biebl at debian.org
Mon Aug 17 09:27:30 BST 2020


Am 07.08.20 um 13:10 schrieb Michael Biebl:
> Am 04.08.20 um 19:14 schrieb Kai L√ľke:
>> Hi,
>>
>> in my case this was caused by the resolvconf-pull-resolved.path unit
>> which continuously triggered the resolvconf-pull-resolved.service unit.
> 
> ...
> 
>> Would be good to see if the PathChanges is broken in general and then
>> report this upstream.
> 
> Fwiw, it is not PathChanged= which triggers this issue but PathExists=,
> which now behaves like originally documented.
> 
> To workaround the issue, you can comment out the line
> 
> PathExists=/run/systemd/resolve/stub-resolv.conf
> in resolvconf-pull-resolved.path
> 

Checking the archive, potentially affected packages are:

- cups-daemon_2.3.3-2
cups.path:PathExists=/var/cache/cups/org.cups.cupsd

-> triggers the start of cups.service, a potentially long running
service, so most likely not affected



- ostree-boot_2020.4-2
ostree-finalize-staged.path:PathExists=/run/ostree/staged-deployment

-> Type=oneshot service using RemainAfterExit=yes, so seemingly not affected



- plymouth_0.9.4-3
systemd-ask-password-plymouth.path:ConditionPathExists=/run/plymouth/pid

-> starts systemd-ask-password-plymouth.service, Type=simple with
ExecStart=/usr/bin/systemd-tty-ask-password-agent --watch --plymouth

The "--watch" argument means, it's continuously running and processing
password requests, so should be safe



- resolvconf_1.82
resolvconf-pull-resolved.path:PathExists=/run/systemd/resolve/stub-resolv.conf


-> starts resolvconf-pull-resolved.service, Type=oneshot without
RemainAfterExit=yes.
So in this list the only affected service that seems to be affected.

I was considering cloning/reassigning this bug report to resolvconf, but
there is already https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=968015
I think it makes sense to bump the severity of #968015 to at least
important or even RC, as it is hitting its users hard.

Given that only resolvconf is affected, I don't think it is necessary to
back out this changed behaviour of PathExits= (which now behaves as
documented) in systemd.
I do think though, that rate limiting should be applied and I'll keep
this systemd bug report to track this progress.

Regards,
Michael


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20200817/918ae6a4/attachment-0001.sig>


More information about the Pkg-systemd-maintainers mailing list