On Wed, Oct 03, 2018 at 08:01:19AM +, Zbigniew Jędrzejewski-Szmek wrote:
> Hi,
>
> we had a systemd hackfest/talkfest last Sunday in Berlin as part of
> AllSystemdGo 2018.
>
> Here is a copy of the doc we used to discuss the technical &
> documentations topics:
>
Back when I worked on making fsync() in journald asynchronous, I
preserved the existing strategy of ignoring fsync() errors.
In reading [1], I am reminded of this situation and am again wondering
why this is the case. Shouldn't journald trigger a journal rotate when
fsync() realizes an IO error,
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
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
On Sat, Feb 03, 2018 at 09:14:40PM +0100, Stef Bon wrote:
> The testing of the new code requires me too much (meson is required..
> and I don't want to replace my existing systemd) and I do not expect
> to add more patches is near future.
>
> I've got a patch:
>
> diff --git
On Sat, Feb 03, 2018 at 08:38:38PM +0100, Stef Bon wrote:
> 2018-02-03 20:27 GMT+01:00 :
>
> >
> > Nice catch, that indeed looks like a leak. Would you like to prep a
> > PR fixing it?
> >
>
> PR? I do not know what you mean. A pull request?
> I can write a patch.
The
On Sat, Feb 03, 2018 at 07:26:24PM +0100, Stef Bon wrote:
> Hi,
>
> when I look at the function string_hashsum it looks like the context
> is not closed when done.
>
> After a succesfull gcry_md_open the hash context md should be closed
> when leaving this function. That does not happen.
>
On Sat, Jan 20, 2018 at 08:28:21PM +0300, 4xy wrote:
> I have limit in 4Gb for journald regardless of the settings I've made. I see
> this line in the manual
>
> |$ sudo systemctl status systemd-journald ... jan 20 15:44:26 host
> systemd-journald[1218]: System journal (/var/log/journal/) is
On Tue, Jan 16, 2018 at 12:17:52AM +0100, Michał Zegan wrote:
> Hello.
> When systemctl is-active was added?
> I need this to check if I can safely use it to check if unit is active
> if I don't have prior knowledge about the systemd version I am running
> this on, this is for an ansible playbook.
On Thu, Dec 28, 2017 at 10:08:59PM +0100, Lennart Poettering wrote:
> On Do, 28.12.17 20:26, Reindl Harald (h.rei...@thelounge.net) wrote:
>
> >
> >
> > Am 28.12.2017 um 20:07 schrieb tedheadster:
> > > I am doing regression testing on old hardware. systemd-233 just
> > > generated the
On Mon, Dec 04, 2017 at 07:14:51PM +0100, Lennart Poettering wrote:
> On Mo, 04.12.17 23:15, Yun-Chih Chen (yunchih@gmail.com) wrote:
>
> > Hi, fellows:
> >
> > How do I remove a dead process (D-state process) wrapped as a Systemd
> > service unit? The process's parent is systemd (pid=1)
This is not recommended. Forwarding is currently implemented
synchronously in journald, and can have a very substantial negative
impact on journald performance in general as a result.
BTW: are we not averse to top-posting on systemd-devel?
Regards,
Vito Caputo
On Fri, Aug 11, 2017 at
On Mon, Jul 17, 2017 at 10:12:12AM +0200, Lennart Poettering wrote:
> On Fri, 14.07.17 03:18, vcap...@pengaru.com (vcap...@pengaru.com) wrote:
>
> > The current hashmap iteration incurs at least one function call per
> > iteration, and in my observations using gcc 6.3 w/-g -O2, it's two:
> >
> >
The current hashmap iteration incurs at least one function call per
iteration, and in my observations using gcc 6.3 w/-g -O2, it's two:
internal_hashmap_iterate()
hashmap_iterate_entry()
for every element in the hashmap.
In profiles of `journalctl -b --no-pager` having multiple (50) log
On Sat, Jul 08, 2017 at 03:49:11AM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Jul 07, 2017 at 03:54:09PM -0700, vcap...@pengaru.com wrote:
> > On Fri, Jul 07, 2017 at 10:34:22PM +, Zbigniew Jędrzejewski-Szmek wrote:
> > > On Fri, Jul 07, 2017 at 02:35:16PM -0700, vcap...@pengaru.com
On Fri, Jul 07, 2017 at 10:34:22PM +, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, Jul 07, 2017 at 02:35:16PM -0700, vcap...@pengaru.com wrote:
> > On Fri, Jul 07, 2017 at 01:49:54PM -0700, vcap...@pengaru.com wrote:
> > > On Fri, Jul 07, 2017 at 08:37:08PM +, Mantas Mikulėnas wrote:
> > >
On Fri, Jul 07, 2017 at 01:49:54PM -0700, vcap...@pengaru.com wrote:
> On Fri, Jul 07, 2017 at 08:37:08PM +, Mantas Mikulėnas wrote:
> > Back when that commit was made, didn't glibc cache the getpid() result in
> > userspace? That would explain why it was not noticed.
>
> Hmm, this crossed my
On Fri, Jul 07, 2017 at 01:49:54PM -0700, vcap...@pengaru.com wrote:
> On Fri, Jul 07, 2017 at 08:37:08PM +, Mantas Mikulėnas wrote:
> > Back when that commit was made, didn't glibc cache the getpid() result in
> > userspace? That would explain why it was not noticed.
>
> Hmm, this crossed my
Hmm, this crossed my mind, and come to think of it I did a dist-upgrade
from Debian jessie to stretch overnight machine and haven't rebooted.
Perhaps the vdso isn't working and the costly getpid() is a red herring, will
reboot and retest to confirm.
On Fri, Jul 07, 2017 at 08:37:08PM +,
In doing some casual journalctl profiling and stracing, it became apparent
that `journalctl -b --no-pager` runs across a significant quantity of logs,
~10% of the time was thrown away on getpid() calls due to commmit a65f06b.
As-is:
# time ./journalctl -b --no-pager > /dev/null
real
20 matches
Mail list logo