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 the table of a route is larger than 255, then the value is stored in
RTA_TABLE attribute. But the attribute is not supported by old kernels.
So, first try to read the value from RTA_TABLE attribute, then fallback
to the value in the message header.
In order to avoid inflating the dependency list for the core
library, use dlopen when inspecting elfs, since it's only
used in two non-core executables.
Parsing objects is risky as data could be malformed or malicious,
so avoid doing that from the main systemd-coredump process and
instead fork another process, and set it to avoid generating
core files itself.
On distros using Debian's base-passwd, the name of the group with gid 65534 is
nogroup. Currently, systemd-sysusers creates a spurious "nobody" group
systemd-sysusers[243]: Creating group nobody with gid 996
That's both confusing and redundant, as the nobody user still has primary group
65534 aka nogroup, and the nobody group simply goes completely unused.
So explicitly specify the primary group of the nobody user, and add a line
ensuring that that group exists.
This is not a problem for Debian (or Ubuntu) itself, as they add their own
version of basic.conf in their systemd build logic. But it appears on for
example Yocto/OpenEmbedded.
Assumption in edc027b was that job we first skipped because of active
ratelimit is still in run_queue. Hence we trigger the queue and dispatch
it in the next iteration. Actually we remove jobs from run_queue in
job_run_and_invalidate() before we call unit_start(). Hence if we want
to attempt to run the job again in the future we need to add it back
to run_queue.
Fixes#21458
I've seen this in `NetworkManager-1.34.0-0.3.el8.x86_64` (latest in CentOS
Stream 8 at the time of writing this message) which does not use the latest
Systemd but probably the code base is the same (see
51f93e00a2).
Before the patch:
```
libsystemd: eth0: DHCPv6 client: T1 expires in 34y 3w 6d 45min 31s
libsystemd: eth0: DHCPv6 client: T2 expires in 54y 5month 3w 3d 23h 20min 35s
```
After the patch:
```
libsystemd: eth0: DHCPv6 client: T1 expires in 3d 7h 58min 3s
libsystemd: eth0: DHCPv6 client: T2 expires in 5d 2h 26min 50s
```
same box (x86_64 system) and same DHCPv6 server.
This regression has likely been introduced by 8a8955507af363c31297bbc5df79852db4ad39d6.
