[systemd-bugs] [Bug 66664] journalctl boot reporting inconsistent

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=66664

--- Comment #10 from hortplumber at gmail.com ---
Created attachment 82390
  --> https://bugs.freedesktop.org/attachment.cgi?id=82390&action=edit
Diagnostic output from log analysis tool, 20130712

Not having heard anything further on this since last week, I tried 

        [service]
        Nice=-10

in the nice.conf file. This seems to avoid the "Assignment outside of section"
complaint.  Not sure if "Service" was your intented section, but no other
choice seemed to make much sense.

The results are shown in the attachment. Summary: No observable qualitative
difference from the earlier results posted in Comments #7 and #8 and the
original posting on the Arch forum: The distribution of the number of dropped
messages is still roughly bimodal, with the "better" cases dropping roughly
5% of messages from every boot sequence, and the "worse" cases dropping
around 30%.

I also wrote a tool to do the journalctl log analysis, i.e. identify missing
messages among a set of boot cycles, to avoid the tedious work of hand-
comparsion.  So if there are further experiments with process prioritization
or buffering (or whatever else) you might like to try, the results of those
experiments can now be obtained fairly quickly.

That tool was used to generate the results in the attachment. In that output,
"MOI's" means messages of interest, presently comprising only the "Starting"
and "Started" messages generated by systemd (because they are syntactically
consistent across boot sequences).  Even though this is just a small subset
of the total messages generated during a boot sequence, it seems sufficient
to demonstrate the problem, i.e. that journald presently has some serious
reliability issues. Needless to say, diagnosis of boot problems is made
significantly more complicated when boot-time messages are frequently and
silently being dropped from the logs.

I have some past experience dealing with issues of this sort, i.e. diagnostic
logging processes competing for resources (realtime and buffers) to keep up
with bursty message generation. If you're interested perhaps we can discuss,
either here or on the systemd ML.

Let me know if you need any more info or example results.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-bugs/attachments/20130713/a3d91c7e/attachment-0001.html>