Re: [systemd-devel] Why do stop jobs run asynchronously on systemctl isolate target?
Hi, Lets talk on an example. Say we have a target, A.target, that has 100 services starting up and B.target which has only 1 service to start out of 100 services that have been started by A.target. When switching from A.target to B.target, systemctl isolate B.target will return immediately, systemctl is-active B.target will tell is-active immediately. But, I think switching hasn't been completed since 99 services that are started by A.target are being stopped in the background. My thought is, B.target is NOT active until all the services are started and all the services are stopped. Do we need to add After=, Before= to all 99 services against B.target? Is there a better way? Ex: systemctl isolate B.target --wait-for-stop-jobs I am using systemctl list-jobs to ensure that all the stop jobs are also completed. Thanks On Sat, Mar 23, 2013 at 3:43 AM, Lennart Poettering lenn...@poettering.netwrote: On Fri, 08.03.13 14:38, Umut Tezduyar (u...@tezduyar.com) wrote: Hi, I have realized that return of systemctl isolate target command is only synchronous for starting jobs but not for stopping jobs. How can one Well, it is synchronous to jobs that are ordered against the unit you isolate, this isn't any different from any other unit ordering... You might simply need to add an After= or Before= dependency? Not that when a unit is started and another one is stopped and they are ordered against each other, the one to be stopped is first stopped, before the one to be started is started, regardless whether After= or Before= was used. Or in other words: the difference between After= and Before= only has an effect on the order of two jobs that are started, or two jobs that are stopped, but not on two jobs where one is started and the other is stopped. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Ordering for early initialization services
Hi, My concern was being forward compatible with systemd and you have addressed my concern. Thank you. On Sat, Mar 23, 2013 at 3:55 AM, Lennart Poettering lenn...@poettering.netwrote: On Fri, 08.03.13 14:12, Umut Tezduyar (u...@tezduyar.com) wrote: Hi, What would be the advantage of placing an early boot up script in between local-fs.target/sysinit.target OR in between sysinit.target/basic.target? That's a very good question. This hopefully gives a bit of an explanation: http://www.freedesktop.org/software/systemd/man/bootup.html The difference is not that big actually. Basically, sysinit.target is supposed to be the barrier before which all the OS vendor system initialization stuff is finished. And then basic.target is the barrier before normal user services are started. In between the two we initialize the sockets currently, and only really those. i.e. units that belong to the user, but should run before the actual services are started. I plan to introduce paths.target and timers.target in a similar fashion soonishly. Also, as soon as we have kdbus support in systemd we will do bus name registration the same way. I.e. there will be a new unit type .busname for establishing bus names, and they by default are established between sysinit.target and busnames.target or so. Now, some of systemd's own services aren't entirely consistent between what it puts before sysinit.target and what before basic.target. But this is something we should clean up. But in general the rule is: you should place your early-boot stuff *before sysinit.target*. And your late-boot stuff *after basic.target*. And leave everything in between for .socket, .path, .timer, .busname units. I cannot decide what should be the ordering for some early initialization oneshot services I have in my embedded system. These services makes some simple preparations that were previously in /rcS.d/. Dropped support for /rcS.d/ in systemd was placing these services as After=sysinit.target and WantedBy=sysinit.target (and I am not entirely sure but possibly Before=basic.target). I could place them as systemd did before or I could place them as After=local-fs.target and Before=sysinit.target. Since my embedded system doesn't have login prompt, I don't see the difference between basic.target and sysinit.target other than socket activation. Even then, a service that is socket activated has DefaultDependency=yes (It will start after basic.target). To summarize, where are users encouraged to place their early boot up initialization services (ex: setting up the bandwith on a NIC)? sysinit.target! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix LSB Provides handling
Le vendredi 22 mars 2013 à 23:53 +0100, Lennart Poettering a écrit :
On Thu, 21.03.13 17:04, Frederic Crozat (fcro...@suse.com) wrote:
Hi all,
in https://bugzilla.novell.com/show_bug.cgi?id=809646 we noticed LSB
Provides can sometime be incorrectly handled (resulting in Failed to
add LSB Provides name .service, ignoring: File exists errors),
depending on initscript parsing order (if a provides is required by
another initscript and this initscript is parsed before the one with the
provides).
Can you explain the problem in more detail? Not following here.
Yes, sorry, I didn't give our test example :
Let's say you have two initscripts, A and B:
A contains in its LSB header:
Required-Start: C
and B contains in its LSB header:
Provides: C
When systemd is parsing /etc/rc.d/, depending on the file order, you can
end up with:
- B is parsed first. An unit C.service will be created and will be
added as additional name to B.service, with unit_add_name. No bug.
- A is parsed first. An unit C.service is created for the
Required-Start dependency (it will have no file attached, since
nothing provides this dependency yet). Then B is parsed and when trying
to handle Provides: C, unit_add_name is called but will fail, because
C.service already exists in manager-units. Therefore, a merge should
occur for that case.
Also, whitespace/coding style issues.
Will fix.
Hmm, and also, unit_merge_by_name() looks like the easier way here, as
it does pretty much what you do here anyway
Indeed. I overlooked it..
New patch attached.
--
Frederic Crozat fcro...@suse.com
SUSE
From d43a9dc530261506b62c257021c8433d5bf25388 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Thu, 21 Mar 2013 15:40:45 +0100
Subject: [PATCH] core: ensure LSB Provides are handled correctly
Depending on initscript reading order, one initscript might
reference as a Required-Start/Should-Start dependency another
initscript provides, before initscript containing provides has been
parsed and the corresponding in-memory unit has been created. This
change ensure the unit created for the dependency is merged with the
one containing the provides.
---
src/core/service.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/service.c b/src/core/service.c
index 080d583..5c7d919 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -765,7 +765,7 @@ static int service_load_sysv_path(Service *s, const char *path) {
continue;
if (unit_name_to_type(m) == UNIT_SERVICE)
-r = unit_add_name(u, m);
+r = unit_merge_by_name (u, m);
else
/* NB: SysV targets
* which are provided
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix LSB Provides handling
'Twas brillig, and Frederic Crozat at 25/03/13 10:14 did gyre and gimble: Le vendredi 22 mars 2013 à 23:53 +0100, Lennart Poettering a écrit : On Thu, 21.03.13 17:04, Frederic Crozat (fcro...@suse.com) wrote: Hi all, in https://bugzilla.novell.com/show_bug.cgi?id=809646 we noticed LSB Provides can sometime be incorrectly handled (resulting in Failed to add LSB Provides name .service, ignoring: File exists errors), depending on initscript parsing order (if a provides is required by another initscript and this initscript is parsed before the one with the provides). Can you explain the problem in more detail? Not following here. Yes, sorry, I didn't give our test example : Let's say you have two initscripts, A and B: A contains in its LSB header: Required-Start: C and B contains in its LSB header: Provides: C When systemd is parsing /etc/rc.d/, depending on the file order, you can end up with: - B is parsed first. An unit C.service will be created and will be added as additional name to B.service, with unit_add_name. No bug. - A is parsed first. An unit C.service is created for the Required-Start dependency (it will have no file attached, since nothing provides this dependency yet). Then B is parsed and when trying to handle Provides: C, unit_add_name is called but will fail, because C.service already exists in manager-units. Therefore, a merge should occur for that case. Is this explanation perhaps worthy of going in the commit message? It was all very clear when I read this extended explanation but I didn't 100% grok it before :) Also, whitespace/coding style issues. Will fix. Sorry to be a pain, but technically the new, much leaner patch still contains a whitespace/coding style issue :p unit_merge_by_name should not have a space after it before it's parenthesis. Of course it's trivial for someone to do both those things above when merging, but. :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix LSB Provides handling
Le lundi 25 mars 2013 à 12:04 +, Colin Guthrie a écrit :
'Twas brillig, and Frederic Crozat at 25/03/13 10:14 did gyre and gimble:
Le vendredi 22 mars 2013 à 23:53 +0100, Lennart Poettering a écrit :
On Thu, 21.03.13 17:04, Frederic Crozat (fcro...@suse.com) wrote:
Hi all,
in https://bugzilla.novell.com/show_bug.cgi?id=809646 we noticed LSB
Provides can sometime be incorrectly handled (resulting in Failed to
add LSB Provides name .service, ignoring: File exists errors),
depending on initscript parsing order (if a provides is required by
another initscript and this initscript is parsed before the one with the
provides).
Can you explain the problem in more detail? Not following here.
Yes, sorry, I didn't give our test example :
Let's say you have two initscripts, A and B:
A contains in its LSB header:
Required-Start: C
and B contains in its LSB header:
Provides: C
When systemd is parsing /etc/rc.d/, depending on the file order, you can
end up with:
- B is parsed first. An unit C.service will be created and will be
added as additional name to B.service, with unit_add_name. No bug.
- A is parsed first. An unit C.service is created for the
Required-Start dependency (it will have no file attached, since
nothing provides this dependency yet). Then B is parsed and when trying
to handle Provides: C, unit_add_name is called but will fail, because
C.service already exists in manager-units. Therefore, a merge should
occur for that case.
Is this explanation perhaps worthy of going in the commit message? It
was all very clear when I read this extended explanation but I didn't
100% grok it before :)
Also, whitespace/coding style issues.
Will fix.
Sorry to be a pain, but technically the new, much leaner patch still
contains a whitespace/coding style issue :p
unit_merge_by_name should not have a space after it before it's parenthesis.
Of course it's trivial for someone to do both those things above when
merging, but. :)
New patch version, this time with the improved commit message and space
error fixed.
--
Frederic Crozat fcro...@suse.com
SUSE
From a99435109b83e7146a30ccf5387037b51c1fe907 Mon Sep 17 00:00:00 2001
From: Frederic Crozat fcro...@suse.com
Date: Thu, 21 Mar 2013 15:40:45 +0100
Subject: [PATCH] core: ensure LSB Provides are handled correctly
Let's say you have two initscripts, A and B:
A contains in its LSB header:
Required-Start: C
and B contains in its LSB header:
Provides: C
When systemd is parsing /etc/rc.d/, depending on the file order, you
can end up with either:
- B is parsed first. An unit C.service will be created and will be
added as additional name to B.service, with unit_add_name. No bug.
- A is parsed first. An unit C.service is created for the
Required-Start dependency (it will have no file attached, since
nothing provides this dependency yet). Then B is parsed and when trying
to handle Provides: C, unit_add_name is called but will fail, because
C.service already exists in manager-units. Therefore, a merge should
occur for that case.
---
src/core/service.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/service.c b/src/core/service.c
index 4451d38..fa8a1cb 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -762,7 +762,7 @@ static int service_load_sysv_path(Service *s, const char *path) {
continue;
if (unit_name_to_type(m) == UNIT_SERVICE)
-r = unit_add_name(u, m);
+r = unit_merge_by_name(u, m);
else
/* NB: SysV targets
* which are provided
--
1.8.1.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] libsystemd-bus + kdbus plans
On 20/03/13 22:35, Lennart Poettering wrote: kdbus is a new kernel implementation of D-Bus that Kay and Greg have been working on. Please talk to the D-Bus maintainers about any reimplementations or replacements for D-Bus; we are on d...@lists.freedesktop.org. (Cross-posted.) Which parts of the D-Bus Specification does kdbus use? * I assume it uses the type system and the concepts of object paths and bus names, otherwise it'd be a pretty big stretch to call it D-Bus at all. * Does it have the same message semantics as traditional D-Bus in terms of message headers, senders being unforgeable unique names, broadcast/unicast signals, unicast method calls, unicast replies/errors, guaranteed delivery, stuff like that? * Does it have the same ordering guarantees (messages are totally-ordered) as D-Bus? If not, what partial-ordering guarantees *does* it give? (Causal ordering, perhaps?) * Does it use the D-Bus message serialization format (wire format)? * Does it use the D-Bus SASL handshake? d) Port gdbus + classic libdbus.so to become clients for kdbus, too. How do the other reimplementations of D-Bus (I am aware of at least ndesk-dbus (C#), dbus-java, haskell-dbus, and Net::DBus (Perl)) interact with kdbus? For instance, is there a bridge to the traditional D-Bus wire protocol over Unix/IP/IPv6 stream sockets? As far as I understand it, in the AF_BUS patchsets, the dbus-daemon listened on both AF_BUS and stream sockets and bridged messages where necessary, allowing interoperability without a flag day (AF_BUS-to-AF_BUS messages bypassed the dbus-daemon entirely, while AF_BUS-to-stream and stream-to-stream messages continued to pass through the dbus-daemon). Obviously, anything requiring the performance gains of a kernel-assisted transport still requires porting, but there doesn't have to be a flag day. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] libsystemd-bus + kdbus plans
On Mon, Mar 25, 2013 at 01:06:57PM +, Simon McVittie wrote: On 20/03/13 22:35, Lennart Poettering wrote: kdbus is a new kernel implementation of D-Bus that Kay and Greg have been working on. Please talk to the D-Bus maintainers about any reimplementations or replacements for D-Bus; we are on d...@lists.freedesktop.org. (Cross-posted.) Which parts of the D-Bus Specification does kdbus use? The ideas only, the wire protocol is quite different, and in reality, unknown as it isn't implemented yet, so all of your questions are a bit premature, sorry. d) Port gdbus + classic libdbus.so to become clients for kdbus, too. How do the other reimplementations of D-Bus (I am aware of at least ndesk-dbus (C#), dbus-java, haskell-dbus, and Net::DBus (Perl)) interact with kdbus? For instance, is there a bridge to the traditional D-Bus wire protocol over Unix/IP/IPv6 stream sockets? Again, unknown, give us some time to get there. As far as I understand it, in the AF_BUS patchsets, the dbus-daemon listened on both AF_BUS and stream sockets and bridged messages where necessary, allowing interoperability without a flag day (AF_BUS-to-AF_BUS messages bypassed the dbus-daemon entirely, while AF_BUS-to-stream and stream-to-stream messages continued to pass through the dbus-daemon). Obviously, anything requiring the performance gains of a kernel-assisted transport still requires porting, but there doesn't have to be a flag day. And odds are, there will not need to be a flag-day here either, if the library ends up being plug-in compatible for userspace applications. Which is the goal. thanks for your patience, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] libsystemd-bus + kdbus plans
On 25/03/13 13:28, Greg KH wrote: The ideas only, the wire protocol is quite different, and in reality, unknown as it isn't implemented yet, so all of your questions are a bit premature, sorry. Sure. When you have (proposed) answers to these questions, please talk to the D-Bus maintainers before advertising anything as ready for use as a replacement for D-Bus; or if you have questions of your own, the dbus mailing list is a good place to ask. What I would particularly like to avoid is something that calls itself D-Bus but does not have compatible semantics. Not everything that can be said about D-Bus is immediately obvious, and I'd like to avoid having to rediscover what its users rely on. My questions about kdbus should illustrate some of the areas that should be considered. And odds are, there will not need to be a flag-day [for dbus-java etc.] either, if the library ends up being plug-in compatible for userspace applications. Which is the goal. Please note that there are two broad classes of D-Bus libraries: * Wrappers around libdbus (such as QtDBus, dbus-glib, Upstart's libnih, and dbus-python). These use libdbus' public API, and can use alternative transports (even those not based on sockets) as soon as libdbus can, as long as those alternative transports provide compatible semantics. * Complete implementations of the D-Bus protocol (such as libdbus itself, GDBus, dbus-java, and now libsystemd-bus). These implement the whole protocol and do not share code with each other; replacing libdbus does not help the rest of these. libdbus' shortcomings as a bindable library, and its inconvenient licensing (GPL|AFL dual-license, unable to be changed due to a copyright holder that has gone out of business), have led to an increasing number of reimplementations, particularly for high-level languages and in environments where the LGPL or a BSD-style license is conventional. S ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] libsystemd-bus + kdbus plans
On Mon, 25.03.13 13:06, Simon McVittie (simon.mcvit...@collabora.co.uk) wrote: On 20/03/13 22:35, Lennart Poettering wrote: kdbus is a new kernel implementation of D-Bus that Kay and Greg have been working on. Please talk to the D-Bus maintainers about any reimplementations or replacements for D-Bus; we are on d...@lists.freedesktop.org. (Cross-posted.) Well, the kernel code isn't really there yet, as mentioned. We first need to figure out what we want precisely, and want to have some code. Which parts of the D-Bus Specification does kdbus use? * I assume it uses the type system and the concepts of object paths and bus names, otherwise it'd be a pretty big stretch to call it D-Bus at all. * Does it have the same message semantics as traditional D-Bus in terms of message headers, senders being unforgeable unique names, broadcast/unicast signals, unicast method calls, unicast replies/errors, guaranteed delivery, stuff like that? * Does it have the same ordering guarantees (messages are totally-ordered) as D-Bus? If not, what partial-ordering guarantees *does* it give? (Causal ordering, perhaps?) * Does it use the D-Bus message serialization format (wire format)? Pretty much all of the above, though Ryan wants us to adopt GVariant as serialization, but this is mostly orthogonal to the transport. The way we want this to work is that the kernel never actually looks into the message body, and does filtering only via pre-calculated bloom filters attached to each message. As long as all client libraries understand all different serialization methods we can replace the serialization freely. But anyway, adopting GVariant for this, might make sense (because we want something 64bit-safe, which the classic dbus serialization is not), but as mentioned the kernel wouldn't care. * Does it use the D-Bus SASL handshake? No. The kdbus stuff is kernel only, and access is controlled via file access modes on the device node of the specific bus. d) Port gdbus + classic libdbus.so to become clients for kdbus, too. How do the other reimplementations of D-Bus (I am aware of at least ndesk-dbus (C#), dbus-java, haskell-dbus, and Net::DBus (Perl)) interact with kdbus? For instance, is there a bridge to the traditional D-Bus wire protocol over Unix/IP/IPv6 stream sockets? We can do such a bridge (in fact, systemd will ship one anyway, since we support dbus-via-ssh as a transport to access commands on other systems). However, these other dbus implementations are not really my priority, but of course would welcome if they are ported sooner or later. As far as I understand it, in the AF_BUS patchsets, the dbus-daemon listened on both AF_BUS and stream sockets and bridged messages where necessary, allowing interoperability without a flag day (AF_BUS-to-AF_BUS messages bypassed the dbus-daemon entirely, while AF_BUS-to-stream and stream-to-stream messages continued to pass through the dbus-daemon). Obviously, anything requiring the performance gains of a kernel-assisted transport still requires porting, but there doesn't have to be a flag day. Well, the flag day is mostly regarding the policy stuff. We don't want to support the current policy in the kernel, and thus we'd require userspace services to fix their stuff to not really on it first... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] libsystemd-bus + kdbus plans
On segunda-feira, 25 de março de 2013 13.06.57, Simon McVittie wrote: Please talk to the D-Bus maintainers about any reimplementations or replacements for D-Bus; we are on d...@lists.freedesktop.org. (Cross-posted.) Thanks for the cross-posting, Simon. I have now found the thread on systemd- devel showing the plans for kdbus. I'm wondering only why the plans for kdbus were never posted to the dbus@fd.o mailing list... I'll just attribute that to a minor oops. Anyway, here's the original for those in the D-Bus list and not in the systemd list (trimmed to the relevant parts about D-Bus): http://lists.freedesktop.org/archives/systemd-devel/2013-March/009797.html ==kdbus is a new kernel implementation of D-Bus that Kay and Greg have been working on. The userspace component of it will live in systemd, and libsystemd-bus is the first step towards it. This library will speak both kdbus and traditional dbus (we need this, in order to allow tools like systemctl -H to work, across hosts via a stream connection). Currently, the code I just pushed only does the latter. Moving things onto kdbus/libsystemd-bus is going to be a step-by-step process, happening over the coming year or so. We will try hard to make this transition smooth for distributions. Our rough plan is: a) stabilize what we have now b) port over systemctl and the other client side tools to libsystemd-bus, to see if it all works, and give the API a bit of a real-life check-up. When finished we will drop the dependency on classic libdbus.so, but will still use dbus-daemon. c) Finish up kdbus and port libsystemd-bus over to it. Get kdbus merged. d) Port gdbus + classic libdbus.so to become clients for kdbus, too. e) Flag day, switch over the system bus to kdbus, leave session bus as dbus-daemon. At the same time we will no longer support dbus-daemon for the system. This will add a hard dependency of systemd on a very new kernel version. However, to make this palatable we will try hard to keep kdbus.ko compilable out-of-tree and easily backportable. f) Flag day, switch over the session/user bus to kdbus too. dbus-daemon is not used anymore now. All three client libraries will be able to talk to either the new or the old server, so that apps don't really have to care. At least in the ideal case. We try hard to keep breakage minimal, but we might not be able to avoid it entirely. The userspace part for setting up the busses will live in systemd. kdbus is not going to be available for non-systemd systems unless somebody sits down and writes an entirely independent bus userspace. kdbus is entirely different from AF_BUS. == -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [HEADSUP] libsystemd-bus + kdbus plans
On Mon, 25.03.13 08:07, Thiago Macieira (thi...@kde.org) wrote: On segunda-feira, 25 de março de 2013 13.06.57, Simon McVittie wrote: Please talk to the D-Bus maintainers about any reimplementations or replacements for D-Bus; we are on d...@lists.freedesktop.org. (Cross-posted.) Thanks for the cross-posting, Simon. I have now found the thread on systemd- devel showing the plans for kdbus. I'm wondering only why the plans for kdbus were never posted to the dbus@fd.o mailing list... I'll just attribute that to a minor oops. Nope, I didn't post this more widely on purpose. The thing here really is that we don't have working kernel code yet, so we don't really have too much to discuss here on the technical side with the dbus community. My mail to systemd-devel was intended to explain why there is now a libsystemd-bus module in systemd git, and what our plans are with that specific implementation are, nothing else. Of course we'll discuss the technical details with the wider dbus community as soon as we have something to show that is more than just yet another dbus client library... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-analyze: filter dot output with a regular expression
On Sun, 24.03.13 13:32, Łukasz Stelmach (stl...@poczta.fm) wrote:
Make systemd-analyze dot output only lines matching a regular
expression passed on the command line. Without the regular expression
print everything.
So far we mostly used globs everywhere in system. Does it really make
sense to use regexes here?
I mean, unit file names on purpose are file-name like, and generally
even show up in the file system, so it sounds more natural to me to use
fnmatch here?
static const char * const colors[] = {
Requires, [color=\black\],
@@ -591,6 +594,7 @@ static int graph_one_property(const char *name, const
char *prop, DBusMessageIte
After, [color=\green\]
};
+char buf[1024];
We generally avoid using fixed size strings like this. Use dynamic
memory for this if you can... i.e. asprintf(), and consider freeing it
with _cleanup_free_...
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFCv7] Add sync timer to journal server
On Sun, 24.03.13 01:11, Oleksii Shevchuk (alx...@gmail.com) wrote:
Add option to force journal sync with fsync. Default timeout is 5min.
Interval configured via SyncIntervalSec option at journal.conf. Synced
journal files will be marked as OFFLINE.
Manual sync can be performed via sending SIGUSR1.
Looks mostly good.
+int journal_file_set_online(JournalFile *f) {
+assert(f);
+
+if (!f-writable)
+return -EPERM;
+
+if (!(f-fd = 0 f-header))
+return -EINVAL;
+
+switch(f-header-state) {
+case STATE_ONLINE:
+return 0;
+
+case STATE_OFFLINE:
+f-header-state = STATE_ONLINE;
+return 0;
+
+default:
+return -EINVAL;
+}
+}
This needs an explit sync after the change. We need to make sure that
the online state has hit disk before any further changes are made to the
file. Otherwise the kernel might reorder things and flush later changes
to disk before the state change has hit disk. We really need an fsync()
or so after we changed the state.
+int journal_file_set_offline(JournalFile *f) {
+assert(f);
+
+if (!(f-header f-writable f-fd = 0))
+return -EINVAL;
+
+if (f-header-state != STATE_ONLINE)
+return 0;
+
+if (fsync(f-fd))
+return -errno;
+
+f-header-state = STATE_OFFLINE;
+
+if(fsync(f-fd))
+return -errno;
+
+return 0;
+}
I don't think we should really care about the return value of fsync()
here... I mean, flushing things like this is nice, but if we can't,
because maybe the underlying fs doesn't do support it we shouldn't care,
should we? I'd just invoke fsync() and ignore its return value?
Otherwise I am happy.
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] PATCH: fix LSB Provides handling
On Mon, 25.03.13 13:28, Frederic Crozat (fcro...@suse.com) wrote: New patch version, this time with the improved commit message and space error fixed. Applied, thanks! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] [RFCv8] Add sync timer to journal server
Add option to force journal sync with fsync. Default timeout is 5min.
Interval configured via SyncIntervalSec option at journal.conf. Synced
journal files will be marked as OFFLINE.
Manual sync can be performed via sending SIGUSR1.
---
man/journald.conf.xml| 10
src/journal/journal-file.c | 63 +-
src/journal/journal-file.h | 2 +
src/journal/journald-gperf.gperf | 1 +
src/journal/journald-server.c| 112 +--
src/journal/journald-server.h| 6 +++
src/journal/journald.conf| 1 +
7 files changed, 179 insertions(+), 16 deletions(-)
diff --git a/man/journald.conf.xml b/man/journald.conf.xml
index 0797deb..0b9de65 100644
--- a/man/journald.conf.xml
+++ b/man/journald.conf.xml
@@ -322,6 +322,16 @@
seconds. /para/listitem
/varlistentry
+
+varlistentry
+
termvarnameSyncIntervalSec=/varname/term
+
+listitemparaThe timeout before syncing
journal
+data to disk. After syncing journal files have
+OFFLINE state. Default timeout is 5 minutes.
+/para/listitem
+/varlistentry
+
varlistentry
termvarnameForwardToSyslog=/varname/term
termvarnameForwardToKMsg=/varname/term
diff --git a/src/journal/journal-file.c b/src/journal/journal-file.c
index 13fc8ed..5b077be 100644
--- a/src/journal/journal-file.c
+++ b/src/journal/journal-file.c
@@ -68,6 +68,50 @@
/* How many entries to keep in the entry array chain cache at max */
#define CHAIN_CACHE_MAX 20
+int journal_file_set_online(JournalFile *f) {
+assert(f);
+
+if (!f-writable)
+return -EPERM;
+
+if (!(f-fd = 0 f-header))
+return -EINVAL;
+
+switch(f-header-state) {
+case STATE_ONLINE:
+return 0;
+
+case STATE_OFFLINE:
+f-header-state = STATE_ONLINE;
+fsync(f-fd);
+return 0;
+
+default:
+return -EINVAL;
+}
+}
+
+int journal_file_set_offline(JournalFile *f) {
+assert(f);
+
+if (!f-writable)
+return -EPERM;
+
+if (!(f-fd = 0 f-header))
+return -EINVAL;
+
+if (f-header-state != STATE_ONLINE)
+return 0;
+
+fsync(f-fd);
+
+f-header-state = STATE_OFFLINE;
+
+fsync(f-fd);
+
+return 0;
+}
+
void journal_file_close(JournalFile *f) {
assert(f);
@@ -81,16 +125,10 @@ void journal_file_close(JournalFile *f) {
if (f-mmap f-fd = 0)
mmap_cache_close_fd(f-mmap, f-fd);
-if (f-writable f-fd = 0)
-fdatasync(f-fd);
-
-if (f-header) {
-/* Mark the file offline. Don't override the archived state if
it already is set */
-if (f-writable f-header-state == STATE_ONLINE)
-f-header-state = STATE_OFFLINE;
+journal_file_set_offline(f);
+if (f-header)
munmap(f-header, PAGE_ALIGN(sizeof(Header)));
-}
if (f-fd = 0)
close_nointr_nofail(f-fd);
@@ -177,7 +215,7 @@ static int journal_file_refresh_header(JournalFile *f) {
f-header-boot_id = boot_id;
-f-header-state = STATE_ONLINE;
+journal_file_set_online(f);
/* Sync the online state to disk */
msync(f-header, PAGE_ALIGN(sizeof(Header)), MS_SYNC);
@@ -457,6 +495,10 @@ int journal_file_append_object(JournalFile *f, int type,
uint64_t size, Object *
assert(offset);
assert(ret);
+r = journal_file_set_online(f);
+if (r 0)
+return r;
+
p = le64toh(f-header-tail_object_offset);
if (p == 0)
p = le64toh(f-header-header_size);
@@ -1267,9 +1309,6 @@ int journal_file_append_entry(JournalFile *f, const
dual_timestamp *ts, const st
assert(f);
assert(iovec || n_iovec == 0);
-if (!f-writable)
-return -EPERM;
-
if (!ts) {
dual_timestamp_get(_ts);
ts = _ts;
diff --git a/src/journal/journal-file.h b/src/journal/journal-file.h
index cdbc8e4..0eab501 100644
--- a/src/journal/journal-file.h
+++ b/src/journal/journal-file.h
@@ -106,6 +106,8 @@ int journal_file_open(
JournalFile *template,
JournalFile **ret);
+int journal_file_set_offline(JournalFile *f);
+int journal_file_set_online(JournalFile *f);
void journal_file_close(JournalFile *j);
int journal_file_open_reliably(
diff --git
Re: [systemd-devel] [PATCH 2/3] unit: do not care if order isn't right when retroactively starting deps
On 03/23/2013 03:14 AM, Lennart Poettering wrote: On Wed, 13.03.13 01:44, Michal Schmidt (mschm...@redhat.com) wrote: Attempt to satisfy requirement dependencies retroactively even if the unexpectedly activated unit would prefer to be started After them. This way remote-fs-pre.target can be pulled in by performing a manual mount (the mount units have both Wants= and After= remote-fs-pre.target). I am a bit concerned abou this. Wouldn't this also mean that if a mount for /foobar/waldo suddenly shows up we'd still retroactively mount /foobar too, if that happens to have a unit file? That sounds wrong, no? You are right. It would do exactly this wrong thing. I need to rethink. Michal ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFCv8] Add sync timer to journal server
On Mon, 25.03.13 18:49, Oleksii Shevchuk (alx...@gmail.com) wrote: Add option to force journal sync with fsync. Default timeout is 5min. Interval configured via SyncIntervalSec option at journal.conf. Synced journal files will be marked as OFFLINE. Manual sync can be performed via sending SIGUSR1. Applied! Thanks! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] [RFC][PLEASE TEST] readahead: chunk on spinning media
Le vendredi 22 mars 2013 à 15:22 -0700, Auke Kok a écrit : Readahead has all sorts of bad side effects depending on your storage media. On rotating disks, it may be degrading startup performance if enough requests are queued spanning linearly over all blocks early at boot, and mount, blkid and friends want to insert reads to the start of these block devices after. The end result is that on spinning disks with ext3/4 that udev and mounts take a very long time, and nothing really happens until readahead is completely finished. This has the net effect that the CPU is almost entirely idle for the entire period that readahead is working. We could have finished starting up quite a lot of services in this time if we were smarter at how we do readahead. This patch sorts all requests into 2 second chunks and sub-sorts each chunk by block. This adds a single cross-drive seek per chunk but has the benefit that we will have a lot of the blocks we need early on in the boot sequence loaded into memory faster. For a comparison of how before/after bootcharts look (ext4 on a mobile 5400rpm 250GB drive) please look at: http://foo-projects.org/~sofar/blocked-tests/ There are bootcharts in the before and after folders where you should be able to see that many low-level services finish 5-7 seconds earlier with the patch applied (after). I've checked on my test netbook system and I can confirm your findings (with ext4 as fs), gain is around 3s, compared to the old readahead in systemd which was sometime slowing boot by 3s, compared to no readahead. I'd say commit it :) -- Frederic Crozat fcro...@suse.com SUSE ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] units/u...@.service.in
On Fri, 22.03.13 21:46, Auke-Jan Kok (a...@kemper.freedesktop.org) wrote: units/u...@.service.in | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) New commits: commit 3abcb6acedb588ca17f6374c1836f8a58396e520 Author: Auke Kok auke-jan.h@intel.com Date: Fri Mar 22 21:43:31 2013 -0700 Update user session unit template. While most folks will be using the derivative from user-session-units, I'm updating this one to reflect some of the fixes and things to note about user sessions: - cgroup should be set with %u - username instead of %I - set dbus path with %U explicitly too - hint to folks that wish to use MEM_CG features in user sessions - allow unit to be enabled for instances with systemctl enable Hmm, with the old %I wouldn't it suffice to instantiate the unit via user@USERNAME.service rather than user@UID.service? I mean, I am not against this patch, just noticing this... diff --git a/units/u...@.service.in b/units/u...@.service.in index 2c15495..901a334 100644 --- a/units/u...@.service.in +++ b/units/u...@.service.in @@ -6,14 +6,18 @@ # (at your option) any later version. [Unit] -Description=User Manager for %I +Description=User Manager for %u After=systemd-user-sessions.service [Service] User=%I PAMName=systemd-shared -ControlGroup=%R/user/%I/shared cpu:/ +# in order to allow MEM_CG features to work, add memory:/ here +ControlGroup=%R/user/%u/shared cpu:/ ControlGroupModify=yes Type=notify ExecStart=-@rootlibexecdir@/systemd --user -Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket +Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%U/dbus/user_bus_socket + +[Install] +Alias=user@%i.service ___ systemd-commits mailing list systemd-comm...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-commits Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Why do stop jobs run asynchronously on systemctl isolate target?
On Mon, 25.03.13 09:54, Umut Tezduyar (u...@tezduyar.com) wrote: Hi, Lets talk on an example. Say we have a target, A.target, that has 100 services starting up and B.target which has only 1 service to start out of 100 services that have been started by A.target. When switching from A.target to B.target, systemctl isolate B.target will return immediately, systemctl is-active B.target will tell is-active immediately. But, I think switching hasn't been completed since 99 services that are started by A.target are being stopped in the background. My thought is, B.target is NOT active until all the services are started and all the services are stopped. Do we need to add After=, Before= to all 99 services against B.target? Is there a better way? Ex: systemctl isolate B.target --wait-for-stop-jobs I can see how that would be nasty... Hmm, I need to think about this one. What you basically want here is an implicit dependency that exists only during the isolation transaction but not necessarily normally... Grr, the curernt model doesn't allow that. Michal, do you have any ideas on this one? (For now I added this to the TODO list. This is something to think about, but I don't have a good idea what we can do about it...) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-analyze: filter dot output with a regular expression
It was 2013-03-25 pon 16:48, when Lennart Poettering wrote:
On Sun, 24.03.13 13:32, Łukasz Stelmach (stl...@poczta.fm) wrote:
Make systemd-analyze dot output only lines matching a regular
expression passed on the command line. Without the regular expression
print everything.
So far we mostly used globs everywhere in system. Does it really make
sense to use regexes here?
I mean, unit file names on purpose are file-name like, and generally
even show up in the file system, so it sounds more natural to me to use
fnmatch here?
Sounds reasonable and probably would be enough. I'll change it and see
how it suits me.
static const char * const colors[] = {
Requires, [color=\black\],
@@ -591,6 +594,7 @@ static int graph_one_property(const char *name, const
char *prop, DBusMessageIte
After, [color=\green\]
};
+char buf[1024];
We generally avoid using fixed size strings like this. Use dynamic
memory for this if you can... i.e. asprintf(), and consider freeing it
with _cleanup_free_...
Sure. I haven't looked around too much before to see you do things like
this. I'll change it.
--
Łukasz Stelmach
Software wizzard
Samsung Poland RD Center
Al. Armii Ludowej 26, 00-609 Warszawa
http://www.rd.samsung.pl
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: handle mount units with x-rootfs.mount
On Sat, 23.03.13 14:35, Harald Hoyer (harald.ho...@gmail.com) wrote: What Lennart meant was: all the initrd things should stick to one and the same prefix x-initrd.* and not invent new top-level prefixes with x-initrd-*. well, so, x-initrd.rootfs-mount ?? I have now taken the liberty to rename it to x-initrd.rootfs. I hope that makes sense? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: handle mount units with x-rootfs.mount
On Mon, 25.03.13 18:31, Lennart Poettering (lenn...@poettering.net) wrote: On Sat, 23.03.13 14:35, Harald Hoyer (harald.ho...@gmail.com) wrote: What Lennart meant was: all the initrd things should stick to one and the same prefix x-initrd.* and not invent new top-level prefixes with x-initrd-*. well, so, x-initrd.rootfs-mount ?? I have now taken the liberty to rename it to x-initrd.rootfs. I hope that makes sense? BTW, this really needs some documentation... Either in systemd.mount(5) (along with the x-systemd. mount options), or in systemd-fstab-generator(8) or in the wiki (though the latter isn't writable right now). Could you prep something? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] build-sys: configurable debug shell tty path
On Sat, Mar 23, 2013 at 3:00 AM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 14.03.13 14:58, Umut Tezduyar (u...@tezduyar.com) wrote: Hmm, do we really want this configurable? I mean, it's a debug shell, not more... Generally we have been very conservative with making too many things configurable here at build-time, since we don't actually want to encourage people more than necessary to deviate here, for bike-shedding-style questions such as Which VT is my debug shell on?. Anyway, I am not totally opposed, but can you make a good case for it? (Also, should we merge this, please replace the subst name with something uppercase. The lowercase bits are only used for paths really, i guess.) http://cgit.freedesktop.org/systemd/systemd/commit/?id=d95fd3df5997b0dab8650d9427997d295d0975e3 Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: handle mount units with x-rootfs.mount
On Mon, 25.03.13 18:42, Lennart Poettering (lenn...@poettering.net) wrote: What Lennart meant was: all the initrd things should stick to one and the same prefix x-initrd.* and not invent new top-level prefixes with x-initrd-*. well, so, x-initrd.rootfs-mount ?? I have now taken the liberty to rename it to x-initrd.rootfs. I hope that makes sense? BTW, this really needs some documentation... Either in systemd.mount(5) (along with the x-systemd. mount options), or in systemd-fstab-generator(8) or in the wiki (though the latter isn't writable right now). Could you prep something? And these docs really should be linked up from the units with Documentation= stanzas... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add BUILD_ID to os-release
On Fri, Mar 22, 2013 at 4:00 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 20.03.13 14:54, William Douglas (william.doug...@intel.com) wrote: BUILD_ID is a generic field that can uniquely identify all a distributions default packages in a release or image build when VERSION is used as broader identifier. Hmm, why wouldn't VERSION_ID= be enough for this purpose? We already have VERSION= as pretty version string, and VERSION_ID= as low-level computer-readable version, why do we need another? VERSION_ID can be seperate from BUILD_ID in that I could have two different versions with the same BUILD_ID (for example VERSION_ID 1.3 and 2.0 with BUILD_ID being the date + number of build 2013-03-23.5). Appending a BUILD_ID field could be done in my case (I can just use an underscore as a token to seperate but I don't think that it is something that will be simple to tokenize in the general case) I just thought it may be useful enough to have it be its own field. Also, the patch has line breaks in it, can't be merged that way... Hrm there isn't any odd characters that I can see from the mailing list though I seem to have messed it up copying into my mail client as git tells me it is malformed, sorry I don't send patches enough X(. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] units/u...@.service.in
On Mon, Mar 25, 2013 at 9:54 AM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 22.03.13 21:46, Auke-Jan Kok (a...@kemper.freedesktop.org) wrote: units/u...@.service.in | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) New commits: commit 3abcb6acedb588ca17f6374c1836f8a58396e520 Author: Auke Kok auke-jan.h@intel.com Date: Fri Mar 22 21:43:31 2013 -0700 Update user session unit template. While most folks will be using the derivative from user-session-units, I'm updating this one to reflect some of the fixes and things to note about user sessions: - cgroup should be set with %u - username instead of %I - set dbus path with %U explicitly too - hint to folks that wish to use MEM_CG features in user sessions - allow unit to be enabled for instances with systemctl enable Hmm, with the old %I wouldn't it suffice to instantiate the unit via user@USERNAME.service rather than user@UID.service? I mean, I am not against this patch, just noticing this... Right, it will just work regardless now, so, less chance for problems. Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Add BUILD_ID to os-release
On Mon, 25.03.13 11:14, Douglas, William (william.doug...@intel.com) wrote: On Fri, Mar 22, 2013 at 4:00 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 20.03.13 14:54, William Douglas (william.doug...@intel.com) wrote: BUILD_ID is a generic field that can uniquely identify all a distributions default packages in a release or image build when VERSION is used as broader identifier. Hmm, why wouldn't VERSION_ID= be enough for this purpose? We already have VERSION= as pretty version string, and VERSION_ID= as low-level computer-readable version, why do we need another? VERSION_ID can be seperate from BUILD_ID in that I could have two different versions with the same BUILD_ID (for example VERSION_ID 1.3 and 2.0 with BUILD_ID being the date + number of build 2013-03-23.5). Appending a BUILD_ID field could be done in my case (I can just use an underscore as a token to seperate but I don't think that it is something that will be simple to tokenize in the general case) I just thought it may be useful enough to have it be its own field. OK. Makes sense I guess. Can you send an updated patch, with a more comprehensive explanation of the field, plz? Will merge it then. Might make sense to include a terse explanation pointing out why this is separate from VERSION_ID. Also, the patch has line breaks in it, can't be merged that way... Hrm there isn't any odd characters that I can see from the mailing list though I seem to have messed it up copying into my mail client as git tells me it is malformed, sorry I don't send patches enough X(. You could just attach the patch if you need to. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] fstab-generator: add missing strempty() calls
---
src/fstab-generator/fstab-generator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 7f065eb..9754f3a 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -403,7 +403,7 @@ static int parse_fstab(const char *prefix, bool initrd) {
if (errno == ENOENT)
return 0;
-log_error(Failed to open %s/etc/fstab: %m, prefix);
+log_error(Failed to open %s/etc/fstab: %m, strempty(prefix));
return -errno;
}
@@ -415,7 +415,7 @@ static int parse_fstab(const char *prefix, bool initrd) {
continue;
what = fstab_node_to_udev_node(me-mnt_fsname);
-where = strjoin(prefix, me-mnt_dir, NULL);
+where = strjoin(strempty(prefix), me-mnt_dir, NULL);
if (!what || !where) {
r = log_oom();
goto finish;
--
1.8.2.231.gddc3939
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: add missing strempty() calls
On Mon, 25.03.13 21:10, Mantas Mikulėnas (graw...@gmail.com) wrote:
Ouch. Applied! Thanks!
---
src/fstab-generator/fstab-generator.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 7f065eb..9754f3a 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -403,7 +403,7 @@ static int parse_fstab(const char *prefix, bool initrd) {
if (errno == ENOENT)
return 0;
-log_error(Failed to open %s/etc/fstab: %m, prefix);
+log_error(Failed to open %s/etc/fstab: %m,
strempty(prefix));
return -errno;
}
@@ -415,7 +415,7 @@ static int parse_fstab(const char *prefix, bool initrd) {
continue;
what = fstab_node_to_udev_node(me-mnt_fsname);
-where = strjoin(prefix, me-mnt_dir, NULL);
+where = strjoin(strempty(prefix), me-mnt_dir, NULL);
if (!what || !where) {
r = log_oom();
goto finish;
Lennart
--
Lennart Poettering - Red Hat, Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] systemd-analyze: refactor for more data collection
On Sun, Mar 24, 2013 at 11:23 AM, Umut Tezduyar u...@tezduyar.com wrote:
---
src/analyze/systemd-analyze.c | 119
+++--
1 files changed, 66 insertions(+), 53 deletions(-)
diff --git a/src/analyze/systemd-analyze.c b/src/analyze/systemd-analyze.c
index 01bf55e..3dcde30 100644
--- a/src/analyze/systemd-analyze.c
+++ b/src/analyze/systemd-analyze.c
@@ -70,7 +70,7 @@ struct boot_times {
usec_t userspace_time;
usec_t finish_time;
};
-struct unit_times {
+struct unit_stat {
char *name;
usec_t ixt;
usec_t iet;
hey,
almost half of this patch is about just renaming this struct... is
there a reason to do this at all? it seems like the old name is
actually better at describing the content.
Auke
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemd-analyze: filter dot output with a regular expression
W dniu 25.03.2013 16:48, Lennart Poettering pisze:
On Sun, 24.03.13 13:32, Łukasz Stelmach (stl...@poczta.fm) wrote:
Make systemd-analyze dot output only lines matching a regular
expression passed on the command line. Without the regular expression
print everything.
So far we mostly used globs everywhere in system. Does it really make
sense to use regexes here?
I mean, unit file names on purpose are file-name like, and generally
even show up in the file system, so it sounds more natural to me to use
fnmatch here?
Indeed fnmatch() is better for matching unit names, however, I match the
whole line:
multi-user.target-basic.target [color=green];
rather than the the unit names. To quickly match the line above I use
target.*target. A glob that does tha same is *target*target* not as
nice, is it? (This is because globs are implicitly anchored at the
beginning of strings while regexps are not)
I could use globs and match unit names but then the logic would have to
be a bit more complicated. If there is one glob given on the command
line then match either of the units. If two, then the first matches s
and the other c. With regexp this you can match the colour too with no
extra effort.
I am not quite sure fnmatch() with these constraints is better? RFC.
static const char * const colors[] = {
Requires, [color=\black\],
@@ -591,6 +594,7 @@ static int graph_one_property(const char *name, const
char *prop, DBusMessageIte
After, [color=\green\]
};
+char buf[1024];
We generally avoid using fixed size strings like this. Use dynamic
memory for this if you can... i.e. asprintf(), and consider freeing it
with _cleanup_free_...
Cool! Done ;-)
--
Było mi bardzo miło. Czwarta pospolita klęska, [...]
Łukasz Już nie katolicka lecz złodziejska. (c)PP
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] systemd-analyze: --type cpuacct option for blame
On Sun, Mar 24, 2013 at 11:23 AM, Umut Tezduyar u...@tezduyar.com wrote: systemd-analyze blame --type cpuacct displays cpu time usage information of the cgroup. The information displayed is cpuacct.usage. ControlGroup=cpuacct:/foo/bar for a service would work. ControlGroupPersistent=yes for a oneshot service keeps cpuacct around so blame can retrieve it. DefaultControllers=cpuacct on system.conf can be set to have cpuacct same as systemd cgroup. --- src/analyze/systemd-analyze.c | 131 + 1 files changed, 119 insertions(+), 12 deletions(-) So, I'm not against this patch per se, but, I'm wondering if it's not better to display this data in systemd-cgtop. After all, systemd-analyze is a one-time snapshot and suffers from data loss when services are restarted, etc. Having a method to show cpuacct totals in systemd-cgtop seems much more useful. You could modify the code to show totals instead of percentages, etc. Have you thought about doing that? Auke ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCHv2] man/os-release: Add BUILD_ID field
BUILD_ID is a fairly generic field used to identify the system image that was used to install the distribution. Signed-off-by: William Douglas william.doug...@intel.com --- man/os-release.xml | 22 ++ 1 file changed, 22 insertions(+) diff --git a/man/os-release.xml b/man/os-release.xml index 98320ef..45babd6 100644 --- a/man/os-release.xml +++ b/man/os-release.xml @@ -298,6 +298,28 @@ literalBUG_REPORT_URL=https://bugzilla.redhat.com/;/literal/para/listitem /varlistentry +varlistentry +termvarnameBUILD_ID=/varname/term + +listitemparaA string uniquely +identifying the system image used as +the origin for a distribution (it is +not updated with system updates). The +field can be identical between +different VERSION_IDs as BUILD_ID is +an only a unique identifier to a +specific version. Distributions that +release each update as a new version +would only need to use VERSION_ID as +each build is already distinct based +on the VERSION_ID. This field is +optional. Example: +literalBUILD_ID=2013-03-20.3/literal +or +literalBUILD_ID=201303203/literal. + +/para/listitem +/varlistentry /variablelist -- 1.8.1.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] unit: do not care if order isn't right when retroactively starting deps
On Mon, 25.03.13 17:49, Michal Schmidt (mschm...@redhat.com) wrote: On 03/23/2013 03:14 AM, Lennart Poettering wrote: On Wed, 13.03.13 01:44, Michal Schmidt (mschm...@redhat.com) wrote: Attempt to satisfy requirement dependencies retroactively even if the unexpectedly activated unit would prefer to be started After them. This way remote-fs-pre.target can be pulled in by performing a manual mount (the mount units have both Wants= and After= remote-fs-pre.target). I am a bit concerned abou this. Wouldn't this also mean that if a mount for /foobar/waldo suddenly shows up we'd still retroactively mount /foobar too, if that happens to have a unit file? That sounds wrong, no? You are right. It would do exactly this wrong thing. I need to rethink. As discussed on IRC I have now commited a patch that adds a new target remote-fs-setup.target which is now used to pull in things (without ordering), and is different from remote-fs-pre.target which is now used again to order things (without pulling things in). http://cgit.freedesktop.org/systemd/systemd/commit/?id=e8d2f6cde0af86eece9118718ad0a8a19e1cffec Now, I don't actually have any remote mounts here locally, so I am really looking for some feedback before I release this with 199. This is the last thing I wanted to get settled before 199, so I'd be very thankful if somebody could test this in a setup that actually makes sense. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
