Am Sat, 10 Feb 2018 09:39:35 -0800 schrieb vcaputo:
>> After some more research, I found that vm.watermark_scale_factor may be
>> the knob I am looking for. I'm going to watch behavior now with a
>> higher factor (default = 10, now 200).
>>
>>
> Have you reporteed this to the kernel maintainers?
On Sat, Feb 10, 2018 at 03:05:16PM +0100, Kai Krakow wrote:
> Am Sat, 10 Feb 2018 14:23:34 +0100 schrieb Kai Krakow:
>
> > Am Sat, 10 Feb 2018 02:16:44 +0200 schrieb Uoti Urpala:
> >
> >> On Fri, 2018-02-09 at 12:41 +0100, Lennart Poettering wrote:
> >>> This last log lines indicates journald was
Am Sat, 10 Feb 2018 14:23:34 +0100 schrieb Kai Krakow:
> Am Sat, 10 Feb 2018 02:16:44 +0200 schrieb Uoti Urpala:
>
>> On Fri, 2018-02-09 at 12:41 +0100, Lennart Poettering wrote:
>>> This last log lines indicates journald wasn't scheduled for a long
>>> time which caused the watchdog to hit and j
Am Sat, 10 Feb 2018 02:16:44 +0200 schrieb Uoti Urpala:
> On Fri, 2018-02-09 at 12:41 +0100, Lennart Poettering wrote:
>> This last log lines indicates journald wasn't scheduled for a long
>> time which caused the watchdog to hit and journald was
>> aborted. Consider increasing the watchdog timeou
On Fri, 2018-02-09 at 12:41 +0100, Lennart Poettering wrote:
> This last log lines indicates journald wasn't scheduled for a long
> time which caused the watchdog to hit and journald was
> aborted. Consider increasing the watchdog timeout if your system is
> indeed that loaded and that's is suppose
On Do, 08.02.18 23:50, Kai Krakow (hurikha...@gmail.com) wrote:
> Hello!
>
> During memory pressure and/or high load, journald may crash. This is
> probably due to design using mmap but it should really not do this.
>
> On 32-bit systems, we are seeing such crashes constantly although the
> avai
Am Thu, 08 Feb 2018 18:12:23 -0800 schrieb vcaputo:
> Note the logs you've pasted portray a watchdog timeout which resulted in
> SIGABRT and a subsequent core dump.
>
> This is not really a journald "crash", and you can increase the watchdog
> timeout or disable it entirely to make it more tolera
Note the logs you've pasted portray a watchdog timeout which resulted in
SIGABRT and a subsequent core dump.
This is not really a journald "crash", and you can increase the watchdog
timeout or disable it entirely to make it more tolerant of thrashing.
What I presume happened is the system was thr
Hello!
During memory pressure and/or high load, journald may crash. This is
probably due to design using mmap but it should really not do this.
On 32-bit systems, we are seeing such crashes constantly although the
available memory is still gigabytes (it's a 32-bit userland running in a
64-bit ker
