On Mon, Feb 16, 2015 at 11:21:53AM +0100, Lennart Poettering wrote:
Is your pppd daemon itself also a systemd service?
What precisely does monitor consist of for this case?
Yes, the pppd is invoked by systemd as a service. What I am
doing right now is:
link.service:
ExecStart=pppd call
On Sat, Jul 20, 2013 at 08:37:14AM +0200, Holger Hans Peter Freyther wrote:
But that looks like a plain automake bug. It should know that targets
starting with a dot are not real targets. Could you file a bug
report with automake, so this gets fixed properly?
I sent an email
On Thu, Aug 22, 2013 at 07:07:07AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
Those tests everywhere are not very pretty, but I guess we don't have
much choice if we want those tests to be runnable before booting with systemd.
Applied.
thanks! do you have a better idea on how to skip them?
On Wed, Aug 14, 2013 at 02:48:07PM -0700, David Strauss wrote:
The CI I maintain [1] for systemd is certainly one alternative that
continues to be in production. I'd like to get more test automation
going, but it's not like TravisCI was running any tests beyond a
successful build. I plan to
On Wed, Aug 14, 2013 at 11:15:35PM +0200, Kay Sievers wrote:
I temporarily switched it off now.
thanks for the heads up.
Maybe someone has an idea, or an alternative.
If David starts to execute make check make distcheck there
is probably nothing travis-ci provides that David's setup
On Sat, Jul 20, 2013 at 01:09:35AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
Hi,
Applied for now.
I picked %MAKEFILE% as this is what was in the generated Makefile before
my patch. I just tried to match the output.
But that looks like a plain automake bug. It should know that targets
On Sat, Jul 20, 2013 at 03:20:02PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
... that's at least how it looks in my testing. I don't think that
having %MAKEFILE% in the final Makefile makes any sense, and it
swhould always be Makefile. Maybe automake forgets to substitute it
in your case, or
From: Holger Hans Peter Freyther hol...@moiji-mobile.com
* Introduce a macro to conditionally execute tests. This avoids
skipping the entire test if some parts require systemd
* Skip the journal tests when no /etc/machine-id is present
* Change test-catalog to load the catalog from the source
From: Holger Hans Peter Freyther hol...@moiji-mobile.com
Yesterday I added test-suite.log as dependency to the .PRECIOUS
target. Automake is warning about this target being redefined
and from what I see there is no way I can stop the warning but
I can add the %MAKEFILE% as dependency.
automake
From: Holger Hans Peter Freyther hol...@moiji-mobile.com
When using Storage=none there is no point in collecting all the
information just to throw them away. After this change journald
consumes a lot less CPU time when only forwarding messages.
---
src/journal/journald-server.c | 5 +
1 file
On Thu, Jul 18, 2013 at 08:32:18PM +0200, Karol Lewandowski wrote:
Agreed, this is why I have been naively thinking that caching wouldn't
be that bad... However, sending all the required information in message
itself is clearly the best solution to this problem.
It is nice to avoid the race
On Fri, Jul 12, 2013 at 07:51:26PM +0200, Lennart Poettering wrote:
Commited. I figure this will not be useful right-away, since current git
of systemd requires a very new version of kmod that is not available at
Travis. However, it's still a good thing to have and to enable as soon
as that
From: Holger Hans Peter Freyther hol...@moiji-mobile.com
The addition of .DELETE_ON_ERROR will lead to the removal of the
test-suite.log in case of a test failure. Mark the rule as PRECIOUS
to keep that file around.
---
Makefile.am | 3 +++
1 file changed, 3 insertions(+)
diff --git
From: Holger Hans Peter Freyther hol...@moiji-mobile.com
* Introduce a macro to conditionally execute tests. This avoids
skipping the entire test if some parts require systemd
* Skip the journal tests when no /etc/machine-id is present
* Change test-catalog to load the catalog from the source
On Thu, Jul 18, 2013 at 06:16:48AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
Can we use the STRINGIFY macro instead?
I can try.
/* Note: this might actually not find anything, if systemd was
* not installed before. That should be fine too. */
-r =
On Wed, Jul 17, 2013 at 05:08:46PM +0200, Kay Sievers wrote:
I did something like that now. Let's see if it works ...
Thank you, it did[1].
[1] https://travis-ci.org/systemd/systemd
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
On Wed, Jul 17, 2013 at 04:02:26PM -0300, Lucas De Marchi wrote:
Talking about kmod and travis-ci. In kmod we are using it. Pretty
cool, with an IRC bot integration. I only wish there were more options
of distributions. Right now it's only Ubuntu 12.04 32 bits
You could ask the people that
On Fri, Jul 12, 2013 at 07:51:26PM +0200, Lennart Poettering wrote:
On Tue, 09.07.13 18:09, Holger Hans Peter Freyther (hol...@freyther.de) wrote:
I figure a simple
if (sd_booted() = 0)
return EXIT_TEST_SKIP;
Ah great, I had planned to search if something like
From: Holger Hans Peter Freyther hol...@moiji-mobile.com
Instruct travis-ci to build systemd and create a tarball. In case
of an error travis-ci will complain on IRC. The systemd testsuite
currently requires the host to have a recent version of systemd
installed and running. This is not the case
On Fri, Jun 28, 2013 at 10:06:11AM +0200, Holger Hans Peter Freyther wrote:
On Fri, Jun 28, 2013 at 09:43:08AM +0200, Peter Sztanojev wrote:
So this issue is about tweaking how jenkins does its job?
I have added David Strauss to the CC, hopefully he won't mind.
Well, that is one part
On Wed, Jun 26, 2013 at 09:58:36PM +0200, Holger Hans Peter Freyther wrote:
So unless there is an issue with my recording/replay I think that
besides my opinion that mapping a 4MB file 65 times is ugly, it
also appears to be slower for the above workload in journald.
ping? any comments? what
On Sat, Jun 29, 2013 at 06:28:40AM +0200, Michael Biebl wrote:
could you check if this fixes the build for you?
It does indeed.
the same for the travis build on ubuntu (make check still fails
though but that is another issue).
___
systemd-devel
Dear Lennart,
the systemd build is currently broken[1] and judging from the commit
history it appears that this happened more than once. Besides fixing
the build you might want to consider adopting another strategy.
In mature software projects the following is quite common:
a.) Create a
On Fri, Jun 28, 2013 at 09:05:40AM +0200, Peter Sztanojev wrote:
On Fri, Jun 28, 2013 at 8:50 AM, Holger Hans Peter Freyther
there already is a jenkins ci for systemd kindly provided by Pantheon:
http://systemd.getpantheon.com:8080/jenkins/
The jenkins script is still using make test (which
On Fri, Jun 28, 2013 at 09:43:08AM +0200, Peter Sztanojev wrote:
So this issue is about tweaking how jenkins does its job?
I have added David Strauss to the CC, hopefully he won't mind.
Well, that is one part. make test really just checks if the test/
directory exists, it doesn't really
On Fri, Jun 28, 2013 at 03:44:35PM +0200, Michael Biebl wrote:
v44, v204 and git master all build and link fine on my pretty standard
Debian sid system, so I can't reproduce the problem, at least not on
Debian.
Which linker and which system do you run it on? A clean build on my
Debian Testing
On Fri, Jun 28, 2013 at 04:01:08PM +0200, Lennart Poettering wrote:
Maybe this is simply broken automake dependency info somewhere left in
your tree?
I did the git clean but I still wondered, this is why I created the
.travis.yml. Before I was building a branch that contained some of
my RFC
On Fri, Jun 28, 2013 at 07:05:35PM +0200, Michael Biebl wrote:
That said, I don't understand, why this commit breaks the build with
that (older) toolchain.
Neither bootctl nor libsystemd-id128.so is using cg_create().
at the same time it has an undefined reference...
$ nm -D
On Fri, Jun 21, 2013 at 06:01:08PM +0200, Holger Hans Peter Freyther wrote:
Do you have an idea on how this could be done?
Hi,
first of all the MMAP cache is not why journald is slow but that is
for another mail/benchmark. I was just curious if the mmap cache is
premature optimization
From: Holger Hans Peter Freyther hol...@moiji-mobile.com
Allow to cache the cg_get_root_path and introduce a new method
cg_pid_get_path_shifted_with_root that can use the cached version
instead of allocating a new string.
---
src/journal/journald-server.c | 20 +---
src/shared
From: Holger Hans Peter Freyther hol...@moiji-mobile.com
---
src/journal/journald-server.c | 45 ++---
1 file changed, 24 insertions(+), 21 deletions(-)
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index b08aa1d..e651a6d 100644
On Fri, Jun 21, 2013 at 12:29:56PM +0200, Kay Sievers wrote:
What's the problem with using address *space*? Address space is not
used memory, file memory mappings are just how things work in general,
they are cheap and should not really matter.
It is a symptom of inefficiency. If an
On Fri, Jun 21, 2013 at 01:53:23PM +0200, Kay Sievers wrote:
Fragmentation, allocation? I don't think we talk about the same thing here.
... you will figure that out.
Mapping an on-disk file a symptom of inefficiency, you might need to
update your idea of how things work.
I didn't say that
On Fri, Jun 21, 2013 at 04:19:30PM +0200, Kay Sievers wrote:
I have no idea why you care what the journald process does with its
very own 2+GB of address space, and why it uses 128MB of it.
I care about whether or not journald will work reliable on an
unattended system. And from what I see
On Fri, Jun 21, 2013 at 05:31:13PM +0200, Holger Hans Peter Freyther wrote:
I care about whether or not journald will work reliable on an
unattended system. And from what I see there is no limit in the
mmap cache. This means that journald can potentially exhaust the
virtual address space
On Fri, Jun 21, 2013 at 02:08:27PM +0200, Lennart Poettering wrote:
That said, the current map sizes are nothing we tuned particularly. If
you can show actal performance benefits I am happy to change them.
Yes, I would be interested in having a performance test for this. Do
you have an idea
On Fri, Jun 21, 2013 at 04:42:41PM +0100, Colin Guthrie wrote:
Did you read Lennart's reply?
Only after responding. ;)
I can also assure you that when there was a bug in this cache window
code about eight months ago it was quite obvious. This was fixed
On Mon, Apr 08, 2013 at 07:06:44PM +0200, Lennart Poettering wrote:
Is it really needed to determine the cgroup of /proc/1 on every message?
Couldn't journald keep the variables for its identity around?
a) use gcc's __thread support, i.e. have one static cache var per
thread. Since all
From: Holger Hans Peter Freyther hol...@moiji-mobile.com
Avoid memory allocations to construct the path for files in the
procfs. The procfs paths are way shorter than the PATH_MAX so we
can use snprintf on a string located on the stack. This shows up
as a win on x86 using the benchmark program
Are these allowed/expected to be changed during the runtime of the
journald?
Holger Hans Peter Freyther (2):
RFC: journald: Do not always record _AUDIT_SESSION and
_AUDIT_LOGINUID
RFC: journald: Do not dynamically allocate _UID/_GID/_PID strings
src/journal/journald-server.c | 26
When systemd was compiled without audit support, do not collect the
audit session and loginuid in the journal. This is saving a couple of
syscalls and memory allocations per log message.
---
src/journal/journald-server.c |4
1 file changed, 4 insertions(+)
diff --git
Avoid the dynamic allocation for the _UID, _GID, and _PID strings.
The maximum size of the string can be determined at compile time.
The code has only been compile tested.
---
src/journal/journald-server.c | 22 ++
1 file changed, 14 insertions(+), 8 deletions(-)
diff
On Fri, Apr 05, 2013 at 05:44:34AM +0200, Zbigniew Jędrzejewski-Szmek wrote:
Good Morning,
It seems that this function must be invoked a bizillion times,
so making it a bit leaner probably makes sense. Your implicit
assumpition that the field is not prefixed by whitespace is
almost certainly
On Tue, Feb 19, 2013 at 03:27:02AM +0100, Lennart Poettering wrote:
Well, to be fair: if an app just prints a couple of log messages, then
the functions you point out should hardly matter... Optimize inner
loops, not just the stuff that happens to be called a couple of
times...
I agree, with
On Mon, Feb 18, 2013 at 08:47:44AM -0800, David Strauss wrote:
Dear David, all,
It's possible that a lot of it could also allocate on the stack or use
stack-style management of a pool in heap. This is pretty
performance-critical code, and we're seeing similar CPU overhead.
I think upstream
From: Holger Hans Peter Freyther hol...@moiji-mobile.com
---
man/sd-id128.xml |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/man/sd-id128.xml b/man/sd-id128.xml
index abd2004..ac2000e 100644
--- a/man/sd-id128.xml
+++ b/man/sd-id128.xml
@@ -112,7 +112,7
From: Holger Hans Peter Freyther hol...@moiji-mobile.com
---
man/binfmt.d.xml |1 +
man/modules-load.d.xml |1 +
man/sysctl.d.xml |1 +
man/systemd.preset.xml |2 ++
man/tmpfiles.d.xml |1 +
5 files changed, 6 insertions(+)
diff --git a/man/binfmt.d.xml b/man
On Wed, Sep 19, 2012 at 02:20:42PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
On Wed, Sep 19, 2012 at 12:02:55PM +0200, Holger Hans Peter Freyther wrote:
Hi,
Hey,
Files in /etc/ override files with the same name in /usr/lib/ and
/run/. Files in /run/ override files with the same name
48 matches
Mail list logo