Re: [systemd-devel] systemd hackfest talking points

2018-10-03 Thread vcaputo
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: >

[systemd-devel] journald fsync() errors

2018-04-03 Thread vcaputo
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,

Re: [systemd-devel] systemd-journald may crash during memory pressure

2018-02-10 Thread vcaputo
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

Re: [systemd-devel] systemd-journald may crash during memory pressure

2018-02-08 Thread 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 tolerant of thrashing. What I presume happened is the system was

Re: [systemd-devel] hash context not closed.

2018-02-03 Thread vcaputo
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

Re: [systemd-devel] hash context not closed.

2018-02-03 Thread vcaputo
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

Re: [systemd-devel] hash context not closed.

2018-02-03 Thread vcaputo
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. >

Re: [systemd-devel] How to make journald increase logs storage capacity?

2018-01-21 Thread vcaputo
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

Re: [systemd-devel] systemctl is-active

2018-01-15 Thread vcaputo
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.

Re: [systemd-devel] Illegal CPUID instruction causes systemd core dump

2017-12-28 Thread vcaputo
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

Re: [systemd-devel] How do I remove dead process managed by Systemd?

2017-12-04 Thread vcaputo
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)

Re: [systemd-devel] Outputting STDOUT and STDERR to current $SSH_TTY

2017-08-11 Thread vcaputo
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

Re: [systemd-devel] Hashmap iteration is too costly

2017-07-17 Thread vcaputo
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: > > > >

[systemd-devel] Hashmap iteration is too costly

2017-07-14 Thread vcaputo
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

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

2017-07-10 Thread vcaputo
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

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

2017-07-07 Thread vcaputo
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: > > >

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

2017-07-07 Thread vcaputo
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

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

2017-07-07 Thread vcaputo
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

Re: [systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

2017-07-07 Thread vcaputo
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 +,

[systemd-devel] Significant performance loss caused by commit a65f06b: journal: return -ECHILD after a fork

2017-07-07 Thread vcaputo
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