I don't think it is useful to warn about about environemnt variables where the user
explicitly configured some value. If they went through the effort of escaping the cc
to include it in the setting (e.g. Environment="VAR=\efoo"), and we pass this through,
there isn't anything to warn about. This also applies to 'systemctl set-environment',
where the variable name and value are passed as arguments.
The only case where the warning *might* be useful is where the user might be
surprised by the value. This occurs when importing variables from the inherited
environment, i.e. in 'systemctl import-environment'. In not convinced that this is
useful, since the user better control their shell environment anyway.
$ systemctl import-environment
Calling import-environment without a list of variable names is deprecated.
Environment variable $LESS_TERMCAP_mb contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_md contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_me contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_se contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_so contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_ue contains control characters, importing anyway.
Environment variable $LESS_TERMCAP_us contains control characters, importing anyway.
Environment variable $ZZZ contains control characters, importing anyway.
I was quite confused what is happening:
$ XXX=xxx
$ systemctl --user import-environment XXX
$ systemctl --user show-environment | grep XXX
(nothing)
Obviously, 'export XXX' was missing. Without any indication why the
export is not happening, this can be hard to figure out.
Another option would be to error out. But so far we didn't, and doing
that could break some script which optimistically tries to export some
variables, if present.
Allow to setup new bind mounts for a service at runtime (via either
DBUS or a new 'systemctl bind' verb) with a new helper that forks into
the unit's mount namespace.
Add a new integration test to cover this.
Useful for zero-downtime addition to services that are running inside
mount namespaces, especially when using RootImage/RootDirectory.
If a service runs with a read-only root, a tmpfs is added on /run
to ensure we can create the airlock directory for incoming mounts
under /run/host/incoming.
../src/systemctl/systemctl-list-units.c: In function ‘output_units_list’:
../src/systemctl/systemctl-list-units.c:112:75: warning: comparison of integer expressions of different signedness: ‘int’ and ‘unsigned int’ [-Wsign-compare]
112 | for (const UnitInfo *u = unit_infos; unit_infos && u - unit_infos < c; u++) {
| ^
The pointer difference is signed. I don't know why gcc warns on 32bits, but
not otherwise.
gcc-10.2.1-9.fc33.x86_64, -m32
find_paths_to_edit() makes 2 calls to unit_find_paths(), one of which is
a retry client-side. ret_dropin_paths should be passed the same in
both cases.
After 85c5d313b5, if you, for example,
create a drop-in for -.slice without a corresponding -.slice file, you will
get the following:
# put some valid stuff in /etc/systemd/system/-.slice.d/override.conf
[root@image ~]# systemctl daemon-reload
[root@image ~]# systemctl edit -- -.slice
Assertion 'path' failed at src/systemctl/systemctl-edit.c:425, function
find_paths_to_edit(). Aborting.
Aborted
The aforementioned commit sets the ret_dropin_paths argument for
unit_find_paths(). Thus, unit_find_paths() returns 1 in the example above
because it finds a relevant drop-in. However find_paths_to_edit() was written
to expect 1 only if the unit file itself exists (it does not in this example).
To make this behave more like the version of `systemctl edit` prior to
this commit, add an additional check so the code enters the
"unit file not found" code branch.
As described in #2680, systemctl did ignore inhibitors if it is not
attached to a tty to allow scripts to ignore inhibitors automatically.
This pull request preserves this behavior but allows scripts to
explicit check inhibitors if required.
The new parameter '--check-inhibitors=yes' enables this feature.
The old parameter '-i'/'--ignore-inhibitors' was deprecated in favor
of '--check-inhibitors=no', the default behaviour can be specified
with '--check-inhibitors=auto'.
The new parameter is also described in the documentations and shell
completions found here.
Importing the full environment is convenient, but it doesn't work too well in
practice, because we get a metric ton of shell-specific crap that should never
end up in the global environment block:
$ systemctl --user show-environment
...
SHELL=/bin/zsh
AUTOJUMP_ERROR_PATH=/home/zbyszek/.local/share/autojump/errors.log
AUTOJUMP_SOURCED=1
CONDA_SHLVL=0
CVS_RSH=ssh
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
DESKTOP_SESSION=gnome
DISPLAY=:0
FPATH=/usr/share/Modules/init/zsh-functions:/usr/local/share/zsh/site-functions:/usr/share/zsh/site-functions:/usr/share/zsh/5.8/functions
GDMSESSION=gnome
GDM_LANG=en_US.UTF-8
GNOME_SETUP_DISPLAY=:1
GUESTFISH_INIT=$'\\e[1;34m'
GUESTFISH_OUTPUT=$'\\e[0m'
GUESTFISH_PS1=$'\\[\\e[1;32m\\]><fs>\\[\\e[0;31m\\] '
GUESTFISH_RESTORE=$'\\e[0m'
HISTCONTROL=ignoredups
HISTSIZE=1000
LOADEDMODULES=
OLDPWD=/home/zbyszek
PWD=/home/zbyszek
QTDIR=/usr/lib64/qt-3.3
QTINC=/usr/lib64/qt-3.3/include
QTLIB=/usr/lib64/qt-3.3/lib
QT_IM_MODULE=ibus
SDL_VIDEO_MINIMIZE_ON_FOCUS_LOSS=0
SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/2612,unix/unix:/tmp/.ICE-unix/2612
SHLVL=0
STEAM_FRAME_FORCE_CLOSE=1
TERM=xterm-256color
USERNAME=zbyszek
WISECONFIGDIR=/usr/share/wise2/
...
Plenty of shell-specific and terminal-specific stuff that have no global
significance.
Let's start warning when this is used to push people towards importing only
specific variables.
Putative NEWS entry:
* systemctl import-environment will now emit a warning when called without
any arguments (i.e. to import the full environment block of the called
program). This command will usually be invoked from a shell, which means
that it'll inherit a bunch of variables which are specific to that shell,
and usually to the tty the shell is connected to, and don't have any
meaning in the global context of the system or user service manager.
Instead, only specific variables should be imported into the manager
environment block.
Similarly, programs which update the manager environment block by directly
calling the D-Bus API of the manager, should also push specific variables,
and not the full inherited environment.
commit 15d7ab87c4 introduced the
change to add an 'alias' state, but it was wired to systemctl
only when running in 'client-side' mode. Return success as
expected and documented also when running in 'server-mode'.
Fixes https://github.com/systemd/systemd/issues/18134
This is unfortunately harder to implement than it sounds. The user's bus
is bound a to the user's lifecycle after all (i.e. only exists as long
as the user has at least one PAM session), and the path dynamically (at
least theoretically, in practice it's going to be the same always)
generated via $XDG_RUNTIME_DIR in /run/.
To fix this properly, we'll thus go through PAM before connecting to a
user bus. Which is hard since we cannot just link against libpam in the
container, since the container might have been compiled entirely
differently. So our way out is to use systemd-run from outside, which
invokes a transient unit that does PAM from outside, doing so via D-Bus.
Inside the transient unit we then invoke systemd-stdio-bridge which
forwards D-Bus from the user bus to us. The systemd-stdio-bridge makes
up the PAM session and thus we can sure tht the bus exists at least as
long as the bus connection is kept.
Or so say this differently: if you use "systemctl -M lennart@foobar"
now, the bus connection works like this:
1. sd-bus on the host forks off:
systemd-run -M foobar -PGq --wait -pUser=lennart -pPAMName=login systemd-stdio-bridge
2. systemd-run gets a connection to the "foobar" container's
system bus, and invokes the "systemd-stdio-bridge" binary as
transient service inside a PAM session for the user "lennart"
3. The systemd-stdio-bridge then proxies our D-Bus traffic to
the user bus.
sd-bus (on host) → systemd-run (on host) → systemd-stdio-bridge (in container)
Complicated? Well, to some point yes, but otoh it's actually nice in
various other ways, primarily as it makes the -H and -M codepaths more
alike. In the -H case (i.e. connect to remote host via SSH) a very
similar three steps are used. The only difference is that instead of
"systemd-run" the "ssh" binary is used to invoke the stdio bridge in a
PAM session of some other system. Thus we get similar implementation and
isolation for similar operations.
Fixes: #14580
A comment indicates the start of the new contents of the override file,
and another indicates that lines following it will be discarded once
editing is finished.
The contents of the unit file and drop-ins are listed out after this
last marker.
Adds WRITE_STRING_FILE_TRUNCATE to set O_TRUNC when opening a file.
Thanks to cgzones for providing the required SELinux function calls.
Co-authored-by: Christian Göttsche <cgzones@googlemail.com>
We would return ENOENT, which is extremely confusing. Strace is not helpful because
no *file* is actually missing. So let's add some logs at debug level and also use
a custom return code. Let all user-facing utilities print a custom error message
in that case.
When doing import-environment, we shouldn't fail if some assignment is invalid.
OTOH, if the invalid assignment is specified as a positional argument, we should
keep failing.
This would also fix https://bugzilla.redhat.com/show_bug.cgi?id=1754395, by
ignoring certain variables which are not important in that scenario. It seems
like the right thing to do in general.
This is just some refactoring: shifting around of code, not change in
codeflow.
This splits up the way too huge systemctl.c in multiple more easily
digestable files. It roughly follows the rule that each family of verbs
gets its own .c/.h file pair, and so do all the compat executable names
we support. Plus three extra files for sysv compat (which existed before
already, but I renamed slightly, to get the systemctl- prefix lik
everything else), a -util file with generic stuff everything uses, and a
-logind file with everything that talks directly to logind instead of
PID1.
systemctl is still a bit too complex for my taste, but I think this way
itc omes in a more digestable bits at least.
No change of behaviour, just reshuffling of some code.
It's an auxiliary function to the UnitInfo structures, and very generic.
Let's hence move it over to the other code operating with UnitInfo, even
if it's not used by code outside of systemctl (yet).
With new directive SystemCallLog= it's possible to list system calls to be
logged. This can be used for auditing or temporarily when constructing system
call filters.
---
v5: drop intermediary, update HASHMAP_FOREACH_KEY() use
v4: skip useless debug messages, actually parse directive
v3: don't declare unused variables with old libseccomp
v2: fix build without seccomp or old libseccomp
Symbolic names and number in the appropriate range are allowed
(log_level_from_string() DTRT already).
The target names are more messy, so we leave the verification to the service.
Heavily inspired by #15622. This adds:
systemctl service-log-level systemd-resolved
systemctl service-log-level systemd-resolved info
systemctl service-log-target systemd-resolved
systemctl service-log-target systemd-resolved console
We already have systemctl verbs log-level, log-target, and service-watchdogs.
Those two new verbs tie nicely into this scheme.
The list was rather ad hoc, with "reset-failed" sandwiched between
"help" and "list-dependencies". Since a person will usually either want
to introspect state in various ways or modify state in a certain way, let's
put all the introspection commands together and all the ones that actually
have an effect second.
In various cases, we would say 'return log_warning()' or 'return log_error()'. Those
functions return 0 if no error is passed in. For log_warning or log_error this doesn't
make sense, and we generally want to propagate the error. In the few cases where
the error should be ignored, I think it's better to split it in two, and call 'return 0'
on a separate line.
Follow the same model established for RootImage and RootImageOptions,
and allow to either append a single list of options or tuples of
partition_number:options.
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Luca Boccassi
Lennart Poettering
Anita Zhang
Felix Stupp
Luca Boccassi
williamvdsandChristian Göttsche
Frantisek Sumsal
Topi Miettinen
fangxiuning