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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We would return a real error sometimes from the callback, and FTW_STOP other
times. Because of FTW_ACTIONRETVAL, everything except FTW_STOP would be
ignored. I don't think using FTW_ACTIONRETVAL is useful.
nftw() can only be used meaningfully with errno. Even if we return a proper
value ourselves from the callback, it will be propagated as a return value from
nftw(), but there is no way to distinguish this from a value generated by
nftw() itself, which is -1/-EPERM on error. So let's set errno ourselves so the
caller can at least look at that.
The code still ignores all errors.
When seccomp_restrict_archs is called, architectures that are blocked
are replaced by the SECCOMP_LOCAL_ARCH_BLOCKED marker so that they are
not disabled again and filters are not installed for them.
This can make some service that use SystemCallArchitecture= and
SystemCallFilter= start faster.
A comment indicates the start of the new contents of the override file,
and another indicates that lines following it will be discarded once
editing is finished.
The contents of the unit file and drop-ins are listed out after this
last marker.
Adds WRITE_STRING_FILE_TRUNCATE to set O_TRUNC when opening a file.
Thanks to cgzones for providing the required SELinux function calls.
Co-authored-by: Christian Göttsche <cgzones@googlemail.com>
This updates the "systemd-analyze syscall-filter" command to show a
special section of syscalls that are included in @known but in no other
group. Typically this should show syscalls we either should add to any
of the existing groups or where we unsure were they best fit in.
Right now, it mostly shows arch-specific compat syscalls, we probably
should move "@obsolete". This patch doesn't add thta however.
By settings AI_ADDRCONFIG in hints we cannot for example resolve "localhost"
when the local machine only has a loopback interface. This seems like an
unnecessary restriction, drop it.
Inspired by https://bugzilla.redhat.com/show_bug.cgi?id=1839007.
Similarly to "setup" vs. "set up", "fallback" is a noun, and "fall back"
is the verb. (This is pretty clear when we construct a sentence in the
present continous: "we are falling back" not "we are fallbacking").
The docs for XZ don't seem to answer this at first blush, or maybe
I'm looking in the wrong place... This might make XZ less terribly slow,
but on the other hand, almost nobody uses it, so it doesn't matter that
much.
We'd start writing an entry line, then another one, then another one,
and then output the rest of the first one, and then some other random
stuff, and the rest of some other lines... Results were ...eh... random.
Let's define a helper to avoid some of the copy&paste madness, and separate
blocks that output a single line with /**********************************/.
This rework doesn't change what data is written, it only tries to fix the
format of the output. The fact that some entries only write data from
link->network, and some from either link->network or link, some stuff only
for dhpc4 leases while some for both dhpc4 and dhcp6, etc, looks rather
suspicious too, but I didn't touch this.
We would print the error sometimes to stdout and sometimes to stderr. It *is*
useful to get the message if one of the names is not found on the bus to
stdout, so that this shows out in the pager. So let's do verification of args
early to catch invalid arguments, and then if we receive an error over the bus
(most likely that the name is not activatable), let's print to stdout so it
gets paged. E.g. 'busctl tree org.freedesktop.systemd1 org.freedesktop.systemd2'
gives a nicely usable output.
Debian Policy encourages to preserve timestamps whenever possible in the
tarballs, thus stable release updates of systemd usually do not bump NEWS file
timestamp. And thus time-epoch remains the same for the lifetime of a release.
It would be better, if each new stable release rebuild of systemd would bump
the time epoch a bit. But at the same time remain
reproducible. SOURCE_DATE_EPOCH is an environmnet variable defined for this
purpose. Thus if available, prefer that, instead of the NEWS file modification
time.
For example, on Debian/Ubuntu under the reproducible builds the
SOURCE_DATE_EPOCH is set to the timestamp from the packaging metadata, thus it
is incremented on every new stable release update, whilst preserving
reproducible builds capability.
Reference: https://reproducible-builds.org/docs/timestamps/
It's not that I think that "hostname" is vastly superior to "host name". Quite
the opposite — the difference is small, and in some context the two-word version
does fit better. But in the tree, there are ~200 occurrences of the first, and
>1600 of the other, and consistent spelling is more important than any particular
spelling choice.
As usual, the formatting was fixed and various obvious updates
were done, but nothing major.
I removed documentation of snapshots and related methods though.
systemd.show-status=error is useful for the case where people care about errors
only.
If people want to have a quiet boot, they most likely don't want to see all
status output even if there is a delay in boot, so make "quiet" imply
systemd.show-status=error instead of systemd.show-status=auto.
Fixes#14976.
Ideally, we would want to report this over back over dbus. But that is pretty hard,
because the unitfile parsing logic doesn't provide any feedback.
systemd-analyze verify also doesn't notice the issue, because it doesn't look
at the [Install] section at all. Let's print a message in the logs at least.
For all units that aren't timers, if it is activated by another unit,
add the triggering unit under the "TriggeredBy:" header. If a unit can
trigger other units, print the units it triggers other the "Triggers:"
header.
If logging disappears issues are hard to debug, hence let's give
journald a slight edge over other services when the OOM killer hits.
Here are the special adjustments we now make:
systemd-coredump@.service.in OOMScoreAdjust=500
systemd-journald.service.in OOMScoreAdjust=-250
systemd-udevd.service.in OOMScoreAdjust=-1000
(i.e. the coredump processing is made more likely to be killed on OOM,
and udevd and journald are less likely to be killed)
In situations where hibernation is requested but resume= and
resume_offset= kernel parameters are not configured, systemd
will attempt to locate a suitable swap location by inspecting
/proc/swaps. This change will use the first suitable swap with
the highest configured priority.
Now all short-*, verbose, with-unit modes are handled. cat, export, json-* are
not, but those are usually used for post-processing, so I don't think it'd be
useful there.
Use hibernation configuration as defined in
/sys/power/resume and /sys/power/resume_offset
if present before inspecting /proc/swaps and
attempting to calculate swapfile offset
The console tty is now allocated from within the container so it's not
necessary anymore to allocate it from the host and bind mount the pty slave
into the container. The pty master is sent to the host.
/dev/console is now a symlink pointing to the pty slave.
This might also be less confusing for applications running inside the container
and the overall result looks cleaner (we don't need to apply manually the
passed selinux context, if any, to the allocated pty for instance).
refactor to use timerfd in place of rtc wakealarm
confirm CLOCK_BOOTTIME_ALARM support in can_s2h
Remove CLOCK_BOOTTIME_ALARM task from TODO
remove unnecessary check on clock_supported return
This should PID collisions a tiny bit less likely, and thus improve
security and robustness.
2^22 isn't particularly a lot either, but it's the current kernel
limitation.
Bumping this limit was suggested by Linus himself:
https://lwn.net/ml/linux-kernel/CAHk-=wiZ40LVjnXSi9iHLE_-ZBsWFGCgdmNiYZUXn1-V5YBg2g@mail.gmail.com/
Let's experiment with this in systemd upstream first. Downstreams and
users can after all still comment this easily.
Besides compat concern the most often heard issue with such high PIDs is
usability, since they are potentially hard to type. I am not entirely sure though
whether 4194304 (as largest new PID) is that much worse to type or to
copy than 65563.
This should also simplify management of per system tasks limits as by
this move the sysctl /proc/sys/kernel/threads-max becomes the primary
knob to control how many processes to have in parallel.
Example output:
title: Fedora 30 (Workstation Edition) (5.0.5-300.fc30.x86_64)
id: 08a5690a2eed47cf92ac0a5d2e3cf6b0-5.0.5-bad-300.fc30.x86_64
source: /boot/efi/loader/entries/08a5690a2eed47cf92ac0a5d2e3cf6b0-5.0.5-bad-300.fc30.x86_64.conf
version: 5.0.5-300.fc30.x86_64
machine-id: 08a5690a2eed47cf92ac0a5d2e3cf6b0
linux: /08a5690a2eed47cf92ac0a/5.0.5-300.fc30.x86_64/linux (No such file or directory)
initrd: /08a5690a2eed47cf92ac0a/5.0.5-300.fc30.x86_64/initrd (No such file or directory)
/08a5690a2eed47cf92ac0a/5.0.5-300.fc30.x86_64/initrd2 (No such file or directory)
options: ...
I think this is more useful (because it's easy to stick the path into an editor command
when one wants to change the options or inspect the files), and more self-explanatory.
Example output:
title: Fedora 30 (Workstation Edition) (4.20.16-200.fc29.x86_64)
id: 08a5690a2eed47cf92ac0a5d2e3cf6b0-4.20.16-200.fc29.x86_64
source: /boot/efi/loader/entries/08a5690a2eed47cf92ac0a5d2e3cf6b0-4.20.16-200.fc29.x86_64.conf
version: 4.20.16-200.fc29.x86_64
...
title: Fedora 30 (Workstation Edition)
id: fedora-30
source: /boot/efi/EFI/Linux/linux-5.0.5-300.fc30.x86_64-08a5690a2eed47cf92ac0a5d2e3cf6b0.efi
linux: EFI/Linux/linux-5.0.5-300.fc30.x86_64-08a5690a2eed47cf92ac0a5d2e3cf6b0.efi
...
title: Reboot Into Firmware Interface
id: auto-reboot-to-firmware-setup
source: /sys/firmware/efi/efivars/LoaderEntries-4a67b082-0a4c-41cf-b6c7-440b29bb8c4f
