<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED --- - journalctl boot reporting inconsistent" href="https://bugs.freedesktop.org/show_bug.cgi?id=66664#c10">Comment # 10</a> on <a class="bz_bug_link bz_status_ASSIGNED " title="ASSIGNED --- - journalctl boot reporting inconsistent" href="https://bugs.freedesktop.org/show_bug.cgi?id=66664">bug 66664</a> from <a class="email" href="mailto:hortplumber@gmail.com" title="hortplumber@gmail.com">hortplumber@gmail.com</a> <pre>Created <a href="attachment.cgi?id=82390" name="attach_82390" title="Diagnostic output from log analysis tool, 20130712">attachment 82390</a> <a href="attachment.cgi?id=82390&action=edit" title="Diagnostic output from log analysis tool, 20130712">[details]</a> 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>