Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

syslogd became silent between 11.2-PRERELEASE r334874 and r335282

1 view
Skip to first unread message

Michael Grimm

unread,
Jun 17, 2018, 10:31:38 AM6/17/18
to
Hi,

I am running service jails (VNET/bridge/epair) and a host at 11.2-PRERELEASE r335282, upgraded from r334874 today.

All syslog messages at each jail become forwarded to syslogd running at the host. This setup worked for years. Today not a single syslog message becomes forwarded to the host's syslogd.

Host's syslogd can be reached from inside every jail, e.g.:

jtest> nc -4vuw 1 10.x.y.z 514
Connection to 10.x.y.z 514 port [udp/syslog] succeeded!

logger doesn't throw any error. No message will be forwarded to the host's syslogd either:

jtest> logger -4 10.x.y.z HELLO
jtest>

I cannot find any hint in src/UPDATING.

What did I miss?
Anyone else with a silenced syslogd?
Anyone running my setup with a noisy syslogd?

Thank you in advance and regards,
Michael

_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stabl...@freebsd.org"

Gary Palmer

unread,
Jun 17, 2018, 10:54:42 AM6/17/18
to
On Sun, Jun 17, 2018 at 04:27:33PM +0200, Michael Grimm wrote:
> Hi,
>
> I am running service jails (VNET/bridge/epair) and a host at 11.2-PRERELEASE r335282, upgraded from r334874 today.
>
> All syslog messages at each jail become forwarded to syslogd running at the host. This setup worked for years. Today not a single syslog message becomes forwarded to the host's syslogd.
>
> Host's syslogd can be reached from inside every jail, e.g.:
>
> jtest> nc -4vuw 1 10.x.y.z 514
> Connection to 10.x.y.z 514 port [udp/syslog] succeeded!
>
> logger doesn't throw any error. No message will be forwarded to the host's syslogd either:
>
> jtest> logger -4 10.x.y.z HELLO
> jtest>
>
> I cannot find any hint in src/UPDATING.
>
> What did I miss?
> Anyone else with a silenced syslogd?
> Anyone running my setup with a noisy syslogd?

Hi,

UDP is connectionless, so the client has no way of knowing if the
connection succeeded or not. If you put in port 515 I suspect you'd
get the same result from your 'nc' attempt.

Is syslogd on the host running with '-s'? If so, that'll stop it
from accepting any remote log events.

Regards,

Gary

Michael Grimm

unread,
Jun 17, 2018, 11:02:28 AM6/17/18
to
On 17. Jun 2018, at 16:50, Gary Palmer <gpa...@freebsd.org> wrote:
> On Sun, Jun 17, 2018 at 04:27:33PM +0200, Michael Grimm wrote:

>> Host's syslogd can be reached from inside every jail, e.g.:
>>
>> jtest> nc -4vuw 1 10.x.y.z 514
>> Connection to 10.x.y.z 514 port [udp/syslog] succeeded!
>

> UDP is connectionless, so the client has no way of knowing if the
> connection succeeded or not. If you put in port 515 I suspect you'd
> get the same result from your 'nc' attempt.

You are right :-)

> Is syslogd on the host running with '-s'? If so, that'll stop it
> from accepting any remote log events.

No, syslogd at the host is running with the following flags only:
syslogd_flags="-vv -b 10.x.y.z -a 10.x.y.0/24"

All syslogd within jails (empty flags needed to prevent syslogd of opening sockets) ...
syslogd_flags=""

… and /etc/syslog.conf with:
*.* @10.x.y.z

Regards,
Michael

Michael Grimm

unread,
Jun 17, 2018, 11:56:42 AM6/17/18
to
On 17. Jun 2018, at 16:27, Michael Grimm <tras...@ellael.org> wrote:

> Hi,
>
> I am running service jails (VNET/bridge/epair) and a host at 11.2-PRERELEASE r335282, upgraded from r334874 today.
>
> All syslog messages at each jail become forwarded to syslogd running at the host. This setup worked for years. Today not a single syslog message becomes forwarded to the host's syslogd.

I do believe that this commit might be the cause:
https://svnweb.freebsd.org/base/stable/11/usr.sbin/syslogd/Makefile?revision=335059&view=markup&sortby=file

But I do have to admit, that I do not understand what changed and what would cause my syslogd become silenced, though.

Any hints?

Yasuhiro KIMURA

unread,
Jun 17, 2018, 12:11:40 PM6/17/18
to
From: Michael Grimm <tras...@ellael.org>
Subject: syslogd became silent between 11.2-PRERELEASE r334874 and r335282
Date: Sun, 17 Jun 2018 16:27:33 +0200

> I am running service jails (VNET/bridge/epair) and a host at 11.2-PRERELEASE r335282, upgraded from r334874 today.

There was a large MFC about syslogd at r335059:

https://svnweb.freebsd.org/base?view=revision&revision=335059

----------------------------------------------------------------------
MFC r309925, r309931, r309933, r310035, r310278, r310310, r310311,
r310323, r310349, r310350, r310351, r310352, r310383, r310384,
r310385, r310386, r310393, r310453, r310456, r310494, r310504,
r310528, r310890, r310893, r310974, r311918, r312921, r313357,
r314563, r314585, r314642, r315322, r315618, r315620, r315622,
r315643, r316951, r316973, r326338, r326339, r326573, r331270,
r332099, r332110, r332111, r332118, r332165, r332510 and r332511.

This commit brings syslogd(8) in sync with the copy in HEAD. The key
improvement of this change is that it adds support for RFC 5424 log
ingestion and exposition (enabled by passing in -O rfc5424). This allows
for saner logging in environments with multiple time zones.

The list of changes to merge back were obtained by running:

svn mergeinfo --show-revs eligible \
^/head/usr.sbin/syslogd ^/stable/11/usr.sbin/syslogd

Of the commits listed, r314436, r325188 and r326025 were excluded, as
they affect a significant number of unrelated files (SPDX and 4-clause
license renumbering). Due to the large number of directly committed
changes on this branch, I had no choice but to perform the merge as
follows:

svn merge --accept=theirs-full -c <list of revisions> ^/head .

This would, however, cause some unrelated changes, such as undoing the
r333356 (MFC of r332877) and still adding the SPDX tag to syslogd.c.
These have been reverted manually.

Requested by: Dave Cottlehuber
Thanks to: dim@ for sharing his insight on hackers@
----------------------------------------------------------------------

So how about take following steps?

1. svn update -r 335058 /usr/src
2. Rebuild and reinstall /usr/sbin/syslogd and /usr/bin/wall on both
host and jail.
3. Restart syslogd on both host and jail.

And if the problem is dissapeared, then you should open bug report.

Best,

---
Yasuhiro KIMURA

Michael Grimm

unread,
Jun 17, 2018, 12:38:46 PM6/17/18
to
On 17. Jun 2018, at 18:06, Yasuhiro KIMURA <ya...@utahime.org> wrote:

> There was a large MFC about syslogd at r335059:

> So how about take following steps?
>
> 1. svn update -r 335058 /usr/src
> 2. Rebuild and reinstall /usr/sbin/syslogd and /usr/bin/wall on both
> host and jail.
> 3. Restart syslogd on both host and jail.

That's what I have started already in the meantime :-)

> And if the problem is dissapeared, then you should open bug report.

I will report and open a bug report if needed.

Thank you and kind regards,
Michael

Ed Schouten

unread,
Jun 17, 2018, 1:32:39 PM6/17/18
to
Hi Michael,

2018-06-17 17:52 GMT+02:00 Michael Grimm <tras...@ellael.org>:
> I do believe that this commit might be the cause:
> https://svnweb.freebsd.org/base/stable/11/usr.sbin/syslogd/Makefile?revision=335059&view=markup&sortby=file

Thanks for reporting this issue. I just did some debugging on my
system and I think I was able to reproduce this issue. It seems as if
I made a tiny mistake in how I implemented the RFC 5426 UDP message
size limiting. Could you please give the following patch for syslogd a
try?

Index: usr.sbin/syslogd/syslogd.c
===================================================================
--- usr.sbin/syslogd/syslogd.c (revision 334706)
+++ usr.sbin/syslogd/syslogd.c (working copy)
@@ -1613,8 +1613,8 @@
struct iovec *last;
size_t diff;

- while (size > il->totalsize) {
- diff = size - il->totalsize;
+ while (il->totalsize > size) {
+ diff = il->totalsize - size;
last = &il->iov[il->iovcnt - 1];
if (diff >= last->iov_len) {
/* Remove the last iovec entirely. */

It should be sufficient to apply this to just the 'client' syslogd.
There is no need to patch the central (storage) server.

--
Ed Schouten <e...@nuxi.nl>
Nuxi, 's-Hertogenbosch, the Netherlands

Michael Grimm

unread,
Jun 17, 2018, 4:08:30 PM6/17/18
to
Hi Ed --
Sorry for my late response, and:

Thanks, your patch fixed it!

I am not that much experienced, but that's what I did:

#) svn update -r 335059
#) applied your patch
#) recompiled world and kernel
#) reinstalled world and kernel
#) reinstalled my jail's basejail (ezjail technology)
#) reboot
-> return of syslogd clients being able to send syslog messages from jails to host's syslogd

I hope that this is sufficient prove that your patch will work?

Thank you very much and with kind regards,
Michael

Ed Schouten

unread,
Jun 18, 2018, 2:07:25 AM6/18/18
to
Hi Michael,

2018-06-17 22:04 GMT+02:00 Michael Grimm <tras...@ellael.org>:
> Thanks, your patch fixed it!

That's awesome. Thanks for confirming!

> I am not that much experienced, but that's what I did:
>
> #) svn update -r 335059
> #) applied your patch
> #) recompiled world and kernel
> #) reinstalled world and kernel
> #) reinstalled my jail's basejail (ezjail technology)
> #) reboot
> -> return of syslogd clients being able to send syslog messages from jails to host's syslogd
>
> I hope that this is sufficient prove that your patch will work?

Yes, that's all right. I've just committed the patch (r335314) and
will MFC it to 11-STABLE before the end of the week.

Best regards,
--
Ed Schouten <e...@nuxi.nl>
Nuxi, 's-Hertogenbosch, the Netherlands

Ed Schouten

unread,
Jun 21, 2018, 12:19:12 PM6/21/18
to
2018-06-18 8:02 GMT+02:00 Ed Schouten <e...@nuxi.nl>:
> I've just committed the patch (r335314) and
> will MFC it to 11-STABLE before the end of the week.

Done, in r335492. Thanks again for reporting this issue!
0 new messages