We check the same condition at various places. Let's add a trivial,
common helper for this, and use it everywhere.
It's not going to make things much faster or much shorter, but I think a
lot more readable
This extends the logic by which we look for drop-ins for unit files when
loading them. Previously for a unit "foo-quux-bar.service" we'd look in
a directory "foo-quux-bar.service.d" accompanying it for extension
dropins. With this change we'll additionally look in:
"foo-quux-.service.d" and "foo-.service.d", i.e. we'll truncate the unit
name after every dash.
This is an alternative to templating for many services, as it permits
configuring defaults for sets of units that all use the same prefix in
the unit name. This is particularly useful in slice, mount and
automount units which reflect a hierarchy of concepts, as it permits
setting defaults for specific subsets of the tree. For example, in order
to provide every user with a memory of 1G it's now possible to do:
# mkdir -p /etc/systemd/system/user-.slice.d
# cat > /etc/systemd/system/user-.slice.d/50-memory.conf << EOF
[Slice]
MemoryMax=1G
EOF
# systemctl daemon-reload
This makes use of the fact that every user gets his own slice unit when
logging in, named "user-$UID.slice".
This doesn't precisely provide what is requested in #2556, but it does
provide equivalent functionality.
Fixes: #2556
See: #3504#7599
$ sudo swapoff -av
swapoff /dev/vda4
$ sudo systemctl hibernate
Failed to hibernate system via logind: Not enough swap space for hibernation
Fixes#6729.
can_sleep() returns 0 if the operation is impossible, but
the code assumed that negative is returned in that case,
in effect reporting s2h was possible even if hibernation or
suspend were not possible.
The Linux kernel is adding support for configuring the offset
into a disk. This allows swapfiles to be more usable as users
will no longer need to set the offset on their kernel command
line.
Use this API in systemd when hibernating as well.
Signed-off-by: Mario Limonciello <mario.limonciello@dell.com>
Files which are installed as-is (any .service and other unit files, .conf
files, .policy files, etc), are left as is. My assumption is that SPDX
identifiers are not yet that well known, so it's better to retain the
extended header to avoid any doubt.
I also kept any copyright lines. We can probably remove them, but it'd nice to
obtain explicit acks from all involved authors before doing that.
When we try to read meta-data from an image, don't bother with mounting
/home or the ESP, as that's not where the metadata is. This not only
speeds things up a bit, but also has the benefit that setups where an
unencrypted root is mixed with an encrypted /home (which I have on one
of my own systems) won't result in errors that the crypto key is needed.
This extends on #8609, and makes two changes:
1. We'll now explicitly check that the child devices of a block device
we are interested in (i.e. the partitions) are block devices themselves.
On newer kernels the mmc rpmb stuff is actually exposed as char rather
than block device as before, and they probably should have been that in
the first place. By adding this check we'll hence filter out these weird
devices through a second rule too, that hopefully makes things a bit
more future-proof, should more devices like this be added eventually,
or other subsystems do a similar thing.
2. When counting partitions we'll now also check the devnum of the
device being non-null, which we already do when matching up the devices
in the second iteration. This should make things more robust, and
prevent other kinds of miscounting, which after all was the main
issue #8609 fixed.
Filter-out RPMB partitions and boot partitions from MMC devices when
counting partitions enumerated by the kernel. Also factor out the now
duplicated code into a separate function.
This complement the previous fixes to the problem reported in
https://github.com/systemd/systemd/issues/5806
The names of drop-in files can be anything as long as they are suffixed
in ".conf", hence don't be stricter than necessary when validating the
names used in symlink chains of such drop-in files.
Also, drop-in files should not be ale to change the type of unit file
itself, i.e. not affect whether it is considered masked or an alias as a
whole.
This adds a flag SEARCH_DROPIN that is passed whenever we load a drop-in
rather the main unit file, and in that case loosen checks and behaviour
we otherwise enforce for the unit file itself. Specifically:
1. If SEARCH_DROPIN is passed we won't change the unit's info->type
field anymore, as that field (which can be REGULAR, MASKED, SYMLINK)
should not be affected by drop-ins, but only by the unit file itself.
2. If SEARCH_DROPIN is passed we will shortcut following of symlink
chains, and not validate the naming of each element in the chain,
since that's irrelevant for drop-ins, and only matters for the unit
file itself.
Or in other words, without this:
1. A symlink /etc/systemd/system/foobar.service.d/20-quux.conf →
/dev/null might have caused the whole of foobar.service to be
considered "masked".
2. A symlink /etc/systemd/system/foobar.service.d/20-quux.conf →
/tmp/miepf might have caused the whole loading of foobar.service to
fail as EINVAL, as "miepf" is not a valid unit name.
This adds flags BUS_MAP_STRDUP and BUS_MAP_BOOLEAN_AS_BOOL.
If BUS_MAP_STRDUP is set, then each "s" message is duplicated.
If BUS_MAP_BOOLEAN_AS_BOOL is set, then each "b" message is
written to a bool pointer.
Follow-up for #8488.
See https://github.com/systemd/systemd/pull/8488#discussion_r175816270.
This is a separate commit only because it actually *increases* memory allocations:
==3256== total heap usage: 100,120 allocs, 100,120 frees, 13,097,140 bytes allocated
to
==4690== total heap usage: 100,121 allocs, 100,121 frees, 14,198,329 bytes allocated
Essentially, we do a little more work to reduce the memory footprint a bit. For a
test where we just allocate the memory and drop it soon afterwards, this is not
beneficial, but it should still be useful for a long running program.
ubsan times out because we do too many allocations:
$ valgrind build/fuzz-unit-file test/fuzz-regressions/fuzz-unit-file/oss-fuzz-6977-full
...
test/fuzz-regressions/fuzz-unit-file/oss-fuzz-6977-full... ok
==1757==
==1757== HEAP SUMMARY:
==1757== in use at exit: 0 bytes in 0 blocks
==1757== total heap usage: 199,997 allocs, 199,997 frees, 90,045,318,585 bytes allocated
...
==3256== total heap usage: 100,120 allocs, 100,120 frees, 13,097,140 bytes allocated
https://oss-fuzz.com/v2/issue/4651449704251392/6977 should now be really fixed.
e3c3d6761b was the first attempt, but even with this change, e3c3d6761b
still makes sense.
This reverts the mmap parts of f5aeac1439,
but keeps the part which restricts address families which works
correctly.
Unfortunately the MIPS toolchains still do not implement PT_GNU_STACK.
This means that while the commit to restrict mmap on MIPS was "correct",
it had the side effect of causing pthread_create to fail because glibc tries
to allocate an executable stack for new threads in the absense of
PT_GNU_STACK. We should wait until PT_GNU_STACK is implemented in all
the relevant parts of the toolchain (at least gcc and glibc) before
enabling this again.
This is similar to TAKE_PTR() but operates on file descriptors, and thus
assigns -1 to the fd parameter after returning it.
Removes 60 lines from our codebase. Pretty good too I think.
This macro will read a pointer of any type, return it, and set the
pointer to NULL. This is useful as an explicit concept of passing
ownership of a memory area between pointers.
This takes inspiration from Rust:
https://doc.rust-lang.org/std/option/enum.Option.html#method.take
and was suggested by Alan Jenkins (@sourcejedi).
It drops ~160 lines of code from our codebase, which makes me like it.
Also, I think it clarifies passing of ownership, and thus helps
readability a bit (at least for the initiated who know the new macro)
This rearranges chase_symlinks() a bit: if no special flags are
specified it will now revert to behaviour before
b12d25a8d6. However, if the new
CHASE_TRAIL_SLASH flag is specified it will follow the behaviour
introduced by that commit.
I wasn't sure which one to make the beaviour that requires specification
of a flag to enable. I opted to make the "append trailing slash"
behaviour the one to enable by a flag, following the thinking that the
function should primarily be used to generate a normalized path, and I
am pretty sure a path without trailing slash is the more "normalized"
one, as the trailing slash is not really a part of it, but merely a
"decorator" that tells various system calls to generate ENOTDIR if the
path doesn't refer to a path.
Or to say this differently: if the slash was part of normalization then
we really should add it in all cases when the final path is a directory,
not just when the user originally specified it.
Fixes: #8544
Replaces: #8545
Let's use first_word() instead of startswith(), it's more explanatory
and a bit more correct. Also, let's use the return value instead of
adding +9 when looking for the second part of the directive.
.include lines are already deprecated somewhat, and for example
explicitly not mentioned in the documentation for this reason. Let's get
one step further and generatea warning when we encounter them (but still
process them).
Why are they deprecated? Because they are semantically awful — they
complicate stat() based mtime checks for configuration files and they
allow arbitrary loops we currently have zero protection against and
really shouldn't have to have.
