| Age | Commit message (Collapse) | Author |
|---|
|
% build/journalctl help
Assertion 'match_is_valid(data, size)' failed at ../src/journal/sd-journal.c:227, function sd_journal_add_match(). Ignoring.
Callers cannot be expect to check all arguments always.
|
|
journalctl help output might run off the screen, so be consistent
as other systemd tools do and pipe it into a pager.
|
|
Also split into paragraphs for easier reading and make a few minor
corrections.
|
|
|
|
containers)
|
|
This is a fairly useless thing to do but it makes the compilers
and analyzers shut up about the use of mktemp.
|
|
to queue/starter
|
|
|
|
|
|
|
|
assert_return()
These are not programming errors, so they shouldn't use assert_return()
|
|
kdbus fortunately exposes the container's busses in the host fs, hence
we can access it directly instead of doing the namespacing dance.
|
|
In addition to the same spot within every 1min, every 1s, every 250s
|
|
we close it
|
|
We don't run the collector in the container either, hence we don't need
to stop it either.
|
|
log message
|
|
show messages from host too
|
|
generating them fresh for each log entry
|
|
connection
|
|
This adds the new library call sd_journal_open_container() and a new
"-M" switch to journalctl. Particular care is taken that journalctl's
"-b" switch resolves to the current boot ID of the container, not the
host.
|
|
|
|
|
|
udev rules
https://bugzilla.redhat.com/show_bug.cgi?id=1026860
|
|
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.
|
|
event source
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 f7e2bd5a8070ba86cba6bcbf7d1c9a8173d846d4.
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 e775289d56ace2f8d23e62ed79316d71332d6d05.
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.
|
