[systemd-devel] [PATCH] corrected machine-info(5) man page to be in line with source
change conflicting man/machine-info.xml documentation to match functionality in src/hostname/hostnamed.c 114-119 --- man/machine-info.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/man/machine-info.xml b/man/machine-info.xml index c6d3e92..240da25 100644 --- a/man/machine-info.xml +++ b/man/machine-info.xml @@ -130,7 +130,7 @@ refsect1 titleExample/title -programlistingPRETTY_NAME=Lennart's Computer +programlistingPRETTY_HOSTNAME=Lennart's Computer ICON_NAME=computer-laptop/programlisting /refsect1 -- 1.7.9 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] corrected machine-info(5) man page to be in line with source
On Mon, 05.03.12 00:29, Shawn Landden (shawnland...@gmail.com) wrote: change conflicting man/machine-info.xml documentation to match functionality in src/hostname/hostnamed.c 114-119 --- man/machine-info.xml |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/man/machine-info.xml b/man/machine-info.xml index c6d3e92..240da25 100644 --- a/man/machine-info.xml +++ b/man/machine-info.xml @@ -130,7 +130,7 @@ refsect1 titleExample/title -programlistingPRETTY_NAME=Lennart's Computer +programlistingPRETTY_HOSTNAME=Lennart's Computer ICON_NAME=computer-laptop/programlisting /refsect1 Thanks, applied. 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] trust of kernel messages re-routed via journald
On Sun, Mar 4, 2012 at 11:37 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 23.02.12 17:54, Rainer Gerhards (rgerha...@gmail.com) wrote: Hi, I am thinking on how to detect potential fake messages, claiming to be e.g. from the audit subsystem. Let's assume - auditd is stopped -- audit messages are put into the kernel log - journald controls /dev/kmsg and provides these via the the journal log socket to syslogd I presume you mean /proc/kmsg here, not /dev/kmsg? doh, of course ;) Note that on F17 (and most likely for much longer) systemd does not take control of /proc/kmsg and leaves that to syslog-ng/rsyslog. Sure, but the question was with a bit broader scope, assuming this will change in the future. - syslogd uses SCM_CREDENTIALS on the journald provided socket Question now: what pid will I see inside SCM_CREDENTIALS (0, 1, s/t else)? I assume I can use the pid to tell the difference between a real message and a faked one from some user process. Is that a correct assumption? You will see systemd's own PID if we have no other sensible PID to fill in. And if a message originates from the kernel we have no PID. OK, so it will be 1, I guess the same like systemd emitted messages. Does it sound decent enough to check if the PID is 1 AND the facility is kernel THEN this message is actually from the kernel log? I am asking because a couple of folks handle messages differently just because of their origin. So I think how to emulate this previous behavior when running under Journal. Thanks, Rainer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] customized shutdown service needed
On Wed, 29.02.12 22:12, Burkhard Kayser (kayser-b-2...@t-online.de) wrote: Hi Lennart, based on your recommendation I tried the following service. [Unit] Description=my private startup service Requires=local-fs.target syslog.service nfs.service After=local-fs.target syslog.service nfs.service [Service] ExecStart=/etc/init.d/my_startup start ExecStop=/etc/init.d/my_startup stop Type=oneshot RemainAfterExit=yes TimeoutSec=600 [Install] WantedBy=multi-user.target If this is a sysv init script then systemd will start this service anyway, no need to write a unit file like the above. systemd provides a certain level of compatibility with sysv scripts. This service is started at the very end of the boot sequence. But stopped too late during shutdown. Too late? What do you mean by that? Feb 29 21:48:43 Linux1 logger: starting /etc/init.d/my_shutdown start (1) 1941 ... Feb 29 21:48:43 Linux1 logger: starting /etc/init.d/my_startup stop (1) 1937 ... Hmm, the idea here is that a systemd service is started at bootup, and stopped at shutdown. This output looks like you start and stop it at shutdown. Is there any similar replacement within systemd? Well, for that you actually have to explain after what and before what other services you want your service to be terminated. 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 sparse warnings
On Wed, 29.02.12 18:33, Frederic Crozat (fcro...@suse.com) wrote: Le mercredi 29 février 2012 à 17:04 +, Frederic Crozat a écrit : Hi, while trying to use sparse to detect potential endianness errors in journald code (apparently, we can't use it for that), I found some other warnings with sparse. Attached patch fixes those (mostly missing static call, 0 vs NULL and macros redefinition). Better with patch attached ;) From d07e3f17e21ad4b200d0e076e0f49a3f8e91fae9 Mon Sep 17 00:00:00 2001 From: Frederic Crozat fcro...@suse.com Date: Wed, 29 Feb 2012 14:42:49 +0100 Subject: [PATCH] fix sparse warnings Looks all good. Applied. I have little experience with sparse, but iirc it knows decorators for variables for le/be, right? Is this something we might want to use in the journal to avoid LE/BE issues like those you tracked down? 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] sd-login.h - g++ complains about 'class'
On Sat, 25.02.12 01:36, Mantas M. (graw...@gmail.com) wrote: When building gnome-system-monitor with systemd support, I get the following error message and compilation stops: In file included from proctable.cpp:49:0: /usr/include/systemd/sd-login.h:97:54: error: expected ‘,’ or ‘...’ before ‘class’ It seems that 'class' cannot be a variable name in C++. Fixed in git. 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 sparse warnings
Le lundi 05 mars 2012 à 15:10 +0100, Lennart Poettering a écrit : On Wed, 29.02.12 18:33, Frederic Crozat (fcro...@suse.com) wrote: Le mercredi 29 février 2012 à 17:04 +, Frederic Crozat a écrit : Hi, while trying to use sparse to detect potential endianness errors in journald code (apparently, we can't use it for that), I found some other warnings with sparse. Attached patch fixes those (mostly missing static call, 0 vs NULL and macros redefinition). Better with patch attached ;) From d07e3f17e21ad4b200d0e076e0f49a3f8e91fae9 Mon Sep 17 00:00:00 2001 From: Frederic Crozat fcro...@suse.com Date: Wed, 29 Feb 2012 14:42:49 +0100 Subject: [PATCH] fix sparse warnings Looks all good. Applied. I have little experience with sparse, but iirc it knows decorators for variables for le/be, right? Is this something we might want to use in the journal to avoid LE/BE issues like those you tracked down? Well, I spend almost a day trying to get sparse to spot endian-ness errors but couldn't get it to work properly :( The idea would be to replace any uint64_t type with __le64 (from /usr/include/linux/types.h) in data structures written on disk and make sure only function returning __le64 are used to modify those variables. Unfortunately, I wasn't able to teach sparse about htole64 / le64toh. Help welcome ;) -- 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] Display manager and logind interaction
On Wed, 15.02.12 19:42, Robert Ancell (robert.anc...@gmail.com) wrote: And on seats != seat0 we currently don't have any kind of session multiplexing. Hence having a special VT for lock screens is really hard to do... (I have actually discussed this topic with the Wayland guys at FOSDEM and we'll probably have userspace VT switching based on Wayland one day, but that's work for the future). Interesting; they are still considering the concepts of VTs still applicable? Well, userspace VT switching only means the rough idea of allowing multiple concurrent sessions on the same seat. Presumably it won't resemble too closely the current VT switching implemented in the Linux kernel, and the assignments of F1-F12 will probably be virtualized. I am tempted to say that until the moment we do VT switching in userspace with Wayland implementing proper lock screens is really hard, and probably not worth the effort. I hope we can work out something now, as this will come up in the future and if the API doesn't support it things are going to get messy. I think the current design is good enough so that we can rework this later without breaking too much compat. One option is to stop logind making the ioctl calls and leaving that to the DM. Then we'd have an API that would work if you wanted to use a non-VT based solution. Well, I have no problem at all in replacing the ioctl based impelemntation by something else if the time comes. The session switching really is quite similar to the X problem of having an external component in charge of something that only the compositor (the DM in this case) can do reliably. Another option is to not have logind do any switching at all. The only value I can see in CK/logind being in control of switching is it allows multiple DMs to be run and text consoles to be mixed with graphical ones. Both of these don't seem like important cases to support. Dunno, I think it is quite an important method on a session the way logind keeps track of it to activate it. How that is implemented however, is an implementation detail, and we can replace that easily if the time comes. Well, with Wayland the entire notion of kernel VTs would go away. Instead, the system compositor could simply redirect VT numbers to different sessions dynamically. Then why keep the concept of VTs at all? multi-session is a useful feature, and we want to keep it. Of course in this future world there would be not /dev/tty7 devices, as that is only inherent to the kernel-based VT logic. - Switch to a new session for a KDE session for user X (not particularly likely but a case may come up requiring settings some session choices) We explicitly want to forbid multiple local graphical sessions by the same user in systemd. Here I mean something like SwitchToUserWithParameters. i.e. you may want the KDE user switcher to switch to 'lennart' with a KDE session but the GNOME Shell one to switch to 'lennart' with a GNOME session. Not a major case though. Well, when I say multiple local graphical sessions I mean just that, and have no plans to distuingish between GNOME and KDE in that. 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] Extracting a coredump from the journal
On Wed, 15.02.12 09:16, Thierry Reding (thierry.red...@avionic-design.de) wrote: Hi, I've just had a service crash on one of my systems that runs with systemd 43 so I had a look at the output from 'systemctl status' and looked through the journal to find an entry saying that the process dumped core. I can also confirm that the journal has a coredump entry (judging by the verbose output mode) but I can't seem to find any documentation on how to extract the core dump from the journal. Have I missed something? There's currently no nice tool to extract a core dump from the journal (which is one of the reasons this feature isn't enabled by default on F17 yet). You can easily extract it with some C calls however. We will add a proper C tool for this shortly. 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] configure.ac: fix typo in distro help string
On Wed, 15.02.12 08:00, Thierry Reding (thierry.red...@avionic-design.de) wrote: Signed-off-by: Thierry Reding thierry.red...@avionic-design.de Thanks! Applied! --- configure.ac |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/configure.ac b/configure.ac index 62e8cdf..87d2211 100644 --- a/configure.ac +++ b/configure.ac @@ -395,7 +395,7 @@ AM_CONDITIONAL(HAVE_XSLTPROC, test x$XSLTPROC != x) AC_PATH_PROG([M4], [m4]) -AC_ARG_WITH(distro, AS_HELP_STRING([--with-distro=DISTRO],[Specify the distribution to target: One of fedora, suse, debian, ubuntu, arch, gentoo, slackware, altlinuxi, mandriva, meego, mageia, angstrom or other])) +AC_ARG_WITH(distro, AS_HELP_STRING([--with-distro=DISTRO],[Specify the distribution to target: One of fedora, suse, debian, ubuntu, arch, gentoo, slackware, altlinux, mandriva, meego, mageia, angstrom or other])) if test z$with_distro = z; then if test $cross_compiling = yes; then AC_MSG_WARN([Target distribution cannot be reliably detected when cross-compiling. You should specify it with --with-distro (see $0 --help for recognized distros)]) 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 2/2] main: added support for loading IMA custom policies
On Wed, 22.02.12 15:52, Roberto Sassu (roberto.sa...@polito.it) wrote:
Heya,
+ policy = mmap(NULL, policy_size, PROT_READ, MAP_PRIVATE, policyfd, 0);
+ if (policy == MAP_FAILED) {
+ log_error(mmap() failed (%m), freezing);
+ result = -errno;
+ goto out;
+ }
+
+ while(written policy_size) {
+ ssize_t len = write(imafd, policy + written,
+ policy_size - written);
+ if (len = 0) {
+ if (errno == EINVAL)
+ log_error(Invalid line #%d in the IMA
custom policy file %s,
+ policy_line_number,
IMA_POLICY_PATH);
+
+ log_error(Failed to load the IMA custom policy
+ file %s (%m), ignoring.,
IMA_POLICY_PATH);
+ goto out_mmap;
+ }
+ written += len;
+ policy_line_number++;
I don't understand the counting here of policy_line_number? You attempt
to write the whole policy at once, no? How does this counting of line
numbers work here then? Or does the write() call on the kernel file
actually only accept one line at a time? If that's the case is it really
a good idea to rely on that behaviour? Knowing how these things go
eventually things might get optimized to read more than one line at once
and then the counting here will be off. Maybe it makes sense to drop the
counting entirely here?
(Something else thing that gets me thinking: by mmap()ing the source
file you imply that the policy can never grow beyond 2G or so. I presume
that's not a problem, right?)
Otherwise looks good.
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] Regression in v40? User session inside a unit.
On Mon, 20.02.12 01:27, Colin Guthrie (gm...@colin.guthr.ie) wrote: Hi, Not sure if this is an intended regression or not but a user reported a problem to me recently which I thought was a little strange. It's maybe been fixed already in newer versions (we were in a beta semi-freeze and I've been on holiday so not updated to v43 yet but will do soon). Anyway the problem was the unit was run as root (no User=) but that ultimately ran a perl script that then invoked su to switch to the apache user. While this is obviously not needed (better to use User=apache), it did result in the user session cgroup (name=systemd:/user/apache/c59) overriding the unit cgroup (name=systemd:/system/zoneminder.service) and thus systemd could no longer see the processes the service started (and thus didn't kill them on systemctl stop zoneminder.service) If using su is all that is needed to escape the unit cgroup, then it could be a little bit ambiguous for a user trying to find all processes started by a given service. Hopefully, this has been fixed already, or perhaps documented somewhere I missed (I didn't see it in http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups) Perhaps user sessions should be kept under name=logind cgroup tree rather than reusing name=systemd? That would avoid the problem (although it could still mean that such spawed processes get killed off if some config options like kill-session-processes=1 are set I guess, but that would be the same as currently I suppose). For killing services we generally kill everything in the cgroup plus the main plus the control process (if there is any). We do this to avoid problems with services which are moved to other cgroups. I guess what is missing here is a bit of code in the service listing logic to also include the main/control PID explicitly in the cgroup listing, if it isn't part of the cgroup anyway. I'll add this to the TODO list. 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 2/2] main: added support for loading IMA custom policies
On Mon, 2012-03-05 at 17:15 +0100, Roberto Sassu wrote:
On 03/05/2012 03:39 PM, Lennart Poettering wrote:
On Wed, 22.02.12 15:52, Roberto Sassu (roberto.sa...@polito.it) wrote:
Heya,
+ policy = mmap(NULL, policy_size, PROT_READ, MAP_PRIVATE, policyfd,
0);
+ if (policy == MAP_FAILED) {
+ log_error(mmap() failed (%m), freezing);
+ result = -errno;
+ goto out;
+ }
+
+ while(written policy_size) {
+ ssize_t len = write(imafd, policy + written,
+ policy_size - written);
+ if (len= 0) {
+ if (errno == EINVAL)
+ log_error(Invalid line #%d in the IMA
custom policy file %s,
+ policy_line_number,
IMA_POLICY_PATH);
+
+ log_error(Failed to load the IMA custom policy
+ file %s (%m), ignoring.,
IMA_POLICY_PATH);
+ goto out_mmap;
+ }
+ written += len;
+ policy_line_number++;
I don't understand the counting here of policy_line_number? You attempt
to write the whole policy at once, no? How does this counting of line
numbers work here then? Or does the write() call on the kernel file
actually only accept one line at a time? If that's the case is it really
a good idea to rely on that behaviour? Knowing how these things go
eventually things might get optimized to read more than one line at once
and then the counting here will be off. Maybe it makes sense to drop the
counting entirely here?
Hi Lennart
yes, the kernel interface accepts only one line at time. I implemented
this code because it is not possible to known from the kernel logs what
is the invalid line if the policy contains several lines. Indeed, IMA
sends an audit message for each parsed rule, so that some are dropped
due to the rate limit of audit.
I agree that is not a good idea writing a code that depends on the
specific implementation of how the policy loading is handled. So, a
solution may be to drop the counting code here and to solve the issue
by allowing IMA to send an audit message only when an invalid rule is
encountered.
Mimi, do you agree with that?
With the audit log rate limiting, the current method is not very
informative. How about implementing the securityfs 'read' ops to
display the rules? Then, displaying only the invalid rule makes sense.
thanks,
Mimi
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Circumvent autofs_v5_packet_union size bug
Am Montag, den 05.03.2012, 16:20 +0100 schrieb Kay Sievers: On Tue, Nov 15, 2011 at 16:52, Thomas Meyer tho...@m3y3r.de wrote: Am 14.11.2011 um 03:35 schrieb Ian Kent ra...@themaw.net: Another solution would be to explicitly add 4 filler bytes to the structure to have an 8 byte alignment, like the compiler does it now implicitly on 64 bit. Is this issue fixed with this commit? yes. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=a32744d4abae24572eff7269bc17895c41bd0085 Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] nspawn: less cryptic error when clone() fails due to lack of adaquate namespace support in kernel
Running systemd-nspawn on a Linux kernel compiled without
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
fails with the cryptic error message
clone() failed: Invalid argument
Give user a more helpful error message when clone() fails
---
src/nspawn.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/nspawn.c b/src/nspawn.c
index b8b379d..e70b658 100644
--- a/src/nspawn.c
+++ b/src/nspawn.c
@@ -707,7 +707,7 @@ int main(int argc, char *argv[]) {
assert_se(sigprocmask(SIG_BLOCK, mask, NULL) == 0);
if ((pid = syscall(__NR_clone,
SIGCHLD|CLONE_NEWIPC|CLONE_NEWNS|CLONE_NEWPID|CLONE_NEWUTS|(arg_private_network
? CLONE_NEWNET : 0), NULL)) 0) {
-log_error(clone() failed: %m);
+log_error(clone() failed, do you have kernel namespace
support (CONFIG: UTS_NS, IPC_NS, PID_NS, NET_NS)?: %m);
goto finish;
}
--
1.7.5.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/1] nspawn: less cryptic error when clone() fails due to lack of adaquate namespace support in kernel
On Tue, 28.02.12 11:40, shawn (shawnland...@gmail.com) wrote: Running systemd-nspawn on a Linux kernel compiled without CONFIG_NAMESPACES=y CONFIG_UTS_NS=y CONFIG_IPC_NS=y CONFIG_PID_NS=y CONFIG_NET_NS=y fails with the cryptic error message clone() failed: Invalid argument Give user a more helpful error message when clone() fails I have now applied a similar patch which however only prints this informative messages on EINVAL and not otherwise. 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 v2] src/systemd-bash-completion.sh: get rid of awk, sed and grep
On Tue, 21.02.12 15:48, har...@redhat.com (har...@redhat.com) wrote: From: Harald Hoyer har...@redhat.com Get rid of awk, sed and grep calls. This can be done entirely in bash! Thanks! Applied! 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] mount: properly check return for mount_add_*
On Fri, 17.02.12 12:17, Dave Reisner (d...@falconindy.com) wrote:
Previously, mount_load_etc_fstab() could never fail for reasons other
than a setmntent() or allocation failure.
Applied. Thanks!
---
src/mount.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/mount.c b/src/mount.c
index 0ae964b..5e52a54 100644
--- a/src/mount.c
+++ b/src/mount.c
@@ -1578,7 +1578,7 @@ static int mount_load_etc_fstab(Manager *m) {
free(what);
free(where);
-if (r 0)
+if (k 0)
r = k;
}
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] systemd39: journald segfault brings down some user services
On Mon, 20.02.12 23:35, Olav Vitters (o...@vitters.nl) wrote: On Thu, Feb 09, 2012 at 08:12:55PM +0100, Lennart Poettering wrote: Now, of course, the journal shouldn't crash in the first place. This bug is still something to fix, but so far nobody managed to get me a bt of this. if the journal itself crashes a coredump will be placed in /var/lib/systemd/coredump/. It would be great if somebody could generate a backtrace of that! See https://bugs.mageia.org/show_bug.cgi?id=4588 and the duplicate for a few different stracktraces. Mageia still has v40 atm, so every crash is *very* noticeable. OK, so I looked and looked and looked at the code, and I think I finally figured it out now. Should be fixed in git, in 48496df. Please test! If I fixed the right bug then you should have encountered your problem only if the journal files grow quite large. Thanks for providing the stacktrace, much appreciated. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
