Age | Commit message (Collapse) | Author |
|
We would only log a terse message when pid1 or systemd-journald crashed.
It seems better to reuse the normal code paths as much as possible,
with the following differences:
- if pid1 crashes, we cannot launch the helper, so we don't analyze the
coredump, just write it to file directly from the helper invoked by the
kernel;
- if journald crashes, we can produce the backtrace, but we don't log full
structured messages.
With comparison to previous code, advantages are:
- we go through most of the steps, so for example vacuuming is performed,
- we gather and log more data. In particular for journald and pid1 crashes we
generate a backtrace, and for pid1 crashes we record the metadata (fdinfo,
maps, etc.),
- coredumpctl shows pid1 crashes.
A disavantage (inefficiency) is that we gather metadata for journald crashes
which is then ignored because _TRANSPORT=kernel does not support structued
messages.
Messages for the systemd-journald "crash" have _TRANSPORT=kernel, and
_TRANSPORT=journal for the pid1 "crash".
Feb 26 16:27:55 systemd[1]: systemd-journald.service: Main process exited, code=dumped, status=11/SEGV
Feb 26 16:27:55 systemd[1]: systemd-journald.service: Unit entered failed state.
Feb 26 16:37:54 systemd-coredump[18801]: Process 18729 (systemd-journal) of user 0 dumped core.
Feb 26 16:37:54 systemd-coredump[18801]: Coredump diverted to /var/lib/systemd/coredump/core.systemd-journal.0.36c14bf3c6ce4c38914f441038990979.18729.1488145074000000.lz4
Feb 26 16:37:54 systemd-coredump[18801]: Stack trace of thread 18729:
Feb 26 16:37:54 systemd-coredump[18801]: #0 0x00007f46d6a06b8d fsync (libpthread.so.0)
Feb 26 16:37:54 systemd-coredump[18801]: #1 0x00007f46d71bfc47 journal_file_set_online (libsystemd-shared-233.so)
Feb 26 16:37:54 systemd-coredump[18801]: #2 0x00007f46d71c1c31 journal_file_append_object (libsystemd-shared-233.so)
Feb 26 16:37:54 systemd-coredump[18801]: #3 0x00007f46d71c3405 journal_file_append_data (libsystemd-shared-233.so)
Feb 26 16:37:54 systemd-coredump[18801]: #4 0x00007f46d71c4b7c journal_file_append_entry (libsystemd-shared-233.so)
Feb 26 16:37:54 systemd-coredump[18801]: #5 0x00005577688cf056 write_to_journal (systemd-journald)
Feb 26 16:37:54 systemd-coredump[18801]: #6 0x00005577688d2e98 dispatch_message_real (systemd-journald)
Feb 26 16:37:54 kernel: systemd-coredum: 9 output lines suppressed due to ratelimiting
Feb 26 16:37:54 systemd-journald[18810]: Journal started
Feb 26 16:50:59 systemd-coredump[19229]: Due to PID 1 having crashed coredump collection will now be turned off.
Feb 26 16:51:00 systemd[1]: Caught <SEGV>, dumped core as pid 19228.
Feb 26 16:51:00 systemd[1]: Freezing execution.
Feb 26 16:51:00 systemd-coredump[19229]: Process 19228 (systemd) of user 0 dumped core.
Stack trace of thread 19228:
#0 0x00007fab82075c47 kill (libc.so.6)
#1 0x000055fdf7c38b6b crash (systemd)
#2 0x00007fab824175c0 __restore_rt (libpthread.so.0)
#3 0x00007fab82148573 epoll_wait (libc.so.6)
#4 0x00007fab8366f84a sd_event_wait (libsystemd-shared-233.so)
#5 0x00007fab836701de sd_event_run (libsystemd-shared-233.so)
#6 0x000055fdf7c4a380 manager_loop (systemd)
#7 0x000055fdf7c402c2 main (systemd)
#8 0x00007fab82060401 __libc_start_main (libc.so.6)
#9 0x000055fdf7c3818a _start (systemd)
Poor machine ;)
|
|
Unit systemd-coredump@1-3854-0.service is failed/failed, not counting it.
TIME PID UID GID SIG COREFILE EXE
Fri 2017-02-24 11:11:00 EST 10002 1000 1000 6 none /home/zbyszek/src/systemd-work/.libs/lt-Sat 2017-02-25 00:49:32 EST 26921 0 0 11 error /usr/libexec/fprintd
Sat 2017-02-25 11:56:30 EST 30703 1000 1000 - - /usr/bin/python3.5
Sat 2017-02-25 13:16:54 EST 3275 1000 1000 11 present /usr/bin/bash
Sat 2017-02-25 17:25:40 EST 4049 1000 1000 11 truncated /usr/bin/bash
For info and gdb output, the filename is marked in red and "(truncated)" is
appended. (Red is necessary because the annotation is hard to see when running
under a pager.)
Fixed #3883.
|
|
A few times I have seen the hint unexpectedly. Add this so debug info
so it's easier to see what's happening.
...
Unit systemd-coredump@0-3119-0.service is failed/failed, not counting it.
Unit systemd-coredump@1-3854-0.service is activating/start-pre, counting it.
...
-- Notice: 1 systemd-coredump@.service unit is running, output may be incomplete.
|
|
We logged about this, but did not attach information directly to the log
entry. It *would* be nice to log the full untruncated size, but afaict, to do
this, we would have to read the full data from the kernel. Doing this just to
log that information seems a bit excessive, in particular when the limit could
be set quite low. So for now let's just add a boolean field.
|
|
Most of the fields in the context array come from the kernel (passed
through argv), but two are special: comm and exe. We allocate them
ourselves. We forgot to initialize context[CONTEXT_COMM] with the value
we allocated (introduced in 9aa820231414baa28e6bf02a033932cb69ff6b8b).
To simplify things, just set context[CONTEXT_COMM] and context[CONTEXT_EXE],
and free those two fields at the end.
Fixes #5442.
|
|
|
|
|
|
blkid error handling
|
|
coredumpctl: implement --since/--until (-S/-U) for info/list verbs
|
|
Revert "core: simplify cg_[all_]unified()" and more.
|
|
|
|
|
|
Implement --since/--until (-S/-U) in the same fashion as journalctl.
This lets the user filter the results a bit so it would be easier to
find relevant info in case there were many core dumps.
|
|
|
|
Let's just check the unified level, directly. There's really no value in
wrapping cg_unified_controllers() with this, i.e. potentially do string
comparison when there's no reason to.
Also, this makes the clal more alike cg_hybrid_unified().
|
|
We usually put the noun first, the verb (i.e. method) secont, for
example in cg_unified_flush(), let's follow the logic here...
|
|
cg_unified() is a bit generic a name, let's make clear that it checks
whether a specified controller is in unified mode.
|
|
We use our cgroup APIs in various contexts, including from our libraries
sd-login, sd-bus. As we don#t control those environments we can't rely
that the unified cgroup setup logic succeeds, and hence really shouldn't
assert on it.
This more or less reverts 415fc41ceaeada2e32639f24f134b1c248b9e43f.
|
|
Just a minor optimization.
|
|
Systemd controller on unified v2
|
|
Udev log revert
|
|
The cg_pid_get_path_shifted() is called twice during
server_dispatch_message(). We can get rid of the second by passing the
path to dispatch_message_real().
|
|
This reverts commit c22569eeeafa94cf510267071f5b75c4ab714e09.
Let's revert this for now, since it apparently doesn't fix the problem
at hand.
|
|
This reverts commit 00d1e0c9def4557c74f46cc2fe3a7ebc32a1dc8a.
|
|
This isn't terribly useful because /sys/fs/cgroup will usually be mounted.
But it at least allows checking if the values make sense in this case.
|
|
We should mount the hybrid hierarchy if the user disabled the unified
hierarchy on the kernel command line.
|
|
Added hwdb rule for E5570 laptop (PointingStick)
|
|
The Python format was added in d489071fb3.
|
|
/sys/fs/cgroups/unified on unified
If we encounter an error in proc cmdline parsing, just treat that as permanent,
i.e. the same as if the option was not specified. Realistically, it is better
to use the same condition for all related mounts, then to have e.g.
/sys/fs/cgroup mounted and /sys/fs/cgroup/unified not. If we find something is
mounted and base our answer on that, cache that result too.
Fix the conditions so that if "unified" is used, make sure any "hybrid" mounts
are not mounted.
|
|
networkd: Do not set config to NULL immediately.
|
|
This updates the man page for the changes introduced in 1d84ad944520fc3e062ef518c4db4e1d3a1866af.
"=" is kep if the option is predominantly used with an argument, and dropped
otherwise.
v2:
- update also description of log_color
- drop '=' in all cases where it is optional
(previous rule of dropping it only in some cases was just too arbitrary.)
|
|
Fixes #4827.
v2:
- update for the inverted interpration of systemd.legacy_systemd_cgroup_controller
|
|
We need this to gracefully support older or strangely configured kernels.
v2:
- do not install a callback handler, just embed the right conditions into
cg_is_*_wanted()
v3:
- fix bug in cg_is_legacy_wanted()
|
|
Less typing and doesn't make the table so incredibly wide.
|
|
It is expected that general-purpose distributions might want to override this.
This commit is made separate from grandparent to make it easy to revert if
needed.
v2:
- use hybrid as the default
(We tested that the default of unified seems boot correctly everywhere and behave
correctly in general, but it is incompatible with docker/lxc and probably some
other tools, so for now we default to hybrid. The new "hybrid" mode should work
be OK for those tools.)
Fixes #4669.
|
|
Trackpoint sensivity is very high by default
https://bugs.freedesktop.org/show_bug.cgi?id=99860
|
|
We not looking for hashmap_put return error code.
|
|
fd45e52 sets
n to NULL which leads to crash.
fixes: #5418
|
|
fixes: #5419
|
|
test-env-util: fix typo leading to memleak
|
|
Apparently if people are adventurous enought to run Go programs in udev
rules they might run into problems with MemoryDenyWriteExecute=.
I am pretty sure the best way out is for the toolchain generating
programs incompatible with W^X to be fixed, but this still deserves
documentation.
This was forgotten for the 232 release, hence add it now, retroactively.
See: #5400
|
|
As per commit 25e773e "udev: switch to systemd logging functions"
Now log_set_max_level() in udev_new() overwites system wide log level.
Propagate the udev.conf setting to log_set_max_level()
only if udev_new() is called from within udevd or one of its helpers.
Introduce a UDEV_PROPAGATE_LOG macro that we set with -D on
the gcc command line for all udev binaries we build, but not
for any others. The log_set_max_level() call is guarded by an
ifdef check for that macro, so that it only effects the various
udev binaries.
closes: #4525
|
|
From: #5393
|
|
Various pre v233 fixes.
|
|
The code that calls this function doesn't care, but it looks bad.
|
|
|
|
This reverts commit 18f71a3c8174774c5386c4aba94d54f3b5c36a84.
According to @keszybz we don't need this anymore, hence drop it:
https://github.com/systemd/systemd/pull/5131/commits/18f71a3c8174774c5386c4aba94d54f3b5c36a84#r102232368
|
|
Fixes: #5401
|
|
MountAPIVFS=
See: #5384
|
|
If the snippet aleady exists, don't do anything, as the file was already
installed then.
(This also reworks the code to create the file atomically)
Fixes: #5396
|