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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Adds a new call sd_event_set_watchdog() that can be used to hook up the
event loop with the watchdog supervision logic of systemd. If enabled
and $WATCHDOG_USEC is set the event loop will ping the invoking systemd
daemon right after coming back from epoll_wait() but not more often than
$WATCHDOG_USEC/4. The epoll_wait() will sleep no longer than
$WATCHDOG_USEC/4*3, to make sure the service manager is called in time.
This means that setting WatchdogSec= in a .service file and calling
sd_event_set_watchdog() in your daemon is enough to hook it up with the
watchdog logic.
That way the even source callback is run with the zombie process still
around so that it can access /proc/$PID/ and similar, and so that it can
be sure that the PID has not been reused yet.
> [simon@troela server]$ /usr/lib/systemd/systemd-activate -l 9000 main.js
> Assertion 'fd == 3 + count' failed at src/activate/activate.c:115,
> function open_sockets(). Aborting.
> Aborted (core dumped)
> after a bit debuging i found the problem:
> slim appears to leak an fd into all of its children:
> stat /proc/14004/fd/3 (14004 is the pid a random process in my session)
> File: '/proc/14004/fd/3' -> '/var/log/slim.log'
systemd-activate should be robust against the shell (or anything else) leaking
descriptors. Now everything except stdin/stdout/stderr and received sockets
will be closed.
It was calling cfmakeraw(3) on the properties for STDIN_FILENO; cfmakeraw
sets both input and output properties. If (and only if) stdin and stdout
are the same device is this correct. Otherwise, we must change only the
input properties of stdin, and only the output properties of stdout.
SetProperties has signature "ba(sv)", but the bus_unit_set_properties()
helper already does a enter_container('a', "sv") so we have to skip it in
bus_unit_method_set_properties().
The static analyzer scan-build had a few issues with analysing
parts of systemd.
gpt-auto-generator.c:
scan-build could not find blkid.h. Whether it should be blkid.h or
blkid/blkid.h seems to depend on the version used. We already use
blkid/blkid.h in udev-builtin-blkid.c so it seems safe to use that
here too.
Makefile.am:
Moved some -D's from CFLAGS to CPPFLAGS. I also simplified them a
bit and got rid of a left over DBUS_CFLAGS.
test-cgroup-mask.c/test-sched-prio.c
A variable was added to store the replaced TEST_DIR. When wrapped
in an assert_se TEST_DIR was not replaced in the logged error.
While not an issue introduced in this patch we might as well fix
it up while we are here.
We support unreffing NULL pointers just fine and we shouldn't pay the
_unlikely_() price for it, not get a debug message if we do, hence let's
not use assert_return() here.
This reverts commit f7e2bd5a80.
Most of these checks are not programming errors, but happen during
normal runtime. For example bus_kernel_pop_memfd() is called all the
time on non-kdbus systems and is supposed to quickly fail if kdbus is
not available. However, assert_return() makes this failure
expensive, and hence has no place here. With the most recent change to
assert_return() it will even log a debug message, which should never
happen here.
This reverts commit e775289d56.
We really should let the dependency logic add jobs for dependencies here
rather than manually adding in jobs, overtaping the real problem.
When this flag is set then its member will not be shown in the
introspection data. Also, properties with this flag set will not be
included in GetAll() responses.
Introduces a new concept of "trusted" vs. "untrusted" busses. For the
latter libsystemd-bus will automatically do per-method access control,
for the former all access is automatically granted. Per-method access
control is encoded in the vtables: by default all methods are only
accessible to privileged clients. If the SD_BUS_VTABLE_UNPRIVILEGED flag
is set for a method it is accessible to unprivileged clients too. By
default whether a client is privileged is determined via checking for
its CAP_SYS_ADMIN capability, but this can be altered via the
SD_BUS_VTABLE_CAPABILITY() macro that can be ORed into the flags field
of the method.
Writable properties are also subject to SD_BUS_VTABLE_UNPRIVILEGED and
SD_BUS_VTABLE_CAPABILITY() for controlling write access to them. Note
however that read access is unrestricted, as PropertiesChanged messages
might send out the values anyway as an unrestricted broadcast.
By default the system bus is set to "untrusted" and the user bus is
"trusted" since per-method access control on the latter is unnecessary.
On dbus1 busses we check the UID of the caller rather than the
configured capability since the capability cannot be determined without
race. On kdbus the capability is checked if possible from the attached
meta-data of a message and otherwise queried from the sending peer.
This also decorates the vtables of the various daemons we ship with
these flags.
In the time it takes to process incoming log messages, the process we
are logging details for may exit. This means the cgroup data is no
longer available from '/proc'. Unfortunately, the way the code was
structured before, we never log _SYSTEMD_UNIT if we don't have this
cgroup information.
Add an else if case that allows the passed in unit_id to be logged even
if we couldn't capture cgroup information. This ensures a command like
`journalctl -u run-XXX` will return all log messages from a oneshot
process.
kbd-model-map was generated from system-config-keyboard's keyboard_models.py.
Several of the kbd layouts referred in that file do not exist and, so far as I
can tell, never did. I believe these entries existed simply to provide the xkb
configuration information for those layouts, and there never were matching kbd
entries; the kbd names were entirely notional, to satisfy the need for some
entry or other in that field.
For systemd, the only function of kbd-model-map is to 'match' kbd and xkb
configurations, so it does not make any sense to maintain entries for cases
where only one or the other exists in this context.
