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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This also makes x11_convert_to_vconsole() changed in the same way.
Then, their callers update Context if necessary.
No functional change, just preparation for later commits.
Also, rename get_battery_identifier() to siphash24_compress_device_sysattr().
This also makes any errors in sd_id128_get_machine() or id128_get_product()
ignored. For the machine ID, the failure should not be significant unless
the file stored in the discharge level is reused by another system, which
is quite unusual. For the product ID, if the firmware provides useless
ID (all zero or all 0xFF), then loading/storing the discharge rate
becomes completely broken, that should be avoided.
Note, now sysattrs are used instead of properties in uevent files, but
both provide the same information, hence no functionality should be
changed.
Before v252, HibernateDelaySec= specifies the maximum timespan that the
system in suspend state, and the system hibernate after the timespan.
However, after 96d662fa4c, the setting is
repurposed as the default interval to measure battery charge level and
estimate the battery discharging late. And if the system has enough
battery capacity, then the system will stay in suspend state and not
hibernate even if the time passed. See issue #25269.
To keep the backward compatibility, let's introduce another setting
SuspendEstimationSec= for controlling the interval to measure
battery charge level, and make HibernateDelaySec= work as of v251.
This also drops implementation details from the man page.
Fixes#25269.
On Arch both delv and dig pull in libnss_resolve:
```
$ grep resolve /etc/nsswitch.conf
hosts: mymachines resolve [!UNAVAIL=return] files myhostname dns
```
We also add the necessary deps for ukify to the mkosi configs.
CentOS Stream 8 is dropped from CI because its python version is too
old (3.6) to be able to run ukify.
This adds a tmpfiles.d/ snippet for LoadCredential= style credentials
directories in /etc/ and /run/.
This is done primarily to ensure that the access modes for the dirs are
set up properly, in the most restrictive ways. Specifically these are
set to 0000, so that CAP_DAC_OVERRIDE is necessary to enumerate and read
the credentials, and being UID=0 is not sufficient to do so.
This creates /etc/credstore/, but leaves /run/credstore/ absent if
missing, for now. Thinking is: the latter being non-persistent is
created by software usually, not manually by users, and hence more
likely right. But dunno, we might want to revisit this sooner or later.
This is ultimately an exercise to advertise the LoadCredential= concept
a bit, and do so in a reasonably secure way, underlining the safety of
the concept.
If we don't have CAP_NET_BIND_SERVICE, we won't be able to bind
the stub listener socket, so let's skip creating it and log a warning.
We do the same for the extra stubs if they're configured on privileged
ports.
If we're in a user namespace but not unsharing the network namespace,
we won't be able to bind any privileged ports even with
CAP_NET_BIND_SERVICE, so let's drop it from the retained capabilities
so services can condition themselves on that.
Let's pick up the boot ID early if unspecified, in
journal_file_append_entry(). This is symmetric to the fact that we
already pick up the monotonic timestamp in journal_file_append_entry()
if unspecified, and given that the monotonic clock is not too useful
without its boot ID it makes a lot of sense to pick them up at the same
time.
There are two relevant callers of journal_file_append_entry() right now:
journald (which leaves the boot ID unspecified) and journal-remote
(there are also some tests, but those don't matter too much). The former
calls it to store new entries in the journal file, the latter for
converting/processing/merging existing ones (where it passes along the
original boot ID). This new code hence only is relevant on the former,
and using the boot ID of the current system is the right choice for live
generated entries.
Note that this effectively changes little, since the lower-level
function journal_file_append_entry_internal() will copy boot ID stored
in the file header into all records if unspecified, and typically that's
the one of the local system. But strictly speaking this is not the right
thing to do, since we actually might end up appending to journal files
from previous boots. (The lower level function is indirectly used by
various tests, where the copying-from-header logic kinda makes sense
since they are detached from any live messages streaming in from the
host after all).
This is a follow-up for 1d8d483f59 and
makes the strict ordering by realtime clock within each journal file
optional, not mandatory. It then enables it for all journal files
written by journald, but leaves it off on others (for example those
written by journald-remote).
This relaxes the logic behind writing journal files to the status quo
ante for all cases where the journal files are not generated, but are
merged/processed/propagated. Typically when processing journal records
from many files ordering by realtime clock and monotonic clock are
contradictory, and cannot be universally guaranteed as the records are
interleaved. By enforcing strict rules we would thus end up generating
myriads of separate journal files, each with just a few records in them.
Hence, let's losen restrictions again, but continue to enforce them in
journald, i.e. when we original create the journal files locally.
Note that generally there's nothing really wring with having journal
files with non-monotonically ordered entries by realtime clock. Looking
for records will not be deterministic anymore, but that's inherent to a
realtime clock that jumps up and down. So you won't get the "only"
answer, but still *a* answer that is correct if you seek for a realtime
clock.
This also adds similar logic on the monotonic clock, which is also only
enabled when generating journal files locally. This should be harder to
trigger (as journald will generate the messages, and should run with a
stable boot id and monotonic clock), but let's better be safe than
sorry, and refuse on the lower layer what makes no sense, even if it's
unlikely the higher layer will ever generate records that aren't ordered
by their monotonic clock.
