| Age | Commit message (Collapse) | Author |
|---|
|
Environment generators
|
|
Fixes #4685.
|
|
Clarifications to make coverity happy
|
|
This is only the tip of the iceberg. It would be great to test all kinds of nesting, handling
of invalid syntax, etc., but I'm leaving that for later.
|
|
Sometimes it's useful to provide a default value during an environment
expansion, if the environment variable isn't already set.
For instance $XDG_DATA_DIRS is suppose to default to:
/usr/local/share/:/usr/share/
if it's not yet set. That means callers wishing to augment
XDG_DATA_DIRS need to manually add those two values.
This commit changes replace_env to support the following shell
compatible default value syntax:
XDG_DATA_DIRS=/foo:${XDG_DATA_DIRS:-/usr/local/share/:/usr/share}
Likewise, it's useful to provide an alternate value during an
environment expansion, if the environment variable isn't already set.
For instance, $LD_LIBRARY_PATH will inadvertently search the current
working directory if it starts or ends with a colon, so the following
is usually wrong:
LD_LIBRARY_PATH=/foo/lib:${LD_LIBRARY_PATH}
To address that, this changes replace_env to support the following
shell compatible alternate value syntax:
LD_LIBRARY_PATH=/foo/lib${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
[zj: gate the new syntax under REPLACE_ENV_ALLOW_EXTENDED switch, so
existing callers are not modified.]
|
|
It's like replace_env, but lets you pass in a substring.
|
|
In the future we might want to allow additional syntax (for example
"unset VAR". But let's check that the data we're getting does not contain
anything unexpected.
|
|
(Only in environment.d files.)
We have only basic compatibility with shell syntax, but specifying variables
without using braces is probably more common, and I think a lot of people would
be surprised if this didn't work.
|
|
|
|
Why the strange name: the prefix is necessary to follow our own advice that
environment generators should have numerical prefixes. I also put -d- in the
name because otherwise the name was very easy to mistake with
systemd.environment-generator. This additional letter clarifies that this
on special generator that supports environment.d files.
|
|
merge_env_file is a new function, that's like load_env_file, but takes a
pre-existing environment as an input argument. New environment entries are
merged. Variable expansion is performed.
Falling back to the process environment is supported (when a flag is set).
Alternatively this could be implemented as passing an additional fallback
environment array, but later on we're adding another flag to allow braceless
expansion, and the two flags can be combined in one arg, so there's less
stuff to pass around.
|
|
strempty() converts a NULL value to empty string, so
that it can be passed on to functions that don't support NULL.
replace_env calls strempty before passing its value on to strappend.
strappend supports NULL just fine, though, so this commit drops the
strempty call.
|
|
If an environment array has duplicates, strv_env_get_n returns
the results for the first match. This is wrong, because later
entries in the environment are supposed to replace earlier
entries.
|
|
Environment file generators are a lot like unit file generators, but not
exactly:
1. environment file generators are run for each manager instance, and their
output is (or at least can be) individualized.
The generators themselves are system-wide, the same for all users.
2. environment file generators are run sequentially, in priority order.
Thus, the lifetime of those files is tied to lifecycle of the manager
instance. Because generators are run sequentially, later generators can use or
modify the output of earlier generators.
Each generator is run with no arguments, and the whole state is stored in the
environment variables. The generator can echo a set of variable assignments to
standard output:
VAR_A=something
VAR_B=something else
This output is parsed, and the next and subsequent generators run with those
updated variables in the environment. After the last generator is done, the
environment that the manager itself exports is updated.
Each generator must return 0, otherwise the output is ignored.
The generators in */user-env-generator are for the user session managers,
including root, and the ones in */system-env-generator are for pid1.
|
|
Only tests are added, otherwise the new code is unused.
|
|
|
|
strv_env_replace was calling env_match(), which in effect allowed multiple
values for the same key to be inserted into the environment block. That's
pointless, because APIs to access variables only return a single value (the
latest entry), so it's better to keep the block clean, i.e. with just a single
entry for each key.
Add a new helper function that simply tests if the part before '=' is equal in
two strings and use that in strv_env_replace.
In load_env_file_push, use strv_env_replace to immediately replace the previous
assignment with a matching name.
Afaict, none of the callers are materially affected by this change, but it
seems like some pointless work was being done, if the same value was set
multiple times. We'd go through parsing and assigning the value for each
entry. With this change, we handle just the last one.
|
|
|
|
This protocol is generally useful, we might just as well reuse it for the
env. generators.
The implementation is changed a bit: instead of making a new strv and freeing
the old one, just mutate the original. This is much faster with larger arrays,
while in fact atomicity is preserved, since we only either insert the new
entry or not, without being in inconsistent state.
v2:
- fix confusion with return value
|
|
|
|
The output of processes can be gathered, and passed back to the callee.
(This commit just implements the basic functionality and tests.)
After the preparation in previous commits, the change in functionality is
relatively simple. For coding convenience, alarm is prepared *before* any
children are executed, and not before. This shouldn't matter usually, since
just forking of the children should be pretty quick. One could also argue that
this is more correct, because we will also catch the case when (for whatever
reason), forking itself is slow.
Three callback functions and three levels of serialization are used:
- from individual generator processes to the generator forker
- from the forker back to the main process
- deserialization in the main process
v2:
- replace an structure with an indexed array of callbacks
|
|
There is a slight change in behaviour: the user manager for root will create a
temporary file in /run/systemd, not /tmp. I don't think this matters, but
simplifies implementation.
|
|
Found with:
git grep '"[^"]*[a-z0-9]([0-9]\+p\?)' src/ | grep -vF man:
|
|
|
|
|
|
Coverity was complaining about TOCTOU (CID #745806). Indeed, it seems better
to open the file and avoid the stat altogether:
- O_NOFOLLOW means we'll get ELOOP, which we can translate to EINVAL as before,
- similarly, open(O_WRONLY) on a directory will fail with EISDIR,
- and finally, it makes no sense to check access mode ourselves: just let
the kernel do it and propagate the error.
v2:
- fix memleak, don't clober input arg
|
|
This most likely means oom, it's better to exit than to run less with
incomplete settings.
CID #714383.
|
|
CID #778045.
|
|
In practice this doesn't matter much because the read that follows will
likely fail, but we'll get a better error message.
CID #1368233.
|
|
CID #1368235.
|
|
CID #1368238.
|
|
Check for CID #1368267.
|
|
systemctl edit & reboot fixlets
|
|
|
|
fails
The hint is not too explicit, and just refers to the man page, because this
option is slightly dangereous. This was we don't have to discuss the limitation
in the hint itself.
Fixes #4002.
|
|
|
|
"systemctl --user edit --force --full tmp.mount" would crash, when we'd do
basename(NULL). Fix this by creating a new unit or a new override even if
not path is found.
Tested with:
systemctl --user edit --force --full tmp.mount
systemctl --user edit --force tmp.mount
systemctl --user edit foo@.service
systemctl --user edit foo@bar.service
systemctl --user edit --full foo@.service
systemctl --user edit --full foo@bar.service
|
|
Fixes #5383.
|
|
|
|
Commit cc3901613 only fixed one place, fix the other one too.
|
|
|
|
SD_ID128_MAKE is clearly not a standard C macro, so let’s point the user
to its documentation to let them know which header they need and what
they can then do with MESSAGE_XYZ.
|
|
fixes for running nspawn+resolved in combination
|
|
Let's check D-Bus instead of files in /run to see if resolved is
running. This is a bit nicer as bus names are automatically cleaned up
when resolved dies, which is not the case for files in /run.
See: #4649
|
|
Commit 436e916ea introduced the assumption into test-stat-util that /run
is a tmpfs mount point. This is not the case in build chroots such as
Fedora's mock or Debian's sbuild. So only assert that /run is a tmpfs
and not a btrfs if /run is actually a mount point. This will then still
be asserted with installed tests.
|
|
|
|
various coredump fixes
|
|
more resolved fixes
|
|
Following a similar commit in casync:
https://github.com/systemd/casync/pull/10
|
|
networkd: fix drop-in conf directory configs overwriting each other
|
