Re: [PATCH v6 02/15] trace2: create new combined trace facility

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 06 2019, Jeff Hostetler via GitGitGadget wrote:

> +	sa.sun_family = AF_UNIX;
> +	strlcpy(sa.sun_path, path, sizeof(sa.sun_path));
> +	if ((fd = socket(AF_UNIX, SOCK_STREAM, 0)) == -1 ||
> +	    connect(fd, (struct sockaddr *)&sa, sizeof(sa)) == -1) {
> +		if (tr2_dst_want_warning())
> +			warning("trace2: could not connect to socket '%s' for '%s' tracing: %s",
> +				path, dst->env_var_name, strerror(errno));
> +
> +		tr2_dst_trace_disable(dst);
> +		return 0;
> +	}

Just curious, what do you use af_unix:* for? Is this provided by some
Windows emulation ?

On Linux with systemd, this does not work for logging to systemd's
/dev/log. You're opening the socket with SOCK_STREAM, but it needs
SOCK_DGRAM. I.e.:

    # fail
    echo '{"yay": "testing"}' | nc -U /dev/log
    # works
    echo '{"yay": "testing"}' | nc -uU /dev/log

So that gives something that'll "work" for "jounalctl -f", but on my
system ends up being munged to the invalid JSON:

    '{"yay"[PID]: "testing"}'.

I found, and this may be specific to the systemd/rsyslog setup on RedHat
I'm working with, that what /dev/log is expecting is a payload in the
syslog format: https://tools.ietf.org/html/rfc5424

So related to my question in
https://public-inbox.org/git/87a7iyk0r8.fsf@xxxxxxxxxxxxxxxxxxx/ I
wonder what we should do about this. It seems the bare minimal thing
that's needed it some way to open a socket with SOCK_DGRAM, maybe we
should just do that unconditionally if the connect() fails with
EPROTOTYPE?

But it seems that for that to be useful for systemd we'd need to support
the syslog.h interface (so different from af_unix:*), or learn how to
write a standard syslog packet to an af_unix:* SOCK_DGRAM socket.

I guess we can start with just supporting that by hardcoding the ident &
LOG_* values to something sensible, e.g.:

  openlog("git", LOG_PID | (tr2_dst_want_warning() ? LOG_CONS : 0), LOG_USER);
  syslog(LOG_USER|LOG_DEBUG, message_or_json);
  closelog();

I can write the patches for this. As in the earlier message I'm just
looking for some context, whether this is stuff you have WIP already,
and whether you have any other/related ideas. Thanks.



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux