[pve-devel] [PATCH ifupdown2] add ifupdown2-pre.service service

Fabian Grünbichler f.gruenbichler at proxmox.com
Wed Mar 4 09:38:47 CET 2020


On March 4, 2020 9:10 am, Thomas Lamprecht wrote:
> On 3/3/20 11:08 PM, Alexandre DERUMIER wrote:
>>>> hmm, can we not just add a after dependency in the "networking.service" on the 
>>>> already existing "systemd-udev-settle.service" service? 
>> 
>> this was the first proposal in the discuss
>> 
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=920623
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?att=1;bug=920623;filename=0001-Depend-on-systemd-udev-settle.service-in-networking..patch;msg=27
>> 
>> I'm not sure why they have use another -pre.service for ifupdown1.
> 
> AFAICT, they wanted to avoid pulling a systemd specific service with something
> such core like the ifupdown as it would break init-freedom thus they opted to
> an extra service.

that, and they wanted to avoid pulling in udev-settle in case the system 
does not even use /etc/network/interfaces (the ExecStartPre had, and the 
split out service has, logic to check that and skip altogether)

both are not really relevant for our use cases

> 
>> 
>> I just have follow the same behaviour than ifupdown1 to be sure that is working the same for ifupdown2.
> 
> I mean, this makes somewhat sense to do, but in this case I'm not sure.
> We pull in the "systemd-udev-settle.service" through a require from
> "zfs-import-cache.service"  anyhow, plus we're systemd only anyway..
> 
> @Fabian, what do you think?

both extra service and directly pulling in seem fine to me. it would be 
good to push either to Debian's packaging as well (seems to be 
maintained by upstream/Cumulus), which probably gives a slight advantage 
to the extra service, for all the same reasons that the original bug had 
;)




More information about the pve-devel mailing list