Mailinglist Archive: opensuse-bugs (4258 mails)

< Previous Next >
[Bug 1021307] journald frequently crashes with coredump of the journal daemon itself
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Mon, 30 Jan 2017 19:41:35 +0000
  • Message-id: <>

Mel Gorman <mgorman@xxxxxxxx> changed:

What |Removed |Added
Flags|needinfo?(mgorman@xxxxxxxx) |

--- Comment #10 from Mel Gorman <mgorman@xxxxxxxx> ---
(In reply to Franck Bui from comment #9)
@Mel, do you have an idea how this could be traced without interfering with
the timings of journald ?

sudo perf -a trace -e fdatasync,fsync,msync,sync,sync_file_range,syncfs

While that's running it'll track all sync-related syscalls globally. If you
want to target journald, you'll need to specify the pid with -p. Hit ctrl-c
when you're done and there should be a breakdown of the sync calls.

Crude example of tracing like this

# dd if=/dev/zero of=zerofile ibs=1048576 count=500;
sudo perf trace -e fdatasync,fsync,msync,sync,sync_file_range,syncfs sync;
rm zerofile
500+0 records in
1024000+0 records out
524288000 bytes (524 MB, 500 MiB) copied, 0.772471 s, 679 MB/s
1023.708 (1023.708 ms): sync/24234 sync( ) = 0

That is showing that the sync command after an async dd took 1023.708 ms to
complete. You can monitor indefinitely by specifying no command or record for a
duration by running "sleep X" where X is the number of seconds you want to
record data for.

It might be possible by using perf or do you think strace should be enough
for this case ?

perf can do it with lower interference. If there are a high number of sync
calls then you may need to increase the mmap space with -m to avoid lost
events. The same can be achieved with strace but you specified that the
interference with journald be minimised and strace is very heavy

You are receiving this mail because:
You are on the CC list for the bug.
< Previous Next >