Description of problem: The summary kinda says it all. It would be extremely useful to be able to run something like... "journalctl -ktrace" that would dump all existing entries like this from the journal kernel: ------------[ cut here ]------------ kernel: WARNING: at drivers/gpu/drm/i915/intel_pm.c:4355 kernel: Hardware name: 4180WPD kernel: MMIO read or write has been dropped 3 kernel: Modules linked in: fuse ip6table_filter ip6_tables ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf kernel: sdhci_pci sdhci firewire_ohci drm mmc_core firewire_core crc_itu_t i2c_core wmi video kernel: Pid: 1781, comm: kworker/u:0 Tainted: G W 3.9.6-200.fc18.x86_64 #1 kernel: Call Trace: kernel: [<ffffffff8105ef85>] warn_slowpath_common+0x75/0xa0 kernel: [<ffffffff8105f066>] warn_slowpath_fmt+0x46/0x50kernel: [<ffffffffa013e131>] gen6_gt_check_fifodbg+0x41/0x60 [i915] kernel: [<ffffffffa013e174>] __gen6_gt_force_wake_put+0x24/0x30 [i915] kernel: [<ffffffffa013e217>] gen6_gt_force_wake_put+0x37/0x50 [i915] kernel: [<ffffffffa0142b52>] init_ring_common+0x222/0x3b0 [i915] kernel: [<ffffffffa0102748>] ? i915_gem_reset_fences+0x78/0xf0 [i915] kernel: [<ffffffffa01433d4>] init_render_ring+0x34/0x390 [i915] kernel: [<ffffffffa00f1aa2>] i915_reset+0xf2/0x1a0 [i915] kernel: [<ffffffffa00f6fbd>] i915_error_work_func+0xcd/0x160 [i915] kernel: [<ffffffff8107b623>] process_one_work+0x173/0x3c0 kernel: [<ffffffff8107cf4f>] worker_thread+0x10f/0x390 kernel: [<ffffffff8107ce40>] ? busy_worker_rebind_fn+0xb0/0xb0 kernel: [<ffffffff81082af0>] kthread+0xc0/0xd0 kernel: [<ffffffff81090168>] ? finish_task_switch+0x48/0xe0 kernel: [<ffffffff81010000>] ? ftrace_define_fields_xen_mc_flush+0x20/0xb0 kernel: [<ffffffff81082a30>] ? kthread_create_on_node+0x120/0x120 kernel: [<ffffffff8166a52c>] ret_from_fork+0x7c/0xb0 kernel: [<ffffffff81082a30>] ? kthread_create_on_node+0x120/0x120 kernel: ---[ end trace 2f46923b1afdabcc ]--- ( yes I have been going through several of drm/intel relate crashes which started with 3.9.x and are still present with 3.10.x like this hence the suggestion ) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Try this ;) ------------[ cut here ]------------ #!/usr/bin/python from __future__ import print_function import re from systemd import journal j = journal.Reader() first = True while True: j.add_match('_TRANSPORT=kernel') j.add_match(MESSAGE='------------[ cut here ]------------') line = j.get_next() if not line: break j.flush_matches() j.add_match('_TRANSPORT=kernel') if first: first = False else: print() while line: print(line['MESSAGE']) if re.match(r'---\[ end trace [a-z0-9]+ \]---', line['MESSAGE']): break line = j.get_next() ---[ end trace deadbeef ]--- If generally useful, we could make this into a proper script and stick it in systemd. What kind of functionality would you need? Last trace? Last n traces? Traces from this boot? Save to a file? Postprocess somehow?
Well the general idea here is to make it super easy to report those traces so I would assume only uniq traces would be useful and save to file and potentially flush entries or somehow flag it having being saved ( to prevent report duplicates by reporters themselves ) from journal to attach to bug report. I would assume tools like ABRT would take advantage of this or use this somehow as well.
Nah, this is nothing we ever want to do in the journal itself: detect messages by their text contents. I can see the usefulness for this, but people should user message_ids for that, nothing else. Of course it's difficult convincing kernel folks about that, but I still don't think we should work around that.
Also note that abrt does something like this anyway, afaik, to process the messages further. I don't think we need to do this in journald itself, as it couldn't do anything with that data anyway, but abrt can.