[systemd-bugs] [Bug 76935] Do not parse "debug" command line parameter

[bugzilla-daemon at freedesktop.org]

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

Kay Sievers <kay at vrfy.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |NOTABUG

--- Comment #2 from Kay Sievers <kay at vrfy.org> ---
(In reply to comment #0)
> Supplying "debug" on the kernel command line gets parsed by systemd. If
> a random assertion in it fires
> it floods dmesg and I cannot log into the machine anymore.I have to
> reboot and remove "debug" from the command line so that the machine can
> boot. BUT(!)

That is the expected current behaviour, "debug" can cause "too many" messages
to be useful anymore if things are broken.

> I want to see kernel debug messages so I have to be able
> to supply "debug" *without* systemd interfering.

Then use the kernels loglevel= parameter for the kernel only, not affecting
Base OS tools.

> What it should do, instead, is *not* parse "debug" but something else
> with a namespace, i.e. "systemd.debug" or whatever as "debug" is a
> kernel cmdline parameter and not aimed for systemd.

The generic term "debug" is read by Base OS tools too.

> And while we're at it, we'd need a configurable option to tell systemd
> *not* to log to dmesg for when one wants to see only output from the
> kernel in the kernel ring buffer, i.e. something like "systemd.nodmesg"
> or so.

Like for the kernel, there are options to fin-grain control systemd's logging
behaviour; just do not use the generic term "debug" which is a convenience
shortcut for the kernel AND the Base OS.

-- 
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/20140402/ee57ba26/attachment.html>