Hi Martin,
Am 28.03.2015 um 08:15 schrieb Martin Pitt:
> Hey Christian, Michael,
>
> Michael Biebl [2015-03-20 6:25 +0100]:
>> So I guess I'll merge your patch as is, including the upstream commit.
>>
>> I've been running with both patches applied for a while and didn't have
>> a single missed m
Hey Christian, Michael,
Michael Biebl [2015-03-20 6:25 +0100]:
> So I guess I'll merge your patch as is, including the upstream commit.
>
> I've been running with both patches applied for a while and didn't have
> a single missed message since then.
I'm a bit confused what the exact patch is no
Am 2015-03-20 06:25, schrieb Michael Biebl:
You can probably trigger this by putting 12 modules into
/etc/modules-load.d. Each one will generate a message for the
journal
and after the 11th the service will hang. Jupp, just tried it,
deadlocks. Will, kind-of, because after ~15s it will somehow
Am 03.03.2015 um 16:48 schrieb Christian Seiler:
> Am 2015-03-03 16:26, schrieb Michael Biebl:
>> I did a couple more reboots and did indeed run into the problem, that
>> systemd-sysctl.service was started after syslog.socket, so I got the
>> "missed XXX messages" again.
>> Adding the After=systemd
Am 03.03.2015 um 16:26 schrieb Christian Seiler:
> Am 2015-03-03 15:33, schrieb Michael Biebl:
>> Am 02.03.2015 um 15:42 schrieb Christian Seiler:
>>
>>> - SOLUTION (mostly the same as before, but SendBuffer is set on a
>>>different unit and a Condition is added to the service):
>>>
>>>
Am 2015-03-03 16:26, schrieb Michael Biebl:
I did a couple more reboots and did indeed run into the problem, that
systemd-sysctl.service was started after syslog.socket, so I got the
"missed XXX messages" again.
Adding the After=systemd-sysctl.service ordering to syslog.socket
fixed
that. In [1]
Am 2015-03-03 15:33, schrieb Michael Biebl:
Am 02.03.2015 um 15:42 schrieb Christian Seiler:
- SOLUTION (mostly the same as before, but SendBuffer is set on a
different unit and a Condition is added to the service):
1. Increase max_dgram_qlen to a reasonable value. The easiest
Am 03.03.2015 um 16:00 schrieb Michael Biebl:
> Am 03.03.2015 um 15:33 schrieb Michael Biebl:
>> Am 02.03.2015 um 15:42 schrieb Christian Seiler:
>>
>>> - SOLUTION (mostly the same as before, but SendBuffer is set on a
>>>different unit and a Condition is added to the service):
>>>
>>> 1
Am 03.03.2015 um 15:33 schrieb Michael Biebl:
> Am 02.03.2015 um 15:42 schrieb Christian Seiler:
>
>> - SOLUTION (mostly the same as before, but SendBuffer is set on a
>>different unit and a Condition is added to the service):
>>
>> 1. Increase max_dgram_qlen to a reasonable value. The
Am 02.03.2015 um 15:42 schrieb Christian Seiler:
> - SOLUTION (mostly the same as before, but SendBuffer is set on a
>different unit and a Condition is added to the service):
>
> 1. Increase max_dgram_qlen to a reasonable value. The easiest
> way is via a systemd service:
>
>
I did some more tests on this and there is one key thing that I
misunderstood: SO_SNDBUF of the socket that is used to send the
datagrams is used as a limit in the kernel, not of the socket syslog
uses to receive them.
I actually tried setting SendBuffer=1 and ReceiveBuffer=1 on
syslog.socket (to
Small correction to my previous observations:
Am 2015-02-25 18:59, schrieb Christian Seiler:
- SendBuffer=8M will increase the max size of a single log message
that may be sent via this socket (8M is probably at bit much)
Actually that's not true. I've misread the kernel source here, and a
Am 26.02.2015 um 00:25 schrieb Christian Seiler:
> Am 2015-02-26 00:04, schrieb Michael Biebl:
>> That is not true, journal support has been enabled in rsyslog for
>> quite
>> a while. It's split into a separate package called "rsyslog-journal",
>> maybe that's why you didn't notice it?
>
> $ apt
Am 2015-02-26 00:04, schrieb Michael Biebl:
Also: I'm not looking for a solution that solves this for any
possible amount of log messages, but I do think that the current
limit doesn't provide enough of a safety zone that one would like
to rely on.
If we can make the journald -> syslog forwardi
Am 25.02.2015 um 23:49 schrieb Christian Seiler:
> Am 2015-02-25 23:26, schrieb Michael Biebl:
>> If you need that kind of throughput, using the imjournal module might
>> possibly be the better choice (would need some testing, how mature
>> imjournal is). Unfortunately, it's not really possible to
Le 25/02/2015 22:18, Christian Seiler a écrit :
> Now this was really extreme, but there is software out there that
> does log heavily (also depending on the log level set by the admin),
> and just having a queue of 11 is really, really short in such
> situations. Yes, at some point there has to be
Am 2015-02-25 23:26, schrieb Michael Biebl:
If you need that kind of throughput, using the imjournal module might
possibly be the better choice (would need some testing, how mature
imjournal is). Unfortunately, it's not really possible to ship a
default
rsyslog configuration, which uses imjourna
Am 25.02.2015 um 22:18 schrieb Christian Seiler:
> Control: tags -1 - moreinfo
>
> Am 2015-02-25 21:27, schrieb Michael Biebl:
>> Am 25.02.2015 um 18:59 schrieb Christian Seiler:
>>> Control: severity -1 serious
>>>
>>> Thoughts?
>>
>> Those missing syslog messages (only) happen when systemd flush
Processing control commands:
> tags -1 - moreinfo
Bug #762700 [systemd] systemd: journald fails to forward some messages to syslog
Removed tag(s) moreinfo.
--
762700: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762700
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
_
Control: tags -1 - moreinfo
Am 2015-02-25 21:27, schrieb Michael Biebl:
Am 25.02.2015 um 18:59 schrieb Christian Seiler:
Control: severity -1 serious
Thoughts?
Those missing syslog messages (only) happen when systemd flushes the
initial boot kernel/messages to the syslog socket, right?
Not
Processing control commands:
> tags -1 moreinfo
Bug #762700 [systemd] systemd: journald fails to forward some messages to syslog
Added tag(s) moreinfo.
--
762700: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762700
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
_
Control: tags -1 moreinfo
Am 25.02.2015 um 18:59 schrieb Christian Seiler:
> Control: severity -1 serious
>
> Thoughts?
Those missing syslog messages (only) happen when systemd flushes the
initial boot kernel/messages to the syslog socket, right?
Once the syslog daemon is running, do you still g
Control: severity -1 serious
(justification for severity: breaks unrelated software, in this case
all syslog daemons on a default installation; could possibly be
considered grave or even criticial - data loss affecting nearly all
users)
This bug is actually much worse than it seems. In fact, on
23 matches
Mail list logo
