On 14/04/2019 21:22, Adam Borowski wrote:
> On Sun, Apr 14, 2019 at 08:02:45PM +0200, Alec Leamas wrote:
>> No. ddupdate uses systemd --user to setup and run  the service without
>> root permissions. So it's not comparable in this respect.
> 
> It is called by the main blob itself, which runs as root, and sheds
> permissions only to execute user services.

Indeed. Stili, ddupfdate users can setuo and run their service without
root permissions; IIRC cron et. el. does not offer this option.


>>> You have two timers: one every 1h (the usual cron way), and another 2min
>>> after boot.  What's the point of the second if you already have an oneshot
>>> service?

Because it's very likely you have a new address after boot which need to
be registered


> But today, any consumer ISP at any of three places I have non-hosted
> machines at doesn't even support inbound IPv4 anymore, making tunnels
> the way to go for me.

Well, that's you. Other users have inbound connections for various reasons.

> A "must" requirement of the policy:

> ยง9.11:
> # [...] any package integrating with other init systems
> # must also be backwards-compatible with sysvinit by providing a SysV-
> # style init script with the same name as and equivalent functionality
> # to any init-specific job, as this is the only start-up configuration
> # method guaranteed to be supported by all init implementations.

It's interesting -- but it does not take the fact that systemd is the
default init system into account (per TC decision etc, you know this
better than me I guess). The Debian wiki [1] tells us:

# Since jessie, only systemd is fully supported; sysvinit is mostly
# supported, but Debian packages are not required to provide sysvinit
# start scripts.

I will not take part in any systemd  war here. Given the complete
context,  I think this is an RFE.


--alec

[1] https://wiki.debian.org/Init

Reply via email to