On Sun, Aug 9, 2015 at 6:20 AM, Olivier Brunel <jjk_at_jjacky.com> wrote:
> On 08/09/15 10:44, Laurent Bercot wrote:
>> The path leading to the first invocation of readv() hasn't changed,
>> but readv() gives different results. My first suspicion is that "logger"
>> isn't sending the last character (newline or \0) in the second case
>> before exiting, which skagetlnsep() interprets as "I was unable to
>> read a full line before EOF happened" and reports as EPIPE.
>> Are you using the same version of "logger" on both machines ?
>>
That would do it. heliocat is running Debian 8, whereas radon is
running Debian unstable. Debian 8 is on bsdutils 2.25.2 and unstable
on 2.26.2.
>> Grrr. If "logger" starts sending incomplete lines, I may have to change
>> the ucspilogd code to accommodate it.
>
> Had a quick look at this (procrastination & stuff :p) and it seems to me
> this is probably a bug in logger actually. At some point[1] they started
> not to use syslog(3) anymore but implementing things on their own instead.
> However, there's a difference with glibc's implementation, specifically
> when using a SOCK_STREAM the later adds a NUL byte as record terminator,
> which the former does not. Hence there's never a terminating NUL byte
> from logger anymore and ucspilogd fails w/ EPIPE.
>
> HTH,
> -j
>
> [1]
> https://github.com/karelzak/util-linux/commit/1d57503378bdcd838365d625f6d2d0a09da9c29d
>
>
Thanks, checking logger versions was next on my list, right below going to bed.
Ok, looks like the bsdutils upgrade back in May broke it, the timing
lines up perfectly. Though it's my own damn fault for not noticing
until now.
It's unlikely that logger will get fixed, since rsyslog is able to
properly parse messages that logger is sending so from the maintainers
perspective this probably isn't going to get classified as a bug.
Entertainingly, switching ucspilogd for xargs -0 -- works for
single-shot log messages. Using logger as a supervised log/run doesn't
work, xargs won't print anything until it's told to terminate at which
point it execs into echo and dumps its output.
I haven't experimented with it yet, but I think the messages from
long-running logger processes are null-separated, just not the last
line. I'll take a look later today when I have time.
Cheers!
--
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
-- William Blake
Received on Sun Aug 09 2015 - 17:12:23 UTC