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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
else an event like "61" never finishes when calculating the next event
also add regression tests for this and other range checks
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
otherwise the numbers are sorted like this:
[1,10,11 .. 19, 2, 20, ..]
which would lead to the wrong next time
also add regression tests for this and mixed forms like:
20..22:*/30
Signed-off-by: Dominik Csapak <d.csapak@proxmox.com>
Previously an external exception (eg. caused by a SIGARLM in a code
which is already inside a run_with_timeout() call) could happen in
various places where we did not properly this situation.
For instance after calling $lock_func() but before reaching the cleanup
code. In this case a lock was leaked.
Additionally the code was broken in that it used perl's automatic hash
creation side effect ($a->{x}->{y} implicitly initializing $a->{x} with
an empty hash when it did not exist). The effect was that if our own
time out was triggered after the initial check for an existing file
handle inside $lock_func() happened (extremely rare since perl would have
to be running insanely slow), the cleanup did:
if (my $fh = $lock_handles->{$$}->{$filename}->{fh}) {
This recreated $lock_handles->{$$}->{$filename} as an empty hash.
A subsequent call to lock_file_full() will think a file descriptor
already exists because the check simply used:
if (!$lock_handles->{$$}->{$filename}) {
While this could have been a one-line fix for this one particular case,
we'd still not be taking external timeouts into account causing the
first issue described above.
read_etc_network_interfaces used the content of
/proc/net/if_inet6 to decide whether an interface's state is
"active", which means an interface is only active when it
has an ipv6 address, thus using net.ipv6.conf.*.disable_ipv6
on an interface will cause it to show as inactive in the web
interface.
We now filter the interfaces found in /proc/dev/net by their
IFF_UP flag read via an SIOCGIFFLAGS ioctl().
Giving unknown interfaces an order-id of 0 caused them to
always be on top of the interfaces file. This is often
undesired. Instead we now only take type-ordering into
account when both interfaces which are being compared have a
known type, and otherwise only use the priority attribute.
This should result in a more stable modification of
interfaces.
Fixes#747
