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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
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.
I read the message and initially thought that there's some bug in time
subtraction. Let's make it clear that the message is about what we'll
do in the future, and not a report on how we waited up until now.
Currently ref count of bpf-program is kept in user space. However, the
kernel already implements its own ref count. Thus the ref count we keep for
bpf-program is redundant.
This PR removes ref count for bpf program as part of a task to simplify
bpf-program and remove redundancies, which will make the switch to
code-compiled BPF programs easier.
Part of #19270
