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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The comment above makes the intent of the code pretty clear:
"use security2_protocol == NULL as indicator".
So revert the condition in the check and fix the logic in the comment while
at it.
The question is how this could have ever worked: if BS->LocateProtocol
(which is supposedly optional) ever failed, we'd crash here. Strange.
Found by coverity.
m->encrypted is set when fstype=="crypto_LUKS", but this is not obvious when
reading decrypt_partition(). Just check if passphrase is set before using
it.
This fixes the (mostly theoretical, since we're only parsing data that we write
ourselves) memleak when iif or oif is deserialized multiple times. Unfortunately
it does not fix the memleak when rule is freed, but that'll require a bigger
effort.
Let's just say that the code wasn't fully functional ;(
Since we only had the parser for serialization, and not the writer, we are
free to change the format. So while at it, let's use shorter names in the
serialization format that match the surrounding style.
If test-resolve is running in some CI environment that doesn't have
reliably working DNS, it's a good idea not to hang forever, let's
time-out after 20s
Let's always use the same logic when parsing error numbers, i.e. use
parse_errno() here too, to unify some code, and tighten the checks a
bit.
This also allows clients to pass errors as symbolic names. Probably
nothing we want to advertise too eagerly (since new daemons generating
this on old service managers won't understand), but still pretty
useful I think, in particular in scripting languages and such, where the
numeric error numbers might not be readily available.
Currenly the only way to remove fds from the fdstore is to fully
stop the service, or to somehow trigger POLLERR/POLLHUP on the fd, in
which case systemd will remove the fd automatically.
Let's add another way: a new message that can be sent to remove fds
explicitly, given their name.
Of course, it's not really a valid sd_notify() message if multiple of
these fields are used in one, but let's handle this somewhat gracefully,
by only processing one of them, and ignoring the rest.
Let's optimize things a bit for the non-debug case. No change in
behaviour.
Main reason to do this is not so much the speed benefit though, but
merely to isolate the code from its surroundings more.
Some devices get reset itself while setting the MTU. we get in to a LOOP .
Once the MTU changed then the DHCP client talking with DHCP server never stops.
networkd gets into a loop and generates endless DHCP requests.
fixes#6593fixes#7380
Now that we don't kill control processes anymore, let's at least warn
about any processes left-over in the unit cgroup at the moment of
starting the unit.
Let's move the cgroup empty check for all unit types into the generic
unit_check_gc() call, out of the per-unit-type _check_gc() type. This
not only allows us to share some code, but also hooks up mount and
socket units with this kind of check, for free, as it was missing there
previously.
Previously, in the service unit type we ran all control processes in a
special subcgroup /control of the unit's main cgroup. Remove that, and
run the control program in the main cgroup instead.
The concept conflicts with cgroupv2's logic of "no processes in inner
nodes": if a unit has a main daemon process running in the main cgroup,
and a reload control process would be started in the /control subcgroup,
then this would necessarily fail, as the main daemon process would
become an inner node process that way.
We could in theory continue to support this in cgroupv1, but in the
interest in keeping behaviour similar in both hierarchies, let's drop
this altogether.
Philosophically maybe it wasn't the greatest idea anyway to just go
berserk and SIGKILL all those processes — loud warning logging might
have sufficed, too.
Before this patch, the bpf cgroup realization state was implicitly set
to "NO", meaning that the bpf configuration was realized but was turned
off. That means invalidation requests for the bpf stuff (which we issue
in blanket fashion when doing a daemon reload) would actually later
result in a us re-realizing the unit, under the assumption it was
already realized once, even though in reality it never was realized
before.
This had the effect that after each daemon-reload we'd end up realizing
*all* defined units, even the unloaded ones, populating cgroupfs with
lots of unneeded empty cgroups.
With this fix we properly set the realiazation state to "INVALIDATED",
i.e. indicating the bpf stuff was never set up for the unit, and hence
when we try to invalidate it later we won't do anything.
We add units to the cgroup realization queue when propagating realizing
requests to sibling units, and when invalidating cgroup settings because
some cgroup setting changed. In the time between where we add the unit
to the queue until the cgroup is actually dispatched the unit's state
might have changed however, so that the unit doesn't actually need to be
realized anymore, for example because the unit went down. To handle
that, check the unit state again, if realization makes sense.
Redundant realization is usually not a problem, except when the unit is
not actually running, hence check exactly for that.
We never use these functions seperately, hence don't bother splitting
them into to.
Also, simplify things a bit, and maintain tables for the attribute files
to chown. Let's also update those tables a bit, and include thenew
"cgroup.threads" file in it, that needs to be delegated too, according
to the documentation.
Some filesystems do not set d_type value when
readdir is called, so entry type is unknown.
Therefore check if accessing entry does not
return ELOOP error.
