Process 1 (aka init) needs to be started with an empty signal mask.
That includes the process 1 that's started after the initrd is finished.
When the initrd is using systemd (as it does with dracut based initrds)
then it is systemd that calls the real init. Normally this is systemd
again, except when the user uses for instance "init=/bin/bash" on the
kernel command line.
Passing 0 to malloc() is not required to return NULL. Therefore, don't
bail out if "b" is 0. This is not of importance to the existing helpers,
but the upcoming realloc_multiply() requires this. To keep consistence, we
keep the same behavior for the other helpers.
As it turns out, we cannot use _Pragma in compound-statements. Therefore,
constructs like MIN(MAX(a, b), x) will warn due to shadowed variable
declarations. The DISABLE_WARNING_SHADOW macro can be used to suppress
these.
Note that using UNIQUE(_var) does not work either as GCC uses the last
line of a macro-expansion for __LINE__, therefore, still causing both
macros to have the same variables. We could use different variable-names
for MIN and MAX, but that just hides the problem and still fails for
MIN(something(MIN(a, b)), c).
The only working solution is to use __COUNTER__ and pass it pre-evaluated
as extra argument to a macro to use as name-prefix. This, however, makes
all these macros much more complicated so I'll go with manual
DISABLE_WARNING_SHADOW so far.
The only update service we really need to guard like this is
systemd-tmpfiles-setup.service since if invoked manually might create
/var/run/nologin and thus blocking the user from login. The other
services are pretty much idempotent and don't suffer by this problem,
hence let's simplify them.
/etc/mtab should die die die. It's sad enough util-linux still contains
support for it, but we don't have to partake in that charade, so let's
turn this off.
This is in-line with the fact that since years we already have been
"tainting" systemd if we detect /etc/mtab not being a symlink...
Of course, util-linux is currently broken, and still touches /etc/mtab,
weven if we pass "--no-mtab" to it:
https://bugzilla.redhat.com/show_bug.cgi?id=1109367
But hey, let's hope that gets fixed quickly, even if total removal of
/etc/mtab support from util-linux might not happen so quickly...
We could still have an old interface name and/or mac address when libudev
tells us that the device is initialized, as the up-to-date info could still
be on its way from the kernel.
This reverts (and rewrites) commit 7d95c772cb.
The issue blocking this feature has now been fixed in the kernel, and backported
to the various stable kernels.
Our netdevs will now have stable MAC addresses, even if one is not specified.
It may sometimes be necessary to specify the MAC address of a netdev.
Let us set the correct one from the get-go, rather than having the
kernel generate a random one, and then change it after.
It should not be possible to have a DHCP lease on a link without also having
an associated network. Add assert() to avoid compiler warnings.
Reported by Thomas H. P. Andersen
The file should have been in /usr/lib/ in the first place, since it
describes the OS container in /usr (and not the configuration in /etc),
hence, let's support os-release files in /usr/lib as fallback if no
version in /etc exists, following the usual override logic.
A prior commit already enabled tmpfiles to create /etc/os-release as a
symlink to /usr/lib/os-release should it be missing, thus providing nice
compatibility with applications only checking in /etc.
While it's probably a good idea if all apps check both locations via a
fallback logic, it is only necessary in the early boot process, as long
as the /etc/os-release symlink has not been restored, in case we boot
with an empty /etc.
For most NSS calls it is documented that they return NULL + errno=0 when
an entry is not found. However, in reality it appears to be common to
return NULL + errno=ENOENT, instead. Handle that correctly, and don't
consider ENOENT a systematic error.
With this in place RPMs can make sure that whatever they drop in is
immeidately applied, and not delayed until next reboot.
This also moves systemd-sysusers back to /usr/bin, since hardcoding the
path to /usr/lib in the macros would mean compatibility breaks in
future, should we turn sysusers into a command that is actually OK for
people to call directly. And given that that is quite likely to happen
(since it is useful to prepare images with its --root= switch), let's
just prepare for it.
this gives us a little bit more freedom to move things around later on,
as we don't hardcode the systemd paths in old RPMs that shall work with
new systemds.
int unit_file_mask(...) in ./src/shared/install.c calls
get_config_path(...) which can in 4 error cases return without setting
"ret", and thus "prefix" can be uninitialized when unit_file_mask(...)
finishes (which it does directly after the error is returned from
get_config_path(...)).
static bool enable_name_policy(...) in ./src/udev/net/link-config.c
calls proc_cmdline(...) to get "line" initialized, but
proc_cmdline(...) does not guarantee that atleast when both
conditions (detect_container(NULL) > 0) and
read_full_file(...) returned < 0.
static int killall(....) in ./src/core/killall.c tries to get "s"
initialized by calling get_process_comm(...) which calls
read_one_line_file(...) which if it fails will mean it is left
uninitialized.
It is then used in argument to strna(s) call where it is
dereferenced(!), in addition to nothing else initializing it before
the scope it is in finishes.
static int client_send_request(...) in
./src/libsystemd-network/sd-dhcp-client.c tries to initialize
"request" by calling client_message_init(...), which has atleast
5 error cases where it can return without that happening.
This leads to the function finishing without "request" being initialized.
When enabled in [Network] it will set up a dhcp server on the interface, listening
on one of its statically configured IPv4 addresses and with a fixed size pool of
leases determined from it.
Example:
[Match]
Name=ve-arch-tree
[Network]
Address=192.168.12.5/24
DHCPServer=yes
[Route]
Gateway=192.168.12.5
Destination=192.168.12.0/24
In this case we will configure ve-arch-tree with the address 192.168.12.5 and
hand out addresses in the range 192.168.12.6 - 192.168.12.38.
In the future, we should (as suggested by Lennart) introduce a syntax to pick the
server address automatically.
Lennart Poettering