[Toybox] [PATCH] dmesg: fix multi-line messages

[Rob Landley]

I'm going through my "old patches" directory and deleting the ones I've already
applied or resolved, and I hit this from mid-pandemic, which does not have a
reply marker in my email nor in the list web archive. (Most likely my laptop
battery died and my reply window got lost because thunderbird doesn't save them,
and then I never got a follow-up poke to remind me...)

Was there more context? Was this ever tracked down as a kernel bug or a dash
issue or something? Is the original reporter still available? Because I didn't
reproduce it.

On 3/7/20 10:24, Ju Hyung Park wrote:
> Hi Rob, sorry for the late reply.
> 
> Was busy with uni stuffs.
> 
> On Tue, Mar 3, 2020 at 5:00 AM Rob Landley <rob at landley.net> wrote:
>> I'm not sure what the sh -c wrapper accomplishes here?
> 
> The results are different from
> `sh -c "printf 'line a\nline b\n'" > /dev/kmsg`
> and
> `printf 'line a\nline b\n' > /dev/kmsg`.
> 
> I honestly don't know why, but you'll get the same issue as my
> original commit message describes if you wrap it with `sh -c`.

Which sounds like it means you were using dash in the one that failed, and bash
in the one that succeeded. (Because on ubuntu the login shell of all users is
bash by default, but /bin/sh points to dash because ubuntu did something stupid
and refused to ever admit it had been stupid even when it publicly didn't work.)

That said:

$ sh -c "printf 'line a\nlinb\n'"  | hd
00000000  6c 69 6e 65 20 61 0a 6c  69 6e 62 0a              |line a.linb.|
0000000c
$ printf 'line a\nlinb\n' | hd
00000000  6c 69 6e 65 20 61 0a 6c  69 6e 62 0a              |line a.linb.|
0000000c

Binary identical. And also:

$ sh -c "printf 'line a\nlinb\n'" > /dev/kmsg
bash: /dev/kmsg: Permission denied

If you try to run under sudo it'll fail because your shell tries to set up the
redirect before calling sudo, and a common reason for an sh -c wrapper like that
is so you can sudo the whole command line, but that would mean the redirect was
INSIDE the quotes which is not what you presented here...

>> The util-linux dmesg isn't parsing "\x0a" as a magic sequence, that I can tell?
> 
> I deliberately didn't peek at util-linux or busybox's implementation
> as that would potentially become a licensing issue..?
> But either way, I'm sure they'll handle this "multi-line" kmsg.

My point was the specific processing you wanted to add to toybox dmesg is not
being done by other dmesg implementations. "It's ok, they handle it another way
by magic" is not really the explanation I'm looking for here...

>> How do I reproduce the problem you're seeing?
> 
> As I mentioned, a `sh -c` wrapper will do its thing.

It didn't for me at the time.

> The behavior is reproducible on my Ubuntu setup and my Android 10 device.

I was going to ask you to do:

  sudo timeout 2 cat /dev/kmsg | gzip > kmsg.gz

And send me the kmsg.gz file on a system demonstrating this problem.

> The reason why I wanted to fix this was to make toybox properly
> display multi-line printk()s such as `pr_info("%s\n%s\n%s", ...);`.

I'd love to fix it. First I'd like to reproduce it.

> Thanks.

Rob