This applies an (upstreamed) patch to permit systemd-localed to run
locale-gen to generate missing locale when requested to switch the
system locale.
This makes localectl usable on Debian for changing locale without
breaking system localization or even prevent certain applications from
running at all after switching to a non-generated locale.
The new systemd-timesyncd package conflicting with other NTP-related
packages resolves the problems arising when installing systemd-timesyncd
and other NTP servers on the same system.
Co-authored-by: Michael Biebl <biebl@debian.org>
LP: #1849156Closes: #805927, #947936
Apparently Conflicts= are not a reliable mechanism to ensure alternative
NTP implementations take precedence over systemd-timesyncd.
This reverts commit b2ced99893.
Closes: #902026
All major NTP implementations ship a native service file nowadays with a
Conflicts=systemd-timesyncd.service so this drop-in is no longer
necessary.
Closes: #873185
ReadWritePaths= fails by default if the referenced directory does not
exist. This happens if resolvconf is not installed, so use '-' to ignore
the absence.
Closes: #854814
https://github.com/systemd/systemd/pull/5283 will introduce permission
restrictions for systemd-resolved.service, including the lockdown to
writing /run/systemd/. This will then cause the resolvconf call in our
drop-in to fail as that needs to write to /run/resolvconf/. Add this to
ReadWritePaths=. (This is a no-op with the current unrestricted unit).
This leads to timeouts on shutdown via the resolvconf hooks and does not
actually help much -- /etc/resolv.conf would then just be empty instead of
having a nonexisting 127.0.0.53 nameserver, so manually stopping resolved in a
running system is broken either way.
LP: #1648068
On some architectures (at least ppc64el), running resolvconf does not work with
MemoryDenyWriteExecute=yes:
Process: 4728 ExecStartPost=/bin/sh -c [ ! -e /run/resolvconf/enable-updates ] || echo "nameserver 127.0.0.53" | /sbin/resolvconf -a systemd-resolved (code=exited, status=127)
Aug 15 07:16:39 autopkgtest sh[4659]: sed: error while loading shared libraries: cannot restore segment prot after reloc: Operation not permitted
LP: #1609740
Use ConditionPathExists=/dev/tty0, the same check as in getty@.service,
to determine whether we have a functional VC subsystem and we should
start any gettys.
Closes: #824779
Add debian/extra/units/systemd-resolved.service.d/resolvconf.conf to tell
resolvconf about resolved's builtin DNS server on 127.0.0.53. With that, DNS
servers picked up via networkd are respected when using resolvconf, and
software like Chrome that does not do NSS (libnss-resolve) still gets proper
DNS resolution.
Drop the brittle and ugly systemd-networkd-resolvconf-update.{path,service}
hack instead.
DNS servers which only apply to particular domains should/must not appear in
/etc/resolv.conf as globl name servers.
Thanks Andy Whitcroft for the initial fix!
Add corresponding test case to debian/tests/networkd.
LP: #1587762
This was a race condition which sometimes led to resolvconf not knowing about
the received name server. This now also ensures to update resolvconf if the
name server goes away.
This might be legitimately called several times in quick succession.
If that part of the "networkd" autopkgtest fails, show the journal log for that
service for easier debugging.
We don't want to stop these units during shutdown. Stopping networking.service
already shuts down the interfaces, but contains the safeguard for NFS or other
network file systems. Isolating emergency.target still keeps working as before
as well, as this also stops networking.service.
Closes: #761909
LP: #1492546
These send DNS server updates from networkd to resolvconf, if installed and
enabled. As we removed if-up.d/ integration, resolvconf is not otherwise being
updated.
Adjust the test suite as the previous commit stopped waiting for if-up.d/ to
have run, so now we need to wait for resolvconf to finish.
Drop networkd-if-up.d@.service and its invocation from net.agent again. It does
not work when restarting networkd and requires too much overhead.
Instead, add a suid root helper systemd-networkd-dispatcher which calls
run-parts, and patch networkd to run the wrapper at the appropriate time.
Add reference to LP: #1492129.
debian-fixup.service just has one purpose now (make /etc/mtab a symlink), so
drop the debian/extra/debian-fixup shell script and put the ln command directly
into debian-fixup.service. Update the description.
With this, networkd becomes compatible with ifupdown and NetworkManager for
packages shipping hooks.
- Add debian/extra/units/networkd-if-up.d@.service: Wait for a particular
interface to be up, and call if-up.d/ for it if it is managed by
networkd. Correspondingly, call if-post-down.d/ scripts when stopping.
- debian/extra/udev-helpers/net.agent: Start/stop
networkd-if-up.d@.service when interfaces appear/go away.
- debian/tests/networkd: Verify that if-up.d/ and if-post-down.d/ scripts
get run for a networkd managed interface.
Note that if-pre-up.d/ and if-down.d/ scripts are *not* being called + (like
NetworkManager), as they are unnecessary (if-pre-up.d) and unreliable
(if-down.d).
See Ubuntu blueprint for details:
https://blueprints.launchpad.net/ubuntu/+spec/foundations-w-networkd-vs-ifupdown
Follow-up fix for commit 7f563b59e: With Type=simple, ExecStartPost runs
immediately after ifup got started, not after it finished. So we can't use
ExecStartPost here, but instead run both "ifup" and "ifquery" in the same
ExecStart command.
This avoids blocking network.target on boot with unavailable hotplug interfaces
in /etc/network/interfaces. The main purpose of the Before=network.target is to
ensure a robust shutdown order, not to block the boot on ifup'ing every
interface; services which want that need to depend on network-online.target.
Closes: #790669
LP: #1425376
/etc/rc.local often contains status messages which users expect to see during boot.
Rename debian/extra/units/rc-local.service.d/wait-online.conf to debian.conf
and add the Standard{Output,Error} settings there.
LP: #1468102
Add debian/extra/units/rc-local.service.d/wait-online.conf.
This not specified by LSB, but has been behaving that way in Debian under SysV
init and upstart.
LP: #1451797
To ensure that profiles apply to e. g. dhclient:
- Rename networking.service.d/network-pre.conf to systemd.conf, and add
After=apparmor.service.
- ifup@.service: Add After=apparmor.service.
- Add Breaks: on apparmor << 2.9.2-1, which dropped its dependency to
$remote_fs.
LP: #1438249
Revert the PartOf= setting from commit 1afebb7d7e. It's not necessary to fix
this bug, and other network related parts like NetworkManager don't go down
together with network.target either.
With that, "systemctl default" does not shut down network interfaces. Also add
PartOf=network.target, so that stopping network.target also stops network
interfaces.
LP: #1449380
This reverts commit dd2f43c5bc.
The apparmor SysV init script uses
Required-Start: $remote_fs
which leads to a dependency cycle.
That aside, a better fix would be if apparmor shipped a native service
file and hooked that up in network-pre.target.
To ensure that profiles apply to e. g. dhclient:
- Rename networking.service.d/network-pre.conf to systemd.conf, and add
After=apparmor.service.
- ifup@.service: Add After=apparmor.service.
LP: #1438249
