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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Slice/ControlGroup only really makes sense for unit types which actually
have cgroups attached to them, hence move them out of the generic Unit
interface and into the specific unit type interfaces.
These fields will continue to be part of Unit though, simply because
things are a log easier that way. However, regardless how this looks
internally we should keep things clean and independent of the specific
implementation of the inside.
"Scope" units are very much like service units, however with the
difference that they are created from pre-existing processes, rather
than processes that systemd itself forks off. This means they are
generated programmatically via the bus API as transient units rather
than from static configuration read from disk. Also, they do not provide
execution-time parameters, as at the time systemd adds the processes to
the scope unit they already exist and the parameters cannot be applied
anymore.
The primary benefit of this new unit type is to create arbitrary cgroups
for worker-processes forked off an existing service.
This commit also adds a a new mode to "systemd-run" to run the specified
processes in a scope rather then a transient service.
Before: libsystemd-daemonpkg-config(1)
After: libsystemd-daemon pkg-config(1)
This fix is more complicated than it should be due to the consecutive
XML elements separated by collapsible whitespace.
Merging the lines and separating the XML elements with an en space or a
non-breaking space is the only solution that results in one, and only
one, space being inserted between them when testing. An em space results
in two spaces being inserted.
Fixed build on debian wheezy:
./.libs/libudev.so: undefined reference to `cg_create'
Appears to have no influence on the resulting binaries and
libraries. Cf. b5fafdf63f.
Transient units can be created via the bus API. They are configured via
the method call parameters rather than on-disk files. They are subject
to normal GC. Transient units currently may only be created for
services (however, we will extend this), and currently only ExecStart=
and the cgroup parameters can be configured (also to be extended).
Transient units require a unique name, that previously had no
configuration file on disk.
A tool systemd-run is added that makes use of this functionality to run
arbitrary command lines as transient services:
$ systemd-run /bin/ping www.heise.de
Will cause systemd to create a new transient service and run ping in it.
This introduces two bus calls to make runtime changes to selected bus
properties, optionally with persistence.
This currently hooks this up only for three cgroup atributes, but this
brings the infrastructure to add more changable attributes.
This allows setting multiple attributes at once, and takes an array
rather than a dictionary of properties, in order to implement simple
resetting of lists using the same approach as when they are sourced from
unit files. This means, that list properties are appended to by this
call, unless they are first reset via assigning the empty list.
Replace the very generic cgroup hookup with a much simpler one. With
this change only the high-level cgroup settings remain, the ability to
set arbitrary cgroup attributes is removed, so is support for adding
units to arbitrary cgroup controllers or setting arbitrary paths for
them (especially paths that are different for the various controllers).
This also introduces a new -.slice root slice, that is the parent of
system.slice and friends. This enables easy admin configuration of
root-level cgrouo properties.
This replaces DeviceDeny= by DevicePolicy=, and implicitly adds in
/dev/null, /dev/zero and friends if DeviceAllow= is used (unless this is
turned off by DevicePolicy=).
When looking at verbose output, additional "work" is required to
pick out the interesting MESSAGE= lines from all the fields.
Also, show long fields in full in verbose output mode when
OUTPUT_FULL_WIDTH is specified.
When manpages are displayed on a terminal, <literal>s are indistinguishable
from surrounding text. Add quotes everywhere, remove duplicate quotes,
and tweak a few lists for consistent formatting.
https://bugzilla.redhat.com/show_bug.cgi?id=874631
Corrupted empty files are relatively common. I think they are created
when a coredump for a user who never logged anything before is
attempted to be written, but the write does not succeed because the
coredump is too big, but there are probably other ways to create
those, especially if the machine crashes at the right time.
Non-corrupted empty files can also happen, e.g. if a journal file is
opened, but nothing is ever successfully written to it and it is
rotated because of MaxFileSec=. Either way, each "empty" journal file
costs around 3 MB, and there's little point in keeping them around.
Reporting of the free space was bogus, since the remaining space
was compared with the maximum allowed, instead of the current
use being compared with the maximum allowed. Simplify and fix
by reporting limits directly at the point where they are calculated.
Also, assign a UUID to the message.
Sometimes an entry is not successfully written, and we end up with
data items which are "unlinked", not connected to, and not used by any
entry. This will usually happen when we write to write a core dump,
and the initial small data fields are written successfully, but
the huge COREDUMP= field is not written. This situation is hard
to avoid, but the results are mostly harmless. Thus only warn about
unused data items.
Also, be more verbose about why journal files failed verification.
This should help diagnose journal failure modes without resorting
to a hexadecimal editor.
https://bugs.freedesktop.org/show_bug.cgi?id=65235 (esp. see
system.journal attached to the bug report).
Before we only checked the MESSAGE_ID and COREDUMP_UNIT.
Those are both user-controlled fields.
For COREDUMP_USER_UNIT, relax the rules a bit, and also
allow messages from _UID=0.
