run: rearrange error handling when adding unit properties
Let's always leave logging to the call that actually added the fields to
the bus message. This way we don't get duplicate logging whenver
bus_append_unit_property_assignment() ends up being called, which does
all its logging on its own (and probably should do, as it can output
much more precise errors).
documentation: add document listing all unit file settings also supported for transient units
Unfortunately, there are far too many properties currently not
accessible to transient units. The first step to opening them all up is
to figure out which ones they are.
core: never remove "transient" and "control" directories from unit search path
This changes the unit search path logic to never drop the transient and
control directories from the unit search path. This is necessary as we
add new entries to both during runtime, due to the "systemctl
set-property" and transient unit logic.
Previously, the "transient" directory was created during early boot to
deal with this, but the "control" directories were not covered like
that. Creating the control directories early at boot is not possible
however, as /etc might be read-only then, and we do define a persistent
control directory. Hence, let's create these dirs on-demand when we need
them, and make sure the search path clean-up logic never drops them from
the search path even if they are initially missing.
(Also, always create these paths properly labelled)
path-lookup: LookupPathsFlags are a flags type, hence define it like one
We shouldn't rely on C's incremental assignment of values of enums for
bit fields. That'll work only between the first two flags, but for
everything following will break horrible. Hence, let's avoid any
ambiguity here, and let's clearly define the flags as shifts of 1.
This message is displayed either when the unit file itself is newer than
what is loaded, but also when any of the drop-ins is newer. Say so in
the message, in order not to confuse the user unnecessarily.
tree-wide: generate SD_BUS_ERROR_INVALID_ARGS when we get invalid arguments on bus calls
Let's make sure that when we return a D-Bus error, we return a native
one, if we generate it ourselves, and use errno-based error
synthetization only if we received an errno ourselves. Yes, this makes
things slightly longer, but is highly misleading as we propagate D-Bus
errors, and not errnos to the client.
core: add proper escaping to writing of drop-ins/transient unit files
This majorly refactors the transient unit file and drop-in writing
logic, so that we properly C-escape and specifier-escape (% → %%)
everything we write out, so that when we read it back again, specifiers
are parsed that aren't supposed to be parsed.
This renames unit_write_drop_in() and friends by unit_write_setting().
The name change is supposed to clarify that the functions are not only
used to write drop-in files, but also transient unit files.
The previous "mode" parameter to this function is replaced by a more
generic "flags", which knows additional flags for implicit C-style and
specifier escaping before writing things out. This can cover most
properties where either form of escaping is defined. For the cases where
this isn't sufficient, we add helpers unit_escape_setting() and
unit_concat_strv() for escaping individual strings or strvs properly.
While we are at it, we also prettify generation of transient unit files:
we try to reduce the number of section headers written out: previously
we'd write the right section header our for each setting. With this
change we do so only if the setting lives in a different section than
the one before.
(This should also be considered preparation for when we add proper APIs
to systemd to write normal, persistant unit files through the bus API)
generators: be more careful when writing unit settings that support specifier expansion
Let's always escape strings we receive from the user before writing them
out to unit file settings that suppor specifier expansion, so that user
strings are transported as-is.
core: enable specifier expansion for What=/Where=/Type=/SourcePath= too
Using specifiers in these settings isn't particularly useful by itself,
but it unifies behaviour a bit. It's kinda surprising that What= in
mount units resolves specifies, but Where= does not. Hence let's add
that too. Also, it's surprising Where=/What= in mount units behaves
differently than in automount and swap units, hence resolve specifiers
there too. Then, Type= in mount units is nowadays an arbitrary,
sometimes non-trivial string (think fuse!), hence let's also expand
specifiers there, to match the rest of the mount settings.
This has the benefit that when writing code that generates unit files,
less care has to be taken to check whether escaping of specifiers is
necessary or not: broadly everything that takes arbitrary user strings
now does specifier expansion, while enums/numerics/booleans do not.
core: process C-style escapes in UnsetEnvironment=
We process C-style escapes in Environment=, hence we should process it
in UnsetEnvironment= too, as the latter accepts assignments much like
the former, including arbitrary values specified by the user.
core: use config_parse_unit_string_printf() for decoding RebootArgument=
All other cases where we accept a reboot argument are decoded with
config_parse_unit_string_printf() rather than
config_parse_unit_path_printf(), and that's really the only thing what
makes sense here, hence adjust this here, too.
specifier: unify specifier implementations for user-related specifiers
The code in install-printf.c and unit-printf.c for these is pretty much
the same and very generic. Let's move this all over to the generic
specifier.c, and share the implementations.
core: drop specifier expansion when parsing transient dbus properties
Specifier expansion (much like C escape handling) should be a helper for
writing unit files, but should be nothing we do on programatic APIs. For
those, the client can do the necessary replacements anyway, and we
really should be careful with doing such string processing of data we
get via lower level programmatic APIs.
We currently do specifier expansion only for the env var transient unit
APIs, no other properties do this. Let's remove it here too, to be fully
systematic.
Yes, in a way this is API breakage, but then again this API isn't
documented yet, and an outlier, hence let's clear this up now, before it
is too late.
journal: avoid undefined behaviour in float division by 0.0
Coverity says that's undefined. I'm pretty sure we always would get a nan, but
let's avoid (formally) undefined behaviour since that can cause compilers to do
strange things.
read_one_line_file() always returns <= 0, so the code was OK, but let's write
the check a bit differently to make it obvious that min_max is always set.
The comment above makes the intent of the code pretty clear:
"use security2_protocol == NULL as indicator".
So revert the condition in the check and fix the logic in the comment while
at it.
The question is how this could have ever worked: if BS->LocateProtocol
(which is supposedly optional) ever failed, we'd crash here. Strange.
dissect-image: simplify check for passphrase presence
m->encrypted is set when fstype=="crypto_LUKS", but this is not obvious when
reading decrypt_partition(). Just check if passphrase is set before using
it.
networkd: plug some memleaks in rule serialization/deserialization
This fixes the (mostly theoretical, since we're only parsing data that we write
ourselves) memleak when iif or oif is deserialized multiple times. Unfortunately
it does not fix the memleak when rule is freed, but that'll require a bigger
effort.
networkd: fix serialization of {Incoming,Outgoing}Interface
Let's just say that the code wasn't fully functional ;(
Since we only had the parser for serialization, and not the writer, we are
free to change the format. So while at it, let's use shorter names in the
serialization format that match the surrounding style.
If test-resolve is running in some CI environment that doesn't have
reliably working DNS, it's a good idea not to hang forever, let's
time-out after 20s
service: use parse_errno() for parsing error numbers
Let's always use the same logic when parsing error numbers, i.e. use
parse_errno() here too, to unify some code, and tighten the checks a
bit.
This also allows clients to pass errors as symbolic names. Probably
nothing we want to advertise too eagerly (since new daemons generating
this on old service managers won't understand), but still pretty
useful I think, in particular in scripting languages and such, where the
numeric error numbers might not be readily available.
core: add a new sd_notify() message for removing fds from the FD store again
Currenly the only way to remove fds from the fdstore is to fully
stop the service, or to somehow trigger POLLERR/POLLHUP on the fd, in
which case systemd will remove the fd automatically.
Let's add another way: a new message that can be sent to remove fds
explicitly, given their name.
core: only process one of READY=1, STOPPING=1 or RELOADING=1 in sd_notify() handling
Of course, it's not really a valid sd_notify() message if multiple of
these fields are used in one, but let's handle this somewhat gracefully,
by only processing one of them, and ignoring the rest.
Susant Sahani [Sun, 26 Nov 2017 14:21:45 +0000 (19:51 +0530)]
networkd: DHCP client do not get into a loop while setting MTU (#7460)
Some devices get reset itself while setting the MTU. we get in to a LOOP .
Once the MTU changed then the DHCP client talking with DHCP server never stops.
networkd gets into a loop and generates endless DHCP requests.
projects / thirdparty / systemd.git / log
