Previous implementation is simplified by using the new helper. The new code
does more looping, but considering that it's unlikely that people set more
than a handful of variables through commandline options, this should be OK.
If a variable is specified on the command line, it overrides any automatically
set variable. Effective behaviour was already were like this, because we would
specify two variables, both would be set, and since glibc will return
the first matching entry.
('systemd-socket-activate -E TERM=FOO -l 2000 --inetd -a env' would give
'TERM=FOO TERM=xterm-256color PATH=...', and getenv("TERM") returns "FOO".)
But it's nicer to filter out any duplicate entries and only pass the intended
variable to the child process.
The effect should be the same, but the code is less verbose.
In particular, the variable was called envp in parts of the code,
but in other parts, we had a local envp variable, and envp was called
env.
systemd-socket-activate has supported such a mode since
5e65c93a43. '--setenv=FOO=$FOO' is a fairly
common use in scripts, and it's nicer to do this automatically without worrying
about quoting and whatnot.
https://github.com/systemd/mkosi/pull/765 added the same to 'mkosi --environment='.
We would update 'found' using bit operations, but studiously ignore the actual
value and treat it as boolean. So just use a boolean variable instead. Because
there is a double loop, we would break the inner loop, but repeat the outer
loop, even though the boolean was already set. Add '&& !found' in the loop
conditions to break iteration immediately.
We had 'msghdr' and 'mh' in various places. Now 'const struct msghdr msghdr' is
used consistently. With structured init the variable is only used in the call
to sendmsg(), so let's make it a bit more descriptive.
The current pattern '#' triggers on the openSUSE kernel version that is
printed early during boot when no actual prompt is ready
> [ 0.000000] Linux version 5.12.10-1-default (geeko@buildhost) (gcc (SUSE Linux) 11.1.1 20210510 [revision 23855a176609fe8dda6abaf2b21846b4517966eb], GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.36.1.20210326-4) #1 SMP Fri Jun 11 05:05:06 UTC 2021 (b92eaf7)
Instead wait for pattern that: a) should have fewer false positives, b)
still be with working on distro shells:
openSUSE (red color)
^[[1m^[[31mimage:~ #^[[m^O
arch
[root@image ~]#
debian
root@image:~#
ubuntu
root@image:~#
fedora
[root@image ~]#
The current boot test relies on terminal login, therefore network setup
inside image is unnecessary. This opens up possibility to test images
that don't support the network setup via veth devices.
These have ignored the return value forever. Two are public APIs so
we can't really change what they return anyway, and the other one is
a cleanup path and the existing error code is more important.
CID#1461274
CID#1461275
CID#1461276
In general we almost never hit those asserts in production code, so users see
them very rarely, if ever. But either way, we just need something that users
can pass to the developers.
We have quite a few of those asserts, and some have fairly nice messages, but
many are like "WTF?" or "???" or "unexpected something". The error that is
printed includes the file location, and function name. In almost all functions
there's at most one assert, so the function name alone is enough to identify
the failure for a developer. So we don't get much extra from the message, and
we might just as well drop them.
Dropping them makes our code a tiny bit smaller, and most importantly, improves
development experience by making it easy to insert such an assert in the code
without thinking how to phrase the argument.
Zbigniew Jędrzejewski-Szmek
Luca Boccassi
Yu Watanabe
Michal Koutný
Egor Ignatov