[Bug 238006] syslogd not starting because of missing /var/run/log

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238006

Harald Schmalzbauer <bugzilla.freebsd@omnilan.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla.freebsd@omnilan.de

--- Comment #6 from Harald Schmalzbauer <bugzilla.freebsd@omnilan.de> ---
Hello,
I stumbled across this PR while debugging:
'logmsg: pri 53, flags 0, from , msg getaddrinfo failed for syslog: Name does
not resolve'
Since services(5) does include 'syslog  514/udp' in FreeBSD 14.1, my problem
isn't exactly the same, but related.

syslogd(8) doesn't stat in jails which are neither vnet-enabled nor do have a
shared-ip assigned.
I tracked it down to socksetup() in src/usr.sbin/syslogd/syslogd.c.

In main(), after getopt processing,
if no -b as CLI arg was specified [line 742]:
    /* Listen by default: *:514 if no -b flag. */
    if (bflag == 0)
        addpeer(&(struct peer){
            .pe_serv = "syslog"
    });

addpeer() is unconditionally called to add service "syslog" to peer.pe_serv,
even if ( SecureMode > 1 ).

Then, in socksetup(), getaddrinfo() fails in jails as decribed above (no vnet,
no shared-IP).

Unfortunately, that's the part I don't understand.
Neither why it fails, nor why this unconditionally causes die(0); [line 3840].

The check which should make the check result meaningless comes _after_ die(0)
[line 3845]:
if (res->ai_family != AF_LOCAL &&
    SecureMode > 1) {
        /* Only AF_LOCAL in secure mode. */
        continue;
    }

My C skills are too weak to propose a patch, but at least I found a suitable
workaround for the moment:
Adding -b 127.0.0.1 (in addition to -ss) as CLI arg prevents from die(0);.


Anyone familiar with getaddrinfo(3) who can judge if the problem really is in
the syslogd code path as outlined above, or if the real bug is that
getaddrinf(3) fails in jails without a shared-IP configured (and not a vnet
lo0)?

Thanks,
-harry

-- 
You are receiving this mail because:
You are the assignee for the bug.