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