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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
If an image file is actually a block device taking a lock on it doesn't
really make sense for us: it will interfere with udev's block device
probing logic, and it's not going to propagated across the network
anyway (which is what we are after here). Hence simply don't do it.
Follow-up for 2aaf565a2d
We currently call this ioctl even if we are backed by a regular file,
which is actually the common case. While this doesn't really hurt, it
does result in very confusing logs.
This adds support for dm integrity targets and an associated
/etc/integritytab file which is required as the dm integrity device
super block doesn't include all of the required metadata to bring up
the device correctly. See integritytab man page for details.
Let's define two helpers strdupa_safe() + strndupa_safe() which do the
same as their non-safe counterparts, except that they abort if called
with allocations larger than ALLOCA_MAX.
This should ensure that all our alloca() based allocations are subject
to this limit.
afaics glibc offers three alloca() based APIs: alloca() itself,
strndupa() + strdupa(). With this we have now replacements for all of
them, that take the limit into account.
This is like alloca(), but does two things:
1. Verifies the allocation is smaller than ALLOCA_MAX
2. Ensures we allocate at least one byte
This was previously done manually in all invocations. This adds a handy
helper that does that implicitly.
Right now we already understand "default" as special string for enabling
the watchdog but not reconfiguring its timeout (it is internally mapped
to USEC_MAX). To be systematic this adds "off" as special string for
disabling the watchdog logic (it is internally mapped to 0, which is how
this behaviour was previously requested).
If an error happened while the timeout value was being programmed, the error
was ignored and the watchdog module used the new timeout value whereas the
watchdog device was left with the previous one.
Now in cases of error, the device is now disabled and closed if it wasn't
opened already otherwise the previous timeout value is kept so the device is
still pinged at correct intervals.
Passing 0 meant "disable the watchdog although still kept it opened". However
this case didn't seem to be useful especially since PID1 closes the device if
it is passed the nul timeout.
Hence let's change the meaning of watchdog_setup(0) to match PID1's behavior
which allows to simplify the code a bit.
Hence this patch also drops enable_watchdog().
This patch changes the meaning of USEC_INFINITY value for the watchdog
module.
Previously passing this value was a NOP. It now has a special meaning: it
requests the watchdog module to read the programmed timeout value and reuse it
for pinging the device.
This is mostly useful when the watchdog is started by the firmware and there's
no way to reconfigure the timeout with a different value
afterwards. "RuntimeWatchdogSec=infinity" in system.conf can now be used rather
than putting an arbitrary value that PID1 will fail to set (even if it still
felt back to the programmed timeout).
Please note that "infinity" is not supposed to restore the default value of the
firmware. If the value is changed after booting then "infinity" would simply
reuse the current programmed value. IOW it's a NOP unless the watchdog was
previously closed and in that case it will be reopened and the last programmed
value reused.
Check if any cgroup controller is currently being used as v1, and if so don't
use cgroup unified mode. This is only checked when there is no cgroup already
mounted, and is most useful when running in a container where the host is using
a legacy or hybrid cgroup, since we can't (fully) use unified cgroup, as the
host kernel has the cgroup controllers in use by v1.
This shouldn't be needed if the container manager has pre-mounted cgroups
appropriately based on the host system cgroup setup, but we can't rely
on that always being the case.
With the changes to limit that print 'Found module …' over and over, we were
hitting the journal field message limit, effectively truncating the info output.
Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1998488.
