Clean up ignore_signals() + default_signals() + sigaction_many() a bit:
make it unnecessary to explicitly terminate the signal list with -1.
Merge all three calls into a single function that is just called with
slightly different parameters. And eliminate an unnecessary extra
iteration in its inner for() loop.
No change in behaviour.
argv[0] might be prefixed by a path, and we shouldn't get confused by
that. Hence provide a simple helper call that abstracts the checking
away, which we can use everywhere, and expose the same behaviour, even
if argv[0] is not set.
(While we are at it, port all other multi-call binaries over to the new
helper, too)
Follow-up for: d41a9e4fc1
--no-legend is replaced by --legend=no.
--quiet now implies --legend=no, but --legend=yes may be used to override that.
--quiet controls hints and warnings and such, and --legend controls just the
legends. I think it makes sense to allow both to controlled independently, in
particular --quiet --legend makes sense when using systemctl in a script to
provide some user-visible output.
Fixes#18560.
We almost never use the named enum type, in almost all cases we use
"int" instead, since we overload it with negative errnos. To simplify
things, let's use "int" really everywhere.
Moreover, let's rename the fields for this enum to "type_or_errno", to
make the overloading clear. And let's ad some assertions that things are
in the right range.
With all the preparatory work in previous PRs, we can now call static destructors
repeatedly without issue. We need to do it here so that global variables allocated
during parsing are properly freed.
I started working on this because I wanted to change how
DEFINE_TRIVIAL_CLEANUP_FUNC is defined. Even independently of that change, it's
nice to make make things more consistent and predictable.
Memory sanitizer would report leaked memory from --boot-load-entry=help.
Maybe we should disable all bus connections from the fuzzer? It seems not
appropriate to communicate with logind. OTOH, in a real fuzzing environment
this call should just fail, so maybe that's OK.
This is almost equivalent to 'busctl call-method org.freedesktop.systemd1
/org/freedesktop/systemd1 org.freedesktop.systemd1.Manager EnqueueMarkedJobs',
but waits for the jobs to finish.
The immediate motivation is to allow fuzz-systemctl-parse-argv to cover also
the other code paths. p_i_s_n is not getting set (and it probably shouldn't),
so the fuzzer would only cover the paths for ./systemctl, and not ./reboot,
etc. Looking at argv[0] instead, which is passed as part of the fuzzer data,
fixes that.
But I think in general it's more correct to look at argv[0] here: after all we
have all the information available through local variables and shouldn't go out
of our way to look at a global.
As suggested in https://github.com/systemd/systemd/pull/11484#issuecomment-775288617.
This does not touch anything exposed in src/systemd. Changing the defines there
would be a compatibility break.
Note that tests are broken after this commit. They will be fixed in the next one.
Does what the name suggests. Obviously inspired by sudoers, but note that
our tools are not supposed to be installed suid, so there is no privilege
boundary to cross here.
The last release of Upstart was July 2014 [1], and there have been no new
commits to the repo. We should move on too.
[1] https://lists.ubuntu.com/archives/upstart-devel/2014-July/003313.html
The only real support was in the code that looked for $PREVLEVEL.
https://codesearch.debian.net/search?q=PREVLEVEL&literal=1&perpkg=1 shows this
string in our own code (or the copy in elogind), our own man pages, and init
scripts for two packages (brltty, salt), which shouldn't be used with systemd.
(And both *check* for PREVLEVEL, and don't set it. So most likely nothing at
all sets it.)
This effectively reverts 41d1f469cf.
Before this, e.g., `networkctl reload` invoked by `systemctl reload systemd-networkd.service`
does not produce debugging logs even if systemd.log-level=debug is set. This fixes
the issue.
I think this formatting was originally used because it simplified
adding new options to the help messages. However, these days, most
tools their help message end with "\nSee the %s for details.\n" so
the final line almost never has to be edited which eliminates the
benefit of the custom formatting used for printf() help messages.
Let's make things more consistent and use the same formatting for
printf() help messages that we use everywhere else.
Prompted by https://github.com/systemd/systemd/pull/18355#discussion_r567241580
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.
