Since busname units are only useful with kdbus, they weren't actively
used. This was dead code, only compile-tested. If busname units are
ever added back, it'll be cleaner to start from scratch (possibly reverting
parts of this patch).
Example log:
Jul 22 15:55:21 fedora systemd[1]: a1.service: Found ordering cycle on a2.service/start
Jul 22 15:55:21 fedora systemd[1]: a1.service: Found dependency on a3.service/start
Jul 22 15:55:21 fedora systemd[1]: a1.service: Found dependency on a1.service/start
Jul 22 15:55:21 fedora systemd[1]: a1.service: Job a2.service/start deleted to break ordering cycle starting with a1.service/start
Jul 22 15:55:21 fedora systemd[1]: Starting a1.service...
Jul 22 15:55:21 fedora systemd[1]: Started a1.service.
Example log entry:
Sat 2017-07-22 15:55:21.372389 EDT [s=0004bb6302d94ac3aa69987fb6157338;i=9ae;b=a96eb6153d4f4f3686c7b4
_BOOT_ID=a96eb6153d4f4f3686c7b4db8a432908
_MACHINE_ID=ad18f69b80264b52bb3b766240742383
_HOSTNAME=fedora
PRIORITY=3
SYSLOG_FACILITY=3
SYSLOG_IDENTIFIER=systemd
_UID=0
_GID=0
_PID=1
_TRANSPORT=journal
_CAP_EFFECTIVE=3fffffffff
_COMM=systemd
_EXE=/usr/lib/systemd/systemd
_SYSTEMD_CGROUP=/init.scope
_SYSTEMD_UNIT=init.scope
_SYSTEMD_SLICE=-.slice
_SELINUX_CONTEXT=system_u:system_r:kernel_t:s0
CODE_FILE=../src/core/transaction.c
CODE_FUNC=transaction_verify_order_one
UNIT=a3.service
UNIT=a1.service
UNIT=a2.service
CODE_LINE=430
MESSAGE=a1.service: Job a2.service/start deleted to break ordering cycle starting with a1.service
_CMDLINE=/usr/lib/systemd/systemd --system --deserialize 28
_SOURCE_REALTIME_TIMESTAMP=1500753321372389
This should make it easier to see when any of the units are involved in an
ordering cycle.
Fixes#6336.
v2:
- also update the "Unable to break cycle" message.
This reverts commit 2d058a87ff.
When we add another name to a unit (by following an alias), we need to
reload all drop-ins. This is necessary to load any additional dropins
found in the dirs created from the alias name.
Fixes#6334.
While working on the gateway→_gateway conversion, I noticed that
libidn2 strips the leading underscore in some names.
https://gitlab.com/libidn/libidn2/issues/30 was resolved in
05d753ea69,
which disabled "STD3 ASCII rules" by default, i.e. disabled stripping
of underscores. So the situation is that with previously released libidn2
versions we would get incorrect behaviour, and once new libidn2 is released,
we should be OK.
Let's implement a simple test which checks that the name survives the
roundtrip, and if it doesn't, skip IDN resolution. Under old libidn2 this will
fail in more cases, and under new libidn2 in fewer, but should be the right
thing to do also under new libidn2.
As a follow-up for db3f45e2d2 let's do the
same for all other cases where we create a FILE* with local scope and
know that no other threads hence can have access to it.
For most cases this shouldn't change much really, but this should speed
dbus introspection and calender time formatting up a bit.
Given that we set NOTIFY_SOCKET unconditionally it's not surprising that
processes way down the process tree think it's smart to send us a
notification message.
It's still useful to keep this message, for debugging things, but it
shouldn't be generated by default.
This moves pretty much all uses of getpid() over to getpid_raw(). I
didn't specifically check whether the optimization is worth it for each
replacement, but in order to keep things simple and systematic I
switched over everything at once.
In case fstab-generator is called in the initrd, chase_symlinks()
returns with a canonical path "/sysroot/sysroot/<mountpoint>", if the
"/sysroot" prefix is present in the path.
This patch skips the "/sysroot" prefix for the chase_symlinks() call,
because "/sysroot" is already the root directory and chase_symlinks()
prepends the root directory in the canonical path returned.
QEMU >= 2.10 will include a CPUID leaf with value "TCGTCGTCGTCG"
on x86 when running with the TCG CPU emulator:
https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg05231.html
Existing methods of detecting QEMU are left unchanged for sake of
backcompatibility.
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
Since 3536f49e8f, manager_new() in
user mode requires XDG_RUNTIME_DIR is set. So, in this commit,
setup_fake_runtime_directory() is added in the beginning of test.
Fixes an issue comment in #6384.
This makes it more like other configure defines.
Also, it fixes meson status output which was looking for HAVE_ and ENABLE_
prefixes only (the define under meson was OK, just the summary message was
wrong.)
This introduces {State,Cache,Log,Configuration}Directory= those are
similar to RuntimeDirectory=. They create the directories under
/var/lib, /var/cache/, /var/log, or /etc, respectively, with the mode
specified in {State,Cache,Log,Configuration}DirectoryMode=.
This also fixes#6391.
Trivial performance boost by explicitly bypassing the implicit
locking of stdio.
This significantly affects common cases of `journalctl` usage:
Before:
# time ./journalctl -b -1 > /dev/null
real 0m26.628s
user 0m26.495s
sys 0m0.125s
# time ./journalctl -b -1 > /dev/null
real 0m27.069s
user 0m26.936s
sys 0m0.134s
# time ./journalctl -b -1 > /dev/null
real 0m26.727s
user 0m26.607s
sys 0m0.119s
After:
# time ./journalctl -b -1 > /dev/null
real 0m23.394s
user 0m23.244s
sys 0m0.142s
# time ./journalctl -b -1 > /dev/null
real 0m23.283s
user 0m23.160s
sys 0m0.121s
# time ./journalctl -b -1 > /dev/null
real 0m23.274s
user 0m23.125s
sys 0m0.144s
Fixes https://github.com/systemd/systemd/issues/6341
2d79a0bbb9 did that for TimeoutSec=,
89beff89ed did that for JobTimeoutSec=,
and 0004f698df did that for
x-systemd.device-timeout=. But after parsing x-systemd.device-timeout=xxx
we write it out as JobRunningTimeoutSec=xxx. Two options:
- write out JobRunningTimeoutSec=<a very big number>,
- change JobRunningTimeoutSec= to behave like the other options.
I think it would be confusing for JobRunningTimeoutSec= to have different
syntax then TimeoutSec= and JobTimeoutSec=, so this patch implements the
second option.
Fixes#6264, https://bugzilla.redhat.com/show_bug.cgi?id=1462378.
If you specify "x-systemd.device-timeout" for an NFS mount
point, you get no warning and a meaningless device unit
dependency created.
Better to have a warning and no dependency.
I messed up when adding the definitions in 4278d1f531.
Unfortunately I didn't have the hardware at hand and went by
looking at the kernel headers.
(cherry picked from commit 53196fafcb7b24b45ed4f48ab894d00a24a6d871)
"Failed to add rule for system call access, ignoring: Numerical argument out of domain"
is confusing. Make that "... system call access() / 238".
(cherry picked from commit 977dc6ca5acb8069a2966ec63e7378576bc2ca51)
cgroup namespace wasn't useful for delegation because it allowed resource
control interface files (e.g. memory.high) to be written from inside the
namespace - this allowed the namespace parent's resource distribution to be
disturbed by its namespace-scoped children.
A new mount option, "nsdelegate", was added to cgroup v2 to address this issue.
The flag is meangingful only when mounting cgroup v2 in the init namespace and
makes a cgroup namespace a delegation boundary. The kernel feature is pending
for v4.13.
This should have been the default behavior on cgroup namespaces and this commit
makes systemd try "nsdelegate" first when trying to mount cgroup v2 and fall
back if the option is not supported.
Note that this has danger of breaking usages which depend on modifying the
parent's resource settings from the namespace root, which isn't a valid thing
to do, but such usages may still exist.
Introduces window_matches_fd() for the fd matching case in try_context(),
In find_mmap() we're already walking a list of windows by fd, checking
this is pointless work in a potentially hot loop with many windows.
Instead of context_detach_window() and a manual attach of the new
window, simply call context_attach_window() which performs the
detach first if appropriate.
generator_add_symlink() is extended to ignore EEXIST. This should be fine
for all existing callers.
There's a small difference in behaviour when adding symlinks in sysv-generator:
the message is more generic and does not include ", ignored". But creation of
symlinks shouldn't ever fail except if things are very wrong, so in practice
this shouldn't matter.
Test needed updating: os.path.exists(os.readlink(link)) only works if the link
is absolute (or if we are in the right directory). Let's just use
os.path.exists(link), which properly tests that the symlink target exists.
With previous commits, test-daemon is one of the slowest tests.
Under normal circumstances, the notifications go nowhere anyway,
because the test process does not have privileges.
The timeout can be specified as an argument. This is useful to
e.g. test handling of the notifications, which is much easier
with a longer timeout.
Also, if we fail to set the watchdog, run through the rest of the test
without waiting. I think it's useful to still start the commands to
test the error paths, but we can do it quickly.
journal_file_move_to_object() can skip the second
journal_file_move_to() call if the first one already mapped a
sufficiently large area.
Now that mmap_cache_get() returns the size of the mapped area
when asked, ask for the size and only perform the second call if
the required size exceeds the mapped size instead of the object
header size.
This results in a nice performance boost in my testing, even with
a corpus of many small logs burning much CPU time elsewhere:
Before:
# time ./journalctl -b -1 --no-pager > /dev/null
real 0m16.330s
user 0m16.281s
sys 0m0.046s
# time ./journalctl -b -1 --no-pager > /dev/null
real 0m16.409s
user 0m16.358s
sys 0m0.048s
# time ./journalctl -b -1 --no-pager > /dev/null
real 0m16.625s
user 0m16.558s
sys 0m0.061s
After:
# time ./journalctl -b -1 --no-pager > /dev/null
real 0m15.311s
user 0m15.257s
sys 0m0.046s
# time ./journalctl -b -1 --no-pager > /dev/null
real 0m15.201s
user 0m15.135s
sys 0m0.062s
# time ./journalctl -b -1 --no-pager > /dev/null
real 0m15.170s
user 0m15.113s
sys 0m0.053s
If requested, return the actual mapping size to the caller in
addition to the address.
journal_file_move_to_object() often performs two successive
mmap_cache_get() calls via journal_file_move_to(); one to get the
object header, then another to get the entire object when it's
larger than the header's size.
If mmap_cache_get() returned the actual mapping's size, it's
probable that the second mmap_cache_get() could be skipped when
the established mapping already encompassed the desired size.
If an error is encountered in any of the Exec* lines, WorkingDirectory,
SELinuxContext, ApparmorProfile, SmackProcessLabel, Service (in .socket
units), User, or Group, refuse to load the unit. If the config stanza
has support, ignore the failure if '-' is present.
For those configuration directives, even if we started the unit, it's
pretty likely that it'll do something unexpected (like write files
in a wrong place, or with a wrong context, or run with wrong permissions,
etc). It seems better to refuse to start the unit and have the admin
clean up the configuration without giving the service a chance to mess
up stuff.
Note that all "security" options that restrict what the unit can do
(Capabilities, AmbientCapabilities, Restrict*, SystemCallFilter, Limit*,
PrivateDevices, Protect*, etc) are _not_ treated like this. Such options are
only supplementary, and are not always available depending on the architecture
and compilation options, so unit authors have to make sure that the service
runs correctly without them anyway.
Fixes#6237, #6277.
This has a long history; see see 5261ba9018
which originally introduced the behavior. Unfortunately that commit
doesn't include any rationale, but IIRC the basic issue is that
systemd wants to model the real mount state as units, and symlinks
make canonicalization much more difficult.
At the same time, on a RHEL6 system (upstart), one can make e.g. `/home` a
symlink, and things work as well as they always did; but one doesn't have
access to the sophistication of mount units (dependencies, introspection, etc.)
Supporting symlinks here will hence make it easier for people to do upgrades to
RHEL7 and beyond.
The `/home` as symlink case also appears prominently for OSTree; see
https://ostree.readthedocs.io/en/latest/manual/adapting-existing/
Further work has landed in the nspawn case for this; see e.g.
d944dc9553
A basic limitation with doing this in the fstab generator (and that I hit while
doing some testing) is that we obviously can't chase symlinks into mounts,
since the generator runs early before mounts. Or at least - doing so would
require multiple passes over the fstab data (as well as looking at existing
mount units), and potentially doing multi-phase generation. I'm not sure it's
worth doing that without a real world use case. For now, this will fix at least
the OSTree + `/home` <https://bugzilla.redhat.com/show_bug.cgi?id=1382873> case
mentioned above, and in general anyone who for whatever reason has symlinks in
their `/etc/fstab`.
When running systemd-analyze verify I would get a random subset of warnings
(sometimes none, sometimes one or two):
dev-mapper-luks\x2d8db85dcf\x2d6230\x2d4e88\x2d940d\x2dba176d062b31.swap: Unit is bound to inactive unit dev-mapper-luks\x2d8db85dcf\x2d6230\x2d4e88\x2d940d\x2dba176d062b31.device. Stopping, too.
home.mount: Unit is bound to inactive unit dev-disk-by\x2duuid-75751556\x2d6e31\x2d438b\x2d99c9\x2dd626330d9a1b.device. Stopping, too.
boot.mount: Unit is bound to inactive unit dev-disk-by\x2duuid-56c56bfd\x2d93f0\x2d48fb\x2dbc4b\x2d90aa67144ea5.device. Stopping, too.
When running with debug on, it's pretty obvious what is happening:
home.mount: Changed dead -> mounted
home.mount: Unit is bound to inactive unit dev-disk-by\x2duuid-75751556\x2d6e31\x2d438b\x2d99c9\x2dd626330d9a1b.device. Stopping, too.
home.mount: Trying to enqueue job home.mount/stop/fail
home.mount: Installed new job home.mount/stop as 27
home.mount: Enqueued job home.mount/stop as 27
...
dev-disk-by\x2duuid-75751556\x2d6e31\x2d438b\x2d99c9\x2dd626330d9a1b.device: Installed new job dev-disk-by\x2duuid-75751556\x2d6e31\x2d438b\x2d99c9\x2dd626330d9a1b.device/start as 47
dev-disk-by\x2duuid-75751556\x2d6e31\x2d438b\x2d99c9\x2dd626330d9a1b.device: Changed dead -> plugged
dev-disk-by\x2duuid-75751556\x2d6e31\x2d438b\x2d99c9\x2dd626330d9a1b.device: Job dev-disk-by\x2duuid-75751556\x2d6e31\x2d438b\x2d99c9\x2dd626330d9a1b.device/start finished, result=done
Fixes#2206, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808151.
https://tools.ietf.org/html/rfc5891#section-4.2.3.1 says that
> The Unicode string MUST NOT contain "--" (two consecutive hyphens) in the third
> and fourth character positions and MUST NOT start or end with a "-" (hyphen).
This means that libidn2 refuses to encode such names.
Let's just resolve them without trying to use IDN.
When we compare two size values, let's make sure we cast from the
smaller to the bigger type first, if both types differ, rather than the
reverse in order to not run into overflows.
This way we have a MMapFileDescriptor reference external to the cache,
and can supply the handle directly to mmap_cache_get(), eliminating
hashmap lookups entirely from the hot path.
This should make output deterministic, and independent of the directory
layout on disk. Just using ordered hashmaps would be enough to make
the output deterministic on a specific machine, but to make it
identical on different machines with the same set of files and
directories, names are sorted after being use.
Fixes#6157.
ENOENT is a bit too likely to be returned for various reasons, for
example if /sys or /proc are not mounted and hence the files we need not
around. Hence, let's use ENXIO instead, which is equally fitting for the
purpose but has the benefit that the underlying calls won't generate
this error on their own, hence any ambiguity is removed.
We should either log about all errors in a function, or about none (and
then leave the logging about it to the caller who we propagate the error
to). Given that the callers of find_loop_device() already log about the
returned errors let's hence suppress the log messages in
find_loop_device() itself.
It's unlikely this can ever be triggered, but let's be safe rather than
sorry, and handle the case where the list of mount points is zero, and
the "l" array thus NULL. let's ensure we allocate at least one entry.
It seems that there's a common pattern among the various generators. Let's add
a helper function for it and make use of it in cryptsetup-generator.
This fixes a bunch of theoretical memleaks in error paths, since *to wasn't
generally freed properly. Not thath it matters.
systemctl link is the only systemctl verb that takes a filename (and not
a unit name) as argument
use path_strv_make_absolute_cwd to expand the provided filename in order
to make it easier to use from the command line
keep the absolute pathname requirement when --root is used
[zj: add explicit error messages for the cases of --root and plain filename
instead of skipping normalization and just relying on systemd to refuse
to link non-absolute arguments. This allows us to make the error message
more informative.]
If the input is older than "1970-01-01 UTC", then `parse_timestamp()`
fails and returns -EINVAL. However, if the input is e.g. `-100years`,
then the function succeeds and sets `usec = 0`.
This commit makes the function also succeed for old dates and set
`usec = 0`.
Fixes#6290.
e268b81e moved an fflush() from output_json() to the generic
output_journal(), when it probably should have deleted all fflush()
calls from logs-show.c altogether.
The caller supplies the FILE * to these functions, and should be in
charge of flushing as needed. The current implementation essentially
defeats any buffering stdio was bringing to the table, resulting in
extraneous tiny write() calls in commands like `journalctl -b`.
This commit removes the fflush() call from output_journal(), and adds
them to journalctl before waiting for more entries and at completion.
This way in the hot path when journalctl loops on entries stdio can
combine multiple entries into bulkier write() calls.
Actually the caller of dns_packet_new() pass 0 or the data size of the UDP message.
So try to reflect that, so rename the `mtu` parameter to `min_alloc_dsize`.
In fact `mtu` is the size of the whole UDP message, including the UDP header,
and here we just need to pass the size of data (without header). This was confusing.
Also add a check on the requested allocated size, since some caller do not check what is really allocated.
Indeed the function do not allocate more than DNS_PACKET_SIZE_MAX whatever the value of the `mtu` parameter.
secure_getenv does not work when the process has a nonempty permitted
capability set, which means that it's unduly hard to configure logging in
systemd-logind, systemd-resolved, and others.
secure_getenv is useful for code in libraries which might get called from a
setuid application. log_parse_environment() is never called from our library
code, but directly form various top-level executables. None of them are
installed suid, and none are prepared to be used this way, since many
additional changes would be required to make that safe. We may just as well
drop the check and allow SYSTEMD_LOG_* to properly parsed.
Fixes#4900.
test_readlink_and_make_absolute switches to a temp directory, and then
removes it.
test_get_files_in_directory calls opendir(".") from a directory that has
been removed from the filesystem.
This call sequence triggers a bug in Gentoo's sandbox library. This
library attempts to resolve the "." to an absolute path, and aborts when
it ultimately fails to do so.
Re-ordering the calls works around the issue until the sandbox library
can be fixed to more gracefully deal with this.
Bug: https://bugs.gentoo.org/590084
It is useful to know when a timer will trigger next when looking at a
timer status message so calculate and print that information.
Closes#5738.
Example output:
$ systemctl status dnf-makecache.timer
● dnf-makecache.timer - dnf makecache timer
Loaded: loaded (/usr/lib/systemd/system/dnf-makecache.timer; enabled; vendor preset: enabled)
Active: active (waiting) since Tue 2017-07-04 17:24:02 EDT; 24min ago
Trigger: Tue 2017-07-04 18:15:56 EDT; 27min left
