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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
a70581ffb5 added ExecRuntime.ipcns_storage_socket[], and
serialization in exec_runtime_serialize(), and deserialization in exec_runtime_deserialize_one(),
but also deserialization in exec_runtime_deserialize_compat(). exec_runtime_deserialize_compat()
is for deserializating ExecRuntime when it was serialized as part of the unit before
e8a565cb66. There was never any code which would serialize
ExecRuntime.ipcns_storage_socket[] this way, so the deserialization attempts are pointless.
All unit types can be serialized. This function was really checking whether the
unit type has custom serialization/deserialization code. But we don't need a
function for this.
Also, the check that both .serialize() and .deserialize_item() are defined is
better written as an assert. Not we have a function which would skip
serialization/deserializaton for the unit if we forgot to set either of the
fields.
Apparently people use such large key files. Specifically, people used 4M
key files, and we lowered the limit from 4M to 4M-1 back in 248.
This raises the limit to 64M for read_full_file() to avoid these
specific issues and give some non-trivial room beyond the 4M files seen
IRL.
Note that that a 64M allocation in glibc is always immediately done via
mmap(), and is thus a lot slower than shorter allocations. This means
read_virtual_file() becomes ridiculously slow if we'd use the large
limit, since we use it all the time for reading /proc and /sys metadata,
and read_virtual_file() typically allocates the full size with malloc()
in advance. In fact it becomes so slow, that test-process-util kept
timing out on me all the time, once I blindly raised the limit.
This patch hence introduces two distinct limits for read_full_file() and
read_virtual_file(): the former is much larger than the latter and the
latter remains where it is. This is safe since the former uses an
exponentially growing realloc() loop while the latter uses the
aforementioend ahead-of-time full limit allocation.
Fixes: #19193
When we have a unit which cannot be enabled:
# foo@.service:
...
[Install]
WantedBy=foo.target # there is no instance, so we don't know what to enable
we should throw an error when invoked directly with 'enable', but
not when doing 'preset' or 'preset-all'.
Fixes#19856.
Instead of ordering non-pending before pending we should order
"non-pending OR ratelimited" before "pending AND not-ratelimited".
This fixes a bug where ratelimited events were ordered at the end of the
priority queue and could be stuck there for an indeterminate amount of
time.
Since those workarounds have been added, work has been done to tighten
up log_*() return values. Seems we get no warning with
gcc-11.1.1-1.fc34.x86_64 and -O0/-O2.
$ systemctl enable --root=/ serial-getty@.service
Failed to enable unit, unit getty.target is a non-template unit.
↓
Failed to enable serial-getty@.service, destination unit getty.target is a non-template unit.
This had some purpose back in the day, but right now I cannot see what
difference this makes. It's hard to keep the list of all possible errors up to
date. So let's remove this, hopefully nothing breaks.
It's hard to trigger the failure to exit the rate limit state in
isolation as it needs multiple event sources in order to show that it
gets stuck in the queue. Hence why this is an extended test.
There is no reason to tie the two together: in principle we may have
in the future a unit type which does not define .serialize/.deserialize_item,
but we would still want to call the compat deserialization code for it.
When suppressing duplicate fields between files we so far tried to reuse
the already known hash value of the data fields between files. This was
fine as long as we used the same hash function everywhere. However,
since addition of the keyed hash feature for journal files this doesn't
work anymore, since the hashes will be different for different files.
Fixes: #19172
