Re: [systemd-devel] [PATCH] job: always add waiting jobs to run queue during coldplug.
On Tue, May 06, 2014 at 12:36:44PM -0700, Michael Marineau wrote:
commit 20a83d7bf was not equivalent to the original bug fix proposed by
Michal Sekletar msekl...@redhat.com. The committed version only added
the job to the run queue if the job had a timeout, which most jobs do
not have. Just re-ordering the code gets us the intended functionality.
---
Applied. Thanks!
src/core/job.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/core/job.c b/src/core/job.c
index 835cfe1..dc4f441 100644
--- a/src/core/job.c
+++ b/src/core/job.c
@@ -1060,15 +1060,15 @@ int job_coldplug(Job *j) {
if (r 0)
return r;
+if (j-state == JOB_WAITING)
+job_add_to_run_queue(j);
+
if (j-begin_usec == 0 || j-unit-job_timeout == 0)
return 0;
if (j-timer_event_source)
j-timer_event_source =
sd_event_source_unref(j-timer_event_source);
-if (j-state == JOB_WAITING)
-job_add_to_run_queue(j);
-
r = sd_event_add_time(
j-manager-event,
j-timer_event_source,
--
1.8.5.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd: setting the MAC address for a .netdev unit?
This should really be added as AFAICT there is currently no way to match
on virtual devices like briges, TAP devices, batman-adv devices, etc...
which have neither a persistent MAC address nor an ID_PATH to match on.
So I think what we should do here is to allow MAC address (and other
things) to be set when creating the netdevs. I made an attempt at this
by generating a predictable one based on the interface name and the
machine-id. Would that do it for you, or are you after a _specific_
mac address, rather than just one that is always the same? I had to
revert the code doing this for now as there was a kernel bug, however
we'll hopefully get that sorted soon and then get back to this.
Cheers,
Tom
For my usecase, a predictable, but otherwise random MAC address would
do. But I also see that setting an arbitrary MAC address (or any other
link parameter) for a specific virtual device is useful as well
(especially as it is possible to do so with real devices). As virtual
devices are almost always created with specific names, a Name= match for
.link units would make the most sense in my opinion.
As a workaround, I've added the following udev rule to
80-net-setup-link.rules for now to allow matching for virtual devices
with Path= matches:
ENV{DEVPATH}==/devices/virtual/net/*, ENV{ID_PATH}==,
ENV{ID_PATH}=virtual-$kernel
Thanks,
Matthias
Ping. There is still no way to match for virtual devices in .link units
without my workaround. Is it planned to add something similar? Would a
facility allowing to configure the MAC address of a virtual device be in
the scope of the TODO point add reduced [Link] support to .network files?
signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] multiple cgroup hierarchies
Hello. I've tried to update systemd to version 212 in Tizen. After I resolved usual building problems and managed to make my device boot, I hit a number of Failed to create cgroup ... messages. It took me some time to find the reason (ah, the loveliness of parallel processing) which appears to be a piece of software that tries to set up its own cgroup hierarchy and destroys what systemd has done (definitely a bug). However, I can see a problem with systemd too. At some point before v212 Lennart decided[1] to lock /sys/fs/cgroup tmpfs instance mounting it read-only to prevent some issues with shmem. However this commit also prevents other processes from creating their own cgroup hierarchies. My question is: is it deliberate? Is there (going to be?) a way to for third-party software to have their own cgroup hierarchies next to systemd in /sys/fs/cgroup despite of it being remounted read-only? [1] http://cgit.freedesktop.org/systemd/systemd/commit/?id=679142ce4a8def7da43c4d3b2a02bae8c0d21175 Kind regards, -- Łukasz Stelmach Samsung RD Institute Poland Samsung Electronics pgp1fEpWryOYO.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] User and Group permissions for .socket files
Hi, How do we set the user:group of a socket created by .socket file? We have thought User= and Group= should do the job but that doesn't seem to be the case. Is this a missing feature or should we just set the permissions by ExecStartPost= on .socket file? Umut ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd: setting the MAC address for a .netdev unit?
On Mon, May 12, 2014 at 10:43 AM, Matthias Schiffer
mschif...@universe-factory.net wrote:
This should really be added as AFAICT there is currently no way to match
on virtual devices like briges, TAP devices, batman-adv devices, etc...
which have neither a persistent MAC address nor an ID_PATH to match on.
So I think what we should do here is to allow MAC address (and other
things) to be set when creating the netdevs. I made an attempt at this
by generating a predictable one based on the interface name and the
machine-id. Would that do it for you, or are you after a _specific_
mac address, rather than just one that is always the same? I had to
revert the code doing this for now as there was a kernel bug, however
we'll hopefully get that sorted soon and then get back to this.
Cheers,
Tom
For my usecase, a predictable, but otherwise random MAC address would
do. But I also see that setting an arbitrary MAC address (or any other
link parameter) for a specific virtual device is useful as well
(especially as it is possible to do so with real devices). As virtual
devices are almost always created with specific names, a Name= match for
.link units would make the most sense in my opinion.
As a workaround, I've added the following udev rule to
80-net-setup-link.rules for now to allow matching for virtual devices
with Path= matches:
ENV{DEVPATH}==/devices/virtual/net/*, ENV{ID_PATH}==,
ENV{ID_PATH}=virtual-$kernel
Thanks,
Matthias
Ping. There is still no way to match for virtual devices in .link units
without my workaround. Is it planned to add something similar? Would a
facility allowing to configure the MAC address of a virtual device be in
the scope of the TODO point add reduced [Link] support to .network files?
Yes. What we will do is that by default we will generate a MAC address
that will be stable between reboots and use that, but we will also
allow the MAC address to be set manually in the [NetDev] section (in
the same way as in the .link files).
The kernel interface for doing this is currently broken, but a patch
has been submitted to fix it, and once that hits the stable kernels I
guess we can start using it (otherwise we are just going to get heaps
of weird bug reports).
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd pam and O_CLOEXEC problem
Fri, 09 May 2014 11:07:45 + от Colin Walters walt...@verbum.org: On Mon, May 5, 2014 at 6:48 AM, dedede gfgfgf trtrtrtrtrtr s.kabano...@mail.ru wrote: Investigations showed that since in pam module we started to dup fifo descriptor problem appeared. Dup does not set O_CLOEXEC flag. So after fork/exec all children processes have that descriptor and when parent which open pam session dies, children processes continue to run. I think you should change your login program to close unnecessary FDs before executing children. Hello Colin. I am speaking about descriptors in systemd pam module. Application which use pam can not control it. Because of: session_fd = dup(session_fd); in pam-module.c we have now descriptor which does not have O_CLOEXEC set. So it will not be closed automatically during exec of children processes and because of this logind will not know that process which opened pam session exited. Sergei ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd pam and O_CLOEXEC problem
Hi On Mon, May 12, 2014 at 1:27 PM, dedede gfgfgf trtrtrtrtrtr s.kabano...@mail.ru wrote: Hello Colin. I am speaking about descriptors in systemd pam module. Application which use pam can not control it. Because of: session_fd = dup(session_fd); in pam-module.c we have now descriptor which does not have O_CLOEXEC set. So it will not be closed automatically during exec of children processes and because of this logind will not know that process which opened pam session exited. This behavior is intentional. This way we can track the main processes of the session and get notified when they died. You should be able to close the session by using pam_close_session(). Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd pam and O_CLOEXEC problem
Mon, 12 May 2014 13:41:03 +0200 от David Herrmann dh.herrm...@gmail.com: Hi On Mon, May 12, 2014 at 1:27 PM, dedede gfgfgf trtrtrtrtrtr s.kabano...@mail.ru wrote: Hello Colin. I am speaking about descriptors in systemd pam module. Application which use pam can not control it. Because of: session_fd = dup(session_fd); in pam-module.c we have now descriptor which does not have O_CLOEXEC set. So it will not be closed automatically during exec of children processes and because of this logind will not know that process which opened pam session exited. This behavior is intentional. This way we can track the main processes of the session and get notified when they died. You should be able to close the session by using pam_close_session(). Thanks David Hello But all children will have that descriptor open. So when parent process will die logind will not be notified. -- Sergei Kabanov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd pam and O_CLOEXEC problem
Hi On Mon, May 12, 2014 at 1:49 PM, Sergei Kabanov s.kabano...@mail.ru wrote: Hello But all children will have that descriptor open. So when parent process will die logind will not be notified. And? That's intentional. If you want to close the session if the main process dies, use something like /bin/login does: call pam_close_session() on SIGCHLD. Note that if we set O_CLOEXEC, then the exec() after the pam-dance will immediately close the FIFO, thus also close the session. So we cannot set O_CLOEXEC. So please call pam_close_session() to notify systemd about session-deaths, or use something like this: for i in /proc/self/fd/* ; do close($i); done to close all file-descriptors before you exec(). But this is really just a nasty hack. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] list-boots is incorrect, was: lost journal persistence
Could it be that all the boot ids are actually the same for some reason? I had this issue in a container when systemd was reading boot_id from `/proc/sys/kernel/random/boot_id` and since /proc was bind-mounted, boot_id always was host's boot_id. You can also run `journalctl -F _BOOT_ID` to see a set of all the boot ids recorded in the journal (this must agree with `journalctl --list-boots`. You can also add ` -o verbose` to see all the fields of records. Since you say that the messages are actually stored in the journal, it might be interesting to check their _BOOT_ID fields. -- Кирилл Елагин On Mon, May 12, 2014 at 12:30 AM, Chris Murphy li...@colorremedies.comwrote: It looks like --list-boots is broken. I have have the same problem on Rawhide with systemd-212-4.fc21.x86_64, which is a completely different VM. Here are the last three items with --list-boots -2 95117f702e4d43619072f87b20b2f31b Sat 2014-05-03 20:38:22 MDT—Sat 2014-05-03 20:47:17 MDT -1 c9bf102876774c7a8748920f6135ddf6 Sat 2014-05-03 20:47:35 MDT—Sat 2014-05-03 20:51:55 MDT 0 f92e4dda29a54b89a3455a10bbb298b2 Sat 2014-05-03 21:01:17 MDT—Sat 2014-05-03 21:05:24 MDT OK installed Rawhide clean today to a third VM, with a Btrfs subvolume var mounted at /var, and the problem doesn't occur. Each boot gets a new entry with --list-boots. The prior Rawhide and Fedora 20 meanwhile, still always have the same --list-boot list after each boot, stuck on May 3rd for some reason. So it seems something broke --list-boot in a state persistent manner with the journal files themselves. The data is in the journal file however, I can extract the prior boots with --since and --lines, it's just that -b [x] is useless. -b -1 takes me back over a week rather than the boot 30 minutes ago. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Failed to mark scope session-20.scope as abandoned
On Sat, May 10, 2014 at 05:12:21PM -0400, Garry T. Williams wrote: This recently stated showing up in the journal on Fedora F20 here: May 10 17:01:01 vfr systemd[1]: Starting Session 20 of user root. May 10 17:01:01 vfr systemd[1]: Started Session 20 of user root. May 10 17:01:01 vfr CROND[5035]: (root) CMD (run-parts /etc/cron.hourly) May 10 17:01:01 vfr run-parts[5039]: (/etc/cron.hourly) starting 0anacron May 10 17:01:01 vfr run-parts[5052]: (/etc/cron.hourly) finished 0anacron May 10 17:01:01 vfr run-parts[5054]: (/etc/cron.hourly) starting ghc-doc-index May 10 17:01:01 vfr run-parts[5065]: (/etc/cron.hourly) finished ghc-doc-index May 10 17:01:01 vfr run-parts[5067]: (/etc/cron.hourly) starting mcelog.cron May 10 17:01:01 vfr run-parts[5071]: (/etc/cron.hourly) finished mcelog.cron May 10 17:01:01 vfr systemd[1]: Failed to mark scope session-20.scope as abandoned : Stale file handle It seems benign. I just haven't seen it before and thought it may be worth reporting here. garry@vfr$ journalctl|grep 'Failed to mark scope' Apr 19 19:01:02 vfr systemd[1]: Failed to mark scope session-2.scope as abandoned : Stale file handle May 05 22:01:02 vfr systemd[1]: Failed to mark scope session-59.scope as abandoned : Stale file handle May 10 17:01:01 vfr systemd[1]: Failed to mark scope session-20.scope as abandoned : Stale file handle garry@vfr$ /usr/lib/systemd/systemd --version systemd 208 +PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ I suspect this is caused by race between systemd realizing that cgroup for a scope is empty, thus changing its state, and dispatching dbus message coming from logind where it asks systemd to mark scope as abandoned. I don't think this is a big deal so we could log this only if debug is on. To make sure if it is the case can you try to reproduce with systemd and logind debug turned on. Thanks! Michal -- Garry T. Williams ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] connection: fix kernel oop when conn_name not set
kernel oops when connection name (kdbus_conn.name) not set via HELLO
message but requested with attach flags KDBUS_ATTACH_CONN_NAME.
As conn.name is defined as for debug purposes I find it more
convenient to return generic name than to strip the field from
requested metadata or raise an error on request.
Signed-off-by: Jacek Janczyk j.janc...@samsung.com
---
connection.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/connection.c b/connection.c
index 40cf133..5ae9d99 100644
--- a/connection.c
+++ b/connection.c
@@ -1941,12 +1941,10 @@ int kdbus_conn_new(struct kdbus_ep *ep,
goto exit_free_conn;
}
- if (conn_name) {
- conn-name = kstrdup(conn_name, GFP_KERNEL);
- if (!conn-name) {
- ret = -ENOMEM;
- goto exit_free_conn;
- }
+ conn-name = kstrdup(conn_name ? conn_name : UNDEFINED, GFP_KERNEL);
+ if (!conn-name) {
+ ret = -ENOMEM;
+ goto exit_free_conn;
}
kref_init(conn-kref);
--
1.7.9.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] test-kdbus: fixed unterminated string
Unterminated string array is used to populate random bus name
in check_prepare_env(). Added proper termination.
Signed-off-by: Jacek Janczyk j.janc...@samsung.com
---
test/test-kdbus.c |5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/test/test-kdbus.c b/test/test-kdbus.c
index e369b4e..f0bf705 100644
--- a/test/test-kdbus.c
+++ b/test/test-kdbus.c
@@ -1042,7 +1042,7 @@ static int check_prepare_env(const struct kdbus_check *c,
struct kdbus_check_env
char name[64];
} bus_make;
unsigned int i;
- char n[32];
+ char n[32 + 1];
int ret;
env-control_fd = open(/dev/ KBUILD_MODNAME /control,
O_RDWR|O_CLOEXEC);
@@ -1054,8 +1054,9 @@ static int check_prepare_env(const struct kdbus_check *c,
struct kdbus_check_env
bus_make.bs.bloom.size = 64;
bus_make.bs.bloom.n_hash = 1;
- for (i = 0; i sizeof(n); i++)
+ for (i = 0; i sizeof(n) - 1; i++)
n[i] = 'a' + (random() % ('z' - 'a'));
+ n[sizeof(n) - 1] = 0;
snprintf(bus_make.name, sizeof(bus_make.name), %u-%s,
getuid(), n);
--
1.7.9.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] connection: fix kernel oop when conn_name not set
On Mon, May 12, 2014 at 3:24 PM, Jacek Janczyk j.janc...@samsung.com wrote: kernel oops when connection name (kdbus_conn.name) not set via HELLO message but requested with attach flags KDBUS_ATTACH_CONN_NAME. Hmm, here does it crash? Seems the code that attaches the string checks for the string being set: if ((mask KDBUS_ATTACH_CONN_NAME) conn conn-name) As conn.name is defined as for debug purposes I find it more convenient to return generic name than to strip the field from requested metadata or raise an error on request. I prefer if we just return nothing when we miss non-essential data. The kernel and its magic strings, which which can also just be supplied by users like the (deleted) for file names, are generally not a good idea. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timer: allow user to control activation time of cron-like timers
Am 11.05.2014 18:30, schrieb Alex B: 2014-05-11 20:09 GMT+04:00 Dave Reisner d...@falconindy.com: On Sun, May 11, 2014 at 07:53:55PM +0400, Alexander Bashmakov wrote: Issue was rised in this thread: https://mailman.archlinux.org/pipermail/arch-general/2014-May/036162.html Disclaimer: I almost have no expereince in C. So this patch can contain some silly mistakes. But it 'works for me'. Please consider it as RFC. -8--- Cron-like timers are useful for maintenance tasks and already used in some distros by default. But midnight is not best time for this. Just add a new option allowing user to specify activation time (and date) for such timers globally. daily is just syntactic sugar for *-*-* 00:00:00. If you don't want to run at midnight, modify the normalized form to run at the time you want. It's ok for one timer, but not for the set of them. In general I'm want to schedule all maintenance tasks to 5 a.m. or lunch break and forget about them. This applies both for distro provided timers an my own that's why anacron don't fire up them at the same time given that you can have on a host 10,20,100 guests *that* below is the solution __ # /etc/anacrontab: configuration file for anacron # See anacron(8) and anacrontab(5) for details. SHELL=/usr/bin/bash PATH=/usr/bin:/usr/sbin LANG=en_GB.UTF-8 MAILTO=root # the maximal random delay added to the base delay of the jobs RANDOM_DELAY=5 # the jobs will be started during the following hours only START_HOURS_RANGE=3-9 #period in days delay in minutes job-identifier command 1 5 cron.daily nice -n 19 run-parts /etc/cron.daily 7 25 cron.weekly nice -n 19 run-parts /etc/cron.weekly @monthly 35 cron.monthly nice -n 19 run-parts /etc/cron.monthly signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] connection: fix kernel oop when conn_name not set
On 05/12/2014 04:20 PM, Kay Sievers wrote: On Mon, May 12, 2014 at 3:24 PM, Jacek Janczyk j.janc...@samsung.com wrote: kernel oops when connection name (kdbus_conn.name) not set via HELLO message but requested with attach flags KDBUS_ATTACH_CONN_NAME. Hmm, here does it crash? Seems the code that attaches the string checks for the string being set: if ((mask KDBUS_ATTACH_CONN_NAME) conn conn-name) My fault. I have brought the patch from older version of the code that we're working on. It is not relevant any more. JJ As conn.name is defined as for debug purposes I find it more convenient to return generic name than to strip the field from requested metadata or raise an error on request. I prefer if we just return nothing when we miss non-essential data. The kernel and its magic strings, which which can also just be supplied by users like the (deleted) for file names, are generally not a good idea. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] rules: add by-parttypeuuid rule for GPT labeled partitions
On Sat, May 10, 2014 at 12:34 AM, Sage Weil s...@inktank.com wrote:
On Sat, 10 May 2014, Kay Sievers wrote:
On Sat, May 10, 2014 at 12:00 AM, Sage Weil s...@inktank.com wrote:
On Fri, 9 May 2014, Kay Sievers wrote:
On Fri, May 9, 2014 at 11:31 PM, Sage Weil s...@inktank.com wrote:
The Ceph OSD initialization relies on identifying GPT partitions by type
in order to mount data volumes and start daemons. Currently we ship
this
rule separately, but it is awkward to duplicate the conditional logic
that
precedes this block and it would be much simpler if it were simply
included
in the upstream rules.
Types are by definition not unique. The symlinks in /dev/disk/by-*/
are *expected* to be unique.
We handle duplicated labels, but they are specified by humans,
multiple partitions with the same GPT types are just normal expected
behavior; and they would have no order or priority, they just
overwrite each other depending on probing order.
This is why the label has both the type (fixed, to identify this as a ceph
partition) and the label (random):
/dev/disk/by-parttypeuuid/$env{ID_PART_ENTRY_TYPE}.$env{ID_PART_ENTRY_UUID}
We should not add such things, the logic to find these volumes at
bootup are better handled by a specific program like systemd's
systemd-gpt-auto-generator, without putting unreliable and
unpredictable content into /dev.
I think this is what we're trying to accomplish with the ceph-disk tool,
which relies on these (reliable and predictable) symlinks. The labels
alone (by-partuuid) aren't sufficient since we want to be able to scan for
partitions of a given type without re-running blkid on every volume.
/dev is an API which should by default not contain custom links which
are not generally useful, and these links are not useful for other
tools.
FWIW I was surprised that there wasn't already a way to find partitions by
type in /dev, but I assume you know better than I how other tools are
using udev. It seems at least as useful as by-partuuid to me.
These links are not even recognizable by type without doing readdir()
over it and string match operations to find the types, we really
should not add such stuff to the default rules set. We have to be
careful here, it seems like the wrong approach to put that in the
public visible /dev API.
Tools can get all this information programatically out of the udev
database, there is no create symlinks or to run blkid.
I just looked up libudev and it looks like there is even a pyudev wrapper,
so that could indeed work better. I take it that queries via
udev_enumerate for (say) ID_PART_ENTRY_TYPE=x are efficient?
Sure, filter for block devices and this or other GPT properties. The
libudev API will just find the devices is /sys and read the database
files in tmpfs /run and, it will not talk to any devices, so it should
perform pretty well.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] list-boots is incorrect, was: lost journal persistence
On 12.05.2014 15:06, Kirill Elagin wrote: Could it be that all the boot ids are actually the same for some reason? I had this issue in a container when systemd was reading boot_id from `/proc/sys/kernel/random/boot_id` and since /proc was bind-mounted, boot_id always was host's boot_id. You can also run `journalctl -F _BOOT_ID` to see a set of all the boot ids recorded in the journal (this must agree with `journalctl --list-boots`. You can also add ` -o verbose` to see all the fields of records. Since you say that the messages are actually stored in the journal, it might be interesting to check their _BOOT_ID fields. $ journalctl -F _BOOT_ID | wc -l 1159 $ journalctl --list-boots | wc -l 1159 poma ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd: setting the MAC address for a .netdev unit?
On 12.05.2014 12:22, Tom Gundersen wrote:
On Mon, May 12, 2014 at 10:43 AM, Matthias Schiffer
mschif...@universe-factory.net wrote:
This should really be added as AFAICT there is currently no way to match
on virtual devices like briges, TAP devices, batman-adv devices, etc...
which have neither a persistent MAC address nor an ID_PATH to match on.
So I think what we should do here is to allow MAC address (and other
things) to be set when creating the netdevs. I made an attempt at this
by generating a predictable one based on the interface name and the
machine-id. Would that do it for you, or are you after a _specific_
mac address, rather than just one that is always the same? I had to
revert the code doing this for now as there was a kernel bug, however
we'll hopefully get that sorted soon and then get back to this.
Cheers,
Tom
For my usecase, a predictable, but otherwise random MAC address would
do. But I also see that setting an arbitrary MAC address (or any other
link parameter) for a specific virtual device is useful as well
(especially as it is possible to do so with real devices). As virtual
devices are almost always created with specific names, a Name= match for
.link units would make the most sense in my opinion.
As a workaround, I've added the following udev rule to
80-net-setup-link.rules for now to allow matching for virtual devices
with Path= matches:
ENV{DEVPATH}==/devices/virtual/net/*, ENV{ID_PATH}==,
ENV{ID_PATH}=virtual-$kernel
Thanks,
Matthias
Ping. There is still no way to match for virtual devices in .link units
without my workaround. Is it planned to add something similar? Would a
facility allowing to configure the MAC address of a virtual device be in
the scope of the TODO point add reduced [Link] support to .network files?
Yes. What we will do is that by default we will generate a MAC address
that will be stable between reboots and use that, but we will also
allow the MAC address to be set manually in the [NetDev] section (in
the same way as in the .link files).
The kernel interface for doing this is currently broken, but a patch
has been submitted to fix it, and once that hits the stable kernels I
guess we can start using it (otherwise we are just going to get heaps
of weird bug reports).
Cheers,
Tom
Ping.
Care to paste link to a patch?
poma
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd: setting the MAC address for a .netdev unit?
On Mon, May 12, 2014 at 5:27 PM, poma pomidorabelis...@gmail.com wrote:
On 12.05.2014 12:22, Tom Gundersen wrote:
On Mon, May 12, 2014 at 10:43 AM, Matthias Schiffer
mschif...@universe-factory.net wrote:
This should really be added as AFAICT there is currently no way to match
on virtual devices like briges, TAP devices, batman-adv devices, etc...
which have neither a persistent MAC address nor an ID_PATH to match on.
So I think what we should do here is to allow MAC address (and other
things) to be set when creating the netdevs. I made an attempt at this
by generating a predictable one based on the interface name and the
machine-id. Would that do it for you, or are you after a _specific_
mac address, rather than just one that is always the same? I had to
revert the code doing this for now as there was a kernel bug, however
we'll hopefully get that sorted soon and then get back to this.
Cheers,
Tom
For my usecase, a predictable, but otherwise random MAC address would
do. But I also see that setting an arbitrary MAC address (or any other
link parameter) for a specific virtual device is useful as well
(especially as it is possible to do so with real devices). As virtual
devices are almost always created with specific names, a Name= match for
.link units would make the most sense in my opinion.
As a workaround, I've added the following udev rule to
80-net-setup-link.rules for now to allow matching for virtual devices
with Path= matches:
ENV{DEVPATH}==/devices/virtual/net/*, ENV{ID_PATH}==,
ENV{ID_PATH}=virtual-$kernel
Thanks,
Matthias
Ping. There is still no way to match for virtual devices in .link units
without my workaround. Is it planned to add something similar? Would a
facility allowing to configure the MAC address of a virtual device be in
the scope of the TODO point add reduced [Link] support to .network files?
Yes. What we will do is that by default we will generate a MAC address
that will be stable between reboots and use that, but we will also
allow the MAC address to be set manually in the [NetDev] section (in
the same way as in the .link files).
The kernel interface for doing this is currently broken, but a patch
has been submitted to fix it, and once that hits the stable kernels I
guess we can start using it (otherwise we are just going to get heaps
of weird bug reports).
Cheers,
Tom
Ping.
Care to paste link to a patch?
Sure: http://www.spinics.net/lists/netdev/msg280477.html
Cheers,
Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] list-boots is incorrect, was: lost journal persistence
On May 12, 2014, at 7:06 AM, Kirill Elagin kirela...@gmail.com wrote: Could it be that all the boot ids are actually the same for some reason? I had this issue in a container when systemd was reading boot_id from `/proc/sys/kernel/random/boot_id` and since /proc was bind-mounted, boot_id always was host's boot_id. You can also run `journalctl -F _BOOT_ID` to see a set of all the boot ids recorded in the journal (this must agree with `journalctl --list-boots`. # journalctl --list-boots | wc -l 36 [root@rawhide ~]# journalctl -F _BOOT_ID | wc -l 80 # cat /proc/sys/kernel/random/boot_id 420fa190-e7dd-4cd7-b248-fd62417d7c02 # reboot ### # journalctl --list-boots | wc -l 36 [root@rawhide ~]# journalctl -F _BOOT_ID | wc -l 81 # cat /proc/sys/kernel/random/boot_id 1e0d5346-85cb-477b-9ae2-2cfb53097b97 So there are more boot ID's than there are list-boots, and list-boots doesn't increment while boot ID's do. And neither of these boot id's match any of the boot id's in --list-boots. You can also add ` -o verbose` to see all the fields of records. Since you say that the messages are actually stored in the journal, it might be interesting to check their _BOOT_ID fields. --since=2014-05-08 _BOOT_ID=e39d1329d216487f951334b229449d81 --since=2014-05-09 _BOOT_ID=550ece50b3ed4e21b9a0c446b95c2ebd --since=2014-05-04 _BOOT_ID=e428016363534ea595b1d9ba0440deeb They all appear to have unique boot IDs in the journal. Yet they aren't listed in --list-boots. For whatever reason, --list-boots is a subset of what I actually have. Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] multiple cgroup hierarchies
On Mon, 12.05.14 11:43, Łukasz Stelmach (l.stelm...@samsung.com) wrote: Hello. I've tried to update systemd to version 212 in Tizen. After I resolved usual building problems and managed to make my device boot, I hit a number of Failed to create cgroup ... messages. It took me some time to find the reason (ah, the loveliness of parallel processing) which appears to be a piece of software that tries to set up its own cgroup hierarchy and destroys what systemd has done (definitely a bug). However, I can see a problem with systemd too. At some point before v212 Lennart decided[1] to lock /sys/fs/cgroup tmpfs instance mounting it read-only to prevent some issues with shmem. However this commit also prevents other processes from creating their own cgroup hierarchies. My question is: is it deliberate? Well, yes. That said, people can simply remount the dir writable agan and then do whatever they want... I just wanted to make sure that no accidental changes take place on the dir. Is there (going to be?) a way to for third-party software to have their own cgroup hierarchies next to systemd in /sys/fs/cgroup despite of it being remounted read-only? Well, sure, they can remount it writable, adn then add it there. That said, given that that would be a private hierarchy, there's really not much point in even mounting it to /sys/fs/cgroup/foobar, it could just as well place it in /run/foobar/mycgrouptree... In general though, be prepare though that after the kernel cgroup rework there will be only a single cgroup tree, so this entire thing will not work in the long run... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User and Group permissions for .socket files
On Mon, 12.05.14 12:03, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: Hi, How do we set the user:group of a socket created by .socket file? We have thought User= and Group= should do the job but that doesn't seem to be the case. Is this a missing feature or should we just set This is a missing feature. And it is on the TODO list. It's not easy to fix though. To chmod() sockets properly we need to resolve the user/group names via NSS first. However, we cannot do NSS from PID1, since this might deadlock, since NSS frequently involves talking/activating local services. To properly handle this we hence need to do the chowning in a temporary child process. Which is a non-trivial amount of code... I have always been too lazy to implement this for now, however, we will soonishly have to add this, since for the kbdus policy we are in a similar situation (since the per-busname policy we upload also is bound to UID/GIDs we need to resolve), and if we fix it there, we can immediately open this up for .sockets too. the permissions by ExecStartPost= on .socket file? Yes, this is the recommended work-around for now. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Posible sd-resolve regression after callback rework
On Sat, 10.05.14 15:13, Daniel Buch (boogiewasth...@gmail.com) wrote: Hi, I just noticed valgrind -tool=helgrind ./test-resolve complains, there seem to be some kind of possible race.. I'm not gdb or valgrind expert, so i just want to bring a heads-up. Here's what i got with --tool=helgrind: Hmm, can't see any issue here that would make sense to me. This is mostly inside of NSS, and I fear we have to assume that glibc NSS is resonably reentrant to be not be a source of problems... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] endless wait for job to mount /sysroot
On May 11, 2014, at 1:25 PM, Chris Murphy ch...@colorremedies.com wrote: Fedora Rawhide (systemd-212) vs Fedora 20 (systemd-209) and a Btrfs degraded boot. With Fedora 20, at basic.target, I get the cylon eye A start job is runing for dev-disk-by….. which eventually fails and I get a dracut prompt, and a note about the sos report. Great. That's what I need to find out why rootflags=degrade is apparently not working. With Fedora Rawhide however, at basic target, I get the cylon eye and it never ends. I get a repeat of these lines: [**] A start job is running for dev-disk-by\x2uuid-7b742…55s / no limit)G ot notification message of runit systemd-journald.service systemd-journald.service: Got notification message from PID 105 (WATCHDOG=1…) systemd-journald.service: got WATCHDOG=1 Still repeats these lines after 20 minutes. So I reattached the missing device so I can boot, and ran: systemctl enable debug-shell.service disconnected the device again and rebooted. Yet ctrl-alt-f9 does not work at this same point (I have one shell only) so I still can't get to a shell, but what I'd rather have is the sos report. Ideas why this behavior is different with Rawhide and F20, seems like a bug to me if we can't mount /sysroot after 20 minutes there needs to be a fail, not a cylon eye for forever. Since I don't know for sure this is a systemd bug, but it represents a regression between Fedora 20 and Rawhide, I filed a bug for it here: https://bugzilla.redhat.com/show_bug.cgi?id=1096910 Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd: setting the MAC address for a .netdev unit?
On 05/12/2014 05:45 PM, Tom Gundersen wrote:
On Mon, May 12, 2014 at 5:27 PM, poma pomidorabelis...@gmail.com wrote:
On 12.05.2014 12:22, Tom Gundersen wrote:
On Mon, May 12, 2014 at 10:43 AM, Matthias Schiffer
mschif...@universe-factory.net wrote:
This should really be added as AFAICT there is currently no way to match
on virtual devices like briges, TAP devices, batman-adv devices, etc...
which have neither a persistent MAC address nor an ID_PATH to match on.
So I think what we should do here is to allow MAC address (and other
things) to be set when creating the netdevs. I made an attempt at this
by generating a predictable one based on the interface name and the
machine-id. Would that do it for you, or are you after a _specific_
mac address, rather than just one that is always the same? I had to
revert the code doing this for now as there was a kernel bug, however
we'll hopefully get that sorted soon and then get back to this.
Cheers,
Tom
For my usecase, a predictable, but otherwise random MAC address would
do. But I also see that setting an arbitrary MAC address (or any other
link parameter) for a specific virtual device is useful as well
(especially as it is possible to do so with real devices). As virtual
devices are almost always created with specific names, a Name= match for
.link units would make the most sense in my opinion.
As a workaround, I've added the following udev rule to
80-net-setup-link.rules for now to allow matching for virtual devices
with Path= matches:
ENV{DEVPATH}==/devices/virtual/net/*, ENV{ID_PATH}==,
ENV{ID_PATH}=virtual-$kernel
Thanks,
Matthias
Ping. There is still no way to match for virtual devices in .link units
without my workaround. Is it planned to add something similar? Would a
facility allowing to configure the MAC address of a virtual device be in
the scope of the TODO point add reduced [Link] support to .network files?
Yes. What we will do is that by default we will generate a MAC address
that will be stable between reboots and use that, but we will also
allow the MAC address to be set manually in the [NetDev] section (in
the same way as in the .link files).
The kernel interface for doing this is currently broken, but a patch
has been submitted to fix it, and once that hits the stable kernels I
guess we can start using it (otherwise we are just going to get heaps
of weird bug reports).
Cheers,
Tom
Ping.
Care to paste link to a patch?
Sure: http://www.spinics.net/lists/netdev/msg280477.html
Cheers,
Tom
Thanks!
Why am I seeing this commit on git/stable,
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/net/bridge/br_netlink.c?id=30313a3
but not in stable complete tarball,
https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.14.3.tar.xz
poma
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: Filter by state behind the D-Bus API, not in the systemctl client.
Bumping this for review. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] User and Group permissions for .socket files
An alternative workaround is to put the socket into a directory that has the permissions desired. If you can't read the directory, you can't use a socket in that directory. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [RFC][PATCH] core: sysvcompat - $network should be equivalent to network-online, rather than network target
Most likely the facility needed is actual connectivity, rather than whether or
not the
network managment daemon is running.
We also need to explicitly pull in the network-online.target, as it is not
active by
default.
This means {systemd-networkd,NetworkManager}-wait-online.service, can be
enabled by default
as part of network-online.target, and only delay boot when some service
actively pulls it in.
See: https://bugzilla.gnome.org/show_bug.cgi?id=728965
Cc: Pavel Šimerda psime...@redhat.com
Cc: Michal Sekletar msekl...@redhat.com
---
TODO | 4
src/core/service.c | 8 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/TODO b/TODO
index 50d3f79..3154fbd 100644
--- a/TODO
+++ b/TODO
@@ -705,10 +705,6 @@ Features:
External:
-* NM: figure out what to do about network-online.target.
- - maybe pull in the target as dependency for LSB initscripts ordered now
after network.target
- - https://bugzilla.gnome.org/show_bug.cgi?id=728965
-
* dbus:
- natively watch for dbus-*.service symlinks (PENDING)
- teach dbus to activate all services it finds in
/etc/systemd/services/org-*.service
diff --git a/src/core/service.c b/src/core/service.c
index 694a265..4b6220e 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -392,7 +392,7 @@ static int sysv_translate_facility(const char *name, const
char *filename, char
static const char * const table[] = {
/* LSB defined facilities */
local_fs, NULL,
-network, SPECIAL_NETWORK_TARGET,
+network, SPECIAL_NETWORK_ONLINE_TARGET,
named,SPECIAL_NSS_LOOKUP_TARGET,
portmap, SPECIAL_RPCBIND_TARGET,
remote_fs,SPECIAL_REMOTE_FS_TARGET,
@@ -854,7 +854,11 @@ static int service_load_sysv_path(Service *s, const char
*path) {
if (r == 0)
continue;
-r = unit_add_dependency_by_name(u,
startswith_no_case(t, X-Start-Before:) ? UNIT_BEFORE : UNIT_AFTER, m, NULL,
true);
+if (streq(m,
SPECIAL_NETWORK_ONLINE_TARGET) !startswith_no_case(t, X-Start-Before:))
+/* the network-online target
is special, as it needs to be actively pulled in */
+r =
unit_add_two_dependencies_by_name(u, UNIT_AFTER, UNIT_WANTS, m, NULL, true);
+else
+r =
unit_add_dependency_by_name(u, startswith_no_case(t, X-Start-Before:) ?
UNIT_BEFORE : UNIT_AFTER, m, NULL, true);
if (r 0)
log_error_unit(u-id, [%s:%u]
Failed to add dependency on %s, ignoring: %s,
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] timed out waiting for device dev-disk-by\x2duuid
Two device Btrfs volume, with one device missing (simulated) will not boot, even with rootflags=degraded set which is currently required to enable Btrfs degraded mounts. Upon reaching a dracut shell after basic.target fails with time out, I can mount -o subvol=root,degraded and exit and continue boot normally with just the single device. The problem seems to be that systemd (udev?) is not finding the volume by uuid for some reason, and therefore not attempting to mount it. But I don't know why it can't find it, or even how the find by uuid mechanism works this early in boot. So I'm not sure if this is a systemd or udev bug, or a dracut, or kernel bug. The problem happens with systemd 208-9.fc20 with kernel 3.11.10-301.fc20, and systemd 212-4.fc21 and kernel 3.15.0-0.rc5.git0.1.fc21. Details: [0.00] localhost.localdomain kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-3.11.10-301.fc20.x86_64 root=UUID=c27871d6-5dbe-4d32-9ba9-03b425076da4 ro rootflags=subvol=root,degraded elevator=deadline systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M Partial of rdsosreport.txt from the above boot which has systemd logging set to debug. [1.466282] systemd[1]: Reached target Basic System. [1.466362] systemd[1]: Accepted connection on private bus. [1.466808] systemd[1]: Got D-Bus request: org.freedesktop.systemd1.Agent.Released() on /org/freedesktop/systemd1/agent [1.466898] systemd[1]: Got D-Bus request: org.freedesktop.DBus.Local.Disconnected() on /org/freedesktop/DBus/Local [ 91.089693] systemd[1]: Job dev-disk-by\x2duuid-c27871d6\x2d5dbe\x2d4d32\x2d9ba9\x2d03b425076da4.device/start timed out. [ 91.098727] systemd[1]: Job dev-disk-by\x2duuid-c27871d6\x2d5dbe\x2d4d32\x2d9ba9\x2d03b425076da4.device/start finished, result=timeout [ 91.099205] systemd[1]: Timed out waiting for device dev-disk-by\x2duuid-c27871d6\x2d5dbe\x2d4d32\x2d9ba9\x2d03b425076da4.device. [ 91.099227] systemd[1]: Job sysroot.mount/start finished, result=dependency [ 91.101537] systemd[1]: Dependency failed for /sysroot. [ 91.101548] systemd[1]: Job initrd-root-fs.target/start finished, result=dependency [ 91.102482] systemd[1]: Dependency failed for Initrd Root File System. [ 91.102497] systemd[1]: Job initrd-parse-etc.service/start finished, result=dependency [ 91.104125] systemd[1]: Dependency failed for Reload Configuration from the Real Root. [ 91.104135] systemd[1]: Triggering OnFailure= dependencies of initrd-parse-etc.service. [ 91.104141] systemd[1]: Trying to enqueue job emergency.target/start/replace [ 91.104165] systemd[1]: Installed new job emergency.target/start as 41 [ 91.104170] systemd[1]: Installed new job emergency.service/start as 42 [ 91.104174] systemd[1]: Installed new job sysinit.target/stop as 45 [ 91.104179] systemd[1]: Installed new job basic.target/stop as 46 [ 91.104183] systemd[1]: Job initrd.target/start finished, result=canceled [ 91.104196] systemd[1]: Closed jobs progress timerfd. [ 91.104200] systemd[1]: Installed new job initrd.target/stop as 47 [ 91.104205] systemd[1]: Job dracut-mount.service/start finished, result=canceled [ 91.104272] systemd[1]: Installed new job dracut-mount.service/stop as 48 [ 91.104278] systemd[1]: Job dracut-pre-pivot.service/start finished, result=canceled [ 91.104306] systemd[1]: Installed new job dracut-pre-pivot.service/stop as 49 [ 91.104310] systemd[1]: Enqueued job emergency.target/start as 41 [ 91.104317] systemd[1]: Triggering OnFailure= dependencies of initrd-root-fs.target. [ 91.104322] systemd[1]: Trying to enqueue job emergency.target/start/isolate [ 91.104365] systemd[1]: Job initrd.target/stop finished, result=canceled [ 91.104371] systemd[1]: Job dracut-mount.service/stop finished, result=canceled [ 91.104376] systemd[1]: Job dracut-pre-pivot.service/stop finished, result=canceled [ 91.104382] systemd[1]: Merged into installed job emergency.target/start as 41 [ 91.104387] systemd[1]: Merged into installed job emergency.service/start as 42 [ 91.104391] systemd[1]: Merged into installed job sysinit.target/stop as 45 [ 91.104396] systemd[1]: Merged into installed job basic.target/stop as 46 [ 91.104400] systemd[1]: Installed new job local-fs.target/stop as 61 [ 91.104406] systemd[1]: Installed new job system.slice/stop as 62 [ 91.104411] systemd[1]: Installed new job slices.target/stop as 63 [ 91.104415] systemd[1]: Installed new job -.slice/stop as 64 [ 91.104419] systemd[1]: Installed new job sockets.target/stop as 65 [ 91.104424] systemd[1]: Installed new job systemd-journald.service/stop as 66 [ 91.104429] systemd[1]: Installed new job systemd-udevd-kernel.socket/stop as 67 [ 91.104434] systemd[1]: Installed new job systemd-udevd-control.socket/stop as 68 [ 91.104439] systemd[1]: Installed new job systemd-udevd.service/stop as 69 [ 91.104443] systemd[1]: Installed new
Re: [systemd-devel] systemd-networkd: setting the MAC address for a .netdev unit?
On 12.05.2014 20:53, Tom Gundersen wrote: On Mon, May 12, 2014 at 7:44 PM, poma pomidorabelis...@gmail.com wrote: Why am I seeing this commit on git/stable, https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/net/bridge/br_netlink.c?id=30313a3 but not in stable complete tarball, https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.14.3.tar.xz You are seeing it in the 'master' branch, which is just tracking Linus' tree. It has not yet been backported to any of the stable branches. Cheers, Tom Ooh yeah! br_netlink.c?h=master vs. br_netlink.c?h=linux-3.14.y Thanks! poma ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
