IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Things are currently fairly ugly in Fedora: we create $BOOT/$MACHINE_ID/$KERNEL_VERSION/,
and then 20-grub.install that is installed by grub2-common.rpm wants to remove that
directory before 50-dracut.install get a chance to run. 50-dracut.install
checks for the presence of that directory to decide where to install the
kernel. So let's make the creation of the directory conditional. Previous
commit changes bootctl install to create $BOOT/$MACHINE_ID, and this commit
makes kernel-install not create it. In effect, the entry directory will only be
created if 'bootctl install' or something else created the parent directory.
https://bugzilla.redhat.com/show_bug.cgi?id=1648907
"BOOT" is misleading, because it sounds like this refers to /boot or $BOOT,
when in fact it refers to some subdirectory. Those variable names are purely
interal, so we can change them. $BOOT_DIR_ABS was used in NEWS, but it should
not be (because it is an internal detail), so the old NEWS entry is reworded to
use "entry directory".
The string validation should always be done correctly, and not fail just
because EFI is turned off. After all an EFI loader entry name string
remains properly formatted regardless if EFI is on or off...
Fixes: #11948
When enabled, three samples are used to determine the value of a
received bit by majority rule.
This patch adds support for the TripleSampling= option in the [CAN]
section of .network files.
This makes it easier to see what is going on. Documentation for
--verbose and --help is added to the man page. Our plugins are updated
to also log a bit.
If EFI is disabled compilation can fail with:
../src/login/logind-dbus.c: In function ‘property_get_reboot_to_boot_loader_entry’:
../src/login/logind-dbus.c:2772:29: error: implicit declaration of function ‘efi_loader_entry_name_valid’; did you mean ‘efi_loader_get_features’? [-Werror=implicit-function-declaration]
} else if (!efi_loader_entry_name_valid(v)) {
^~~~~~~~~~~~~~~~~~~~~~~~~~~
efi_loader_get_features
../src/login/logind-dbus.c:2772:29: warning: nested extern declaration of ‘efi_loader_entry_name_valid’ [-Wnested-externs]
This adds stub for efi_loader_entry_name_valid() to enable compilation.
Similar to the cgroup magic we nowadays do when listening to sockets, to
assign them the right bpf programs, let's also do the same and join the
specified netns in the child process.
This allows people to listen in sockets in specific namespaces, or join
multiple services and socket units together to live in the same
namespace.
The new call allows us to open a netns from the file system, and store
it in a "storage fd pair". It's supposed to work with setup_netns() and
allows pre-population of the netns used with one opened from the file
system.
We don't load the selinux label database anyway, hence this is not going
to do anything at all. Let's simplify this hence and drop the explicit
request.
Also note that today SELinux can take the filename into account when
automatically deducing the label for a new file, hence even if this code
actually would have done something it is redundant today.
let's use mkdir_parents() (because its shorter), and 0755 as access
mode, so that things have the access mode tmpfiles.d also suggests.
Prompted by: #11903
if we sync the legacy and unified trees before moving to the right
subcgroup then ultimately the cgroup paths in the hierarchies will be
out-of-sync... Hence, let's move the payload first, and sync then.
Addresses: https://github.com/systemd/systemd/pull/9762#issuecomment-441187979
unit_require_mounts_for may be passed path arguments that contain "."
components like for user's home directories where "." is sometimes used
to specify some form of anchor point.
This change stops considering such path as an error and removes the "."
components instead.
Closes: #11910
It seems that my EFI storage is corrupted. The kernel reports the file as present, but returns
an error when reading. Nevertheless, this shouldn't prevent me from reading the entry
list.
Fixes#11909.
This avoids double compilation. Those files are tiny, so it doesn't save time,
but we avoid repeated warnings and errors, and it's generally cleaner to it
this way.
The number of commands in 'ninja -C build clean && ninja -C build' drops from
1462 to 1455 for me.
By defining rootprefix= we avoid a double slash in $systemdsystemunitdir and
other variables. This fixes a regression introduced in
1c2c7c6cb3 where the variables using rootprefix=/
would start with a double slash. This should be interpreted the same, but is
certainly ugly.
The rootprefix variable was added to systemd.pc in
1c2c7c6cb3, so there is no question of backwards
compatiblity. If people try to "override" the prefix and specify
--define-variable=rootprefix=/, they will get a double slash, which should be
OK, and is the same as --define-variable=rootprefix=/something/, which also
results in a double slash somewhere in the strings.
(This also removes support for booting into the EFI firmware setup
without logind. That's because otherwise the non-EFI fallback logind
implements can't work.)
Fixes: #9896
This behaves similar to the "boot into firmware" logic, and also allows
either direct EFI operation (which sd-boot supports and others might
support eventually too) or override through env var.
Now only two operations are left. Let's just move this into the caller,
since it should make things simpler, clearer and shorter, in particular
as there's only a single user for this.
It's a simple wrapper around boot_entries_load_config(), but determines
the ESP/XBOOTLDR paths automatically at first. Also, it looks for a path
/run/boot-loader-entries/ and loads the entries from there if it
exists. This is supposed to be a hook for other boot loaders to make our
tools aware of their own entries.
Previously, bootctl would show boot loader entries discovered by the
boot loader which couldn't found locally separately in the output.
Let's move this code into bootspec.c, and beef it up a bit. This way we
can use it later on for logind, and correctly show automatically
discovered windows/macos entries too.
find_default_boot_entry() is only used by systemctl.c, and currently
handles one log message in the caller instead of the callee. Let's
simplify that and move it over, too
This extends the reboot-to-firmware logic in logind, so that other than
EFI firmwares could be theoretically support. The scheme is like this:
if you want to support this, set the $SYSTEMD_REBOOT_TO_FIRMWARE=1 env
var for logind. If so, this will override the EFI logic, and cause a
file /run/systemd/reboot-to-firmware file to be created when
reboot-to-firmware is requested. This file has no contents, it's mere
existance indicates a reboot with reboot-to-firmware set.
The idea is that for alternative firmwares a drop-in for logind is added
that sets the env var, in combination with some code run during shutdown
that checks for the file and does the right thing.
It was already the case before commit a75211421f,
which upgraded the log to warning.
This seems an unintended side effect as the commit message doesn't mention it
and the old behavior looks more appropriate.
Let's move the shutdown binary into its own subdirectory in
src/shutdown, after all it is relatively isolated from the normal PID 1
sources, being a different binary and all.
Unfortunately it's not possible to move some of the code, since it is
shared with PID 1, that I wished we could move, but I still think it's
worth it.
This fixes bugs introduced by 29448498c7
and d838e14515.
Previously, RUN and SECLABEL keys are stored in udev_list with its unique
flag is false. If the flag is false, then udev_list is just a linked
list and new entries are always added in the last.
So, we should use OrderedHashmap instead of Hashmap.
Fixes#11368.
We'd call dns_resource_record_equal(), which calls dns_resource_key_equal()
internally, and then dns_resource_key_equal() a second time. Let's be
a bit smarter, and call dns_resource_key_equal() only once.
(before)
dns_resource_key_hash_func_count=514
dns_resource_key_compare_func_count=275
dns_resource_key_equal_count=62371
4.13s user 0.01s system 99% cpu 4.153 total
(after)
dns_resource_key_hash_func_count=514
dns_resource_key_compare_func_count=276
dns_resource_key_equal_count=31337
2.13s user 0.01s system 99% cpu 2.139 total
This doesn't necessarily make things faster, because we still spend more time
in dns_answer_add(), but it improves the compuational complexity of this part.
If we even make dns_resource_key_equal_faster, this will become worthwhile.
Run: systemctl show -a dbus.service | grep -E "SELinuxContext|AppArmorProfile|SmackProcessLabel"
Before patch:
SELinuxContext=[unprintable]
AppArmorProfile=[unprintable]
SmackProcessLabel=[unprintable]
After patch:
SELinuxContext=[""|"value of context"]
AppArmorProfile=[""|"value of context"]
SmackProcessLabel=[""|"value of context"]
Same as with the other users, any non-trivial use of the objects requires
use from a single thread only or external locking. Using atomic operations
just for reference counts is not useful.
The sd-hwdb objects cannot be used concurrently from two threads in any
meaningful way, because query and iteration operations modify the object.
Thus atomic reference counts are pointless.
We had atomic counters, but all other operations were non-serialized. This
means that concurrent access to the bus object was only safe if _all_ threads
were doing read-only access. Even sending of messages from threads would not be
possible, because after sending of the message we usually want to remove it
from the send queue in the bus object, which would race. Let's just kill this.
The subvol snapshot logic doesn't cover sub-mounts either, and it really
shouldn't in the general case, hence let's simply stop at submounts in
all cases, both in the main and in the fall-back codepath.
As discussed here:
https://github.com/systemd/systemd/pull/11243#pullrequestreview-209477230
Before this commit bus messages had a single reference count: when it
reached zero the message would be freed. This simple approach meant a
cyclic dependency was typically seen: a message that was enqueued in a
bus connection object would reference the bus connection object but also
itself be referenced by the bus connection object. So far out strategy
to avoid cases like this was: make sure to process the bus connection
regularly so that messages don#t stay queued, and at exit flush/close
the connection so that the message queued would be emptied, and thus the
cyclic dependencies resolved. Im many cases this isn't done properly
however.
With this change, let's address the issue more systematically: let's
break the reference cycle. Specifically, there are now two types of
references to a bus message:
1. A regular one, which keeps both the message and the bus object it is
associated with pinned.
2. A "queue" reference, which is weaker: it pins the message, but not
the bus object it is associated with.
The idea is then that regular user handling uses regular references, but
when a message is enqueued on its connection, then this takes a "queue"
reference instead. This then means that a queued message doesn't imply
the connection itself remains pinned, only regular references to the
connection or a message associated with it do. Thus, if we end up in the
situation where a user allocates a bus and a message and enqueues the
latter in the former and drops all refs to both, then this will detect
this case and free both.
Note that this scheme isn't perfect, it only covers references between
messages and the busses they are associated with. If OTOH a bus message
is enqueued on a different bus than it is associated with cyclic deps
cannot be recognized with this simple algorithm, and thus if you enqueue
a message associated with a bus A on a bus B, and another message
associated with bus B on a bus A, a cyclic ref will be in effect and not
be discovered. However, given that this is an exotic case (though one
that happens, consider systemd-bus-stdio-bridge), it should be OK not to
cover with this, and people have to explicit flush all queues on exit in
that case.
Note that this commit only establishes the separate reference counters
per message. A follow-up commit will start making use of this from the
bus connection object.
Don't try to be smart, don't bypass the ref counting logic if there's no
real reason to.
This matters if we want to tweak the ref counting logic later.
Let's make sure our own code follows coding style and initializes all
return values on all types of success (and leaves it uninitialized in
all types of failure).
Let's do this like we usually do and size arrays with size_t.
We already do this for the "allocated" counter correctly, and externally
we expose the queue sizes as uint64_t anyway, hence there's really no
point in usigned "unsigned" internally.
Previously, when we'd copy an individual file we'd synthesize a
user.crtime_usec xattr with the source's creation time if we can
determine it. As the creation/birth time was until recently not
queriable form userspace this effectively just propagated the same xattr
on the source to the same xattr on the destination. However, current
kernels now allow to query the birthtime using statx() and we do make
use of that now. Which means that suddenly we started synthesizing these
xattrs much more regularly.
Doing this actually does make sense, but only in very few cases:
not for the typical regular files we copy, but certainly when dealing
with disk images. Hence, let's keep this kind of propagation, but let's
make it a flag and default to off. Then turn it on whenever we deal with
disk images, and leave it off otherwise.
This is particularly relevant as overlayfs combining a real fs, and a
tmpfs on top will result in EOPNOTSUPP when it is attempted to open a
file with xattrs for writing, as tmpfs does not support xattrs, and
hence the copy-up cannot work. Hence, let's avoid synthesizing this
needlessly, to increase compat with overlayfs.
