[systemd-devel] Run script before the first systemd-timer is triggered? Systemd-timer in UTC?
Hello, I want to run systemd on a embedded linux board. I have connected a RTC module via I2C. What I want to do is to set the time via "hwclock --hctosys" during boot. I have to do this before the first systemd-timer is triggered. How do I have to create my service-file to set the time as early as possible? Second question: Do I have to use "localtime" for systemd timers or is it possible to set a timer wich, for example, is triggered daily at 04:00 UTC? Thank you very much in advance. Greetings, Manuel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core/cryptsetup: Add WantsMountFor option to enable fallback to password request for crypt mounts. Signed-off-by: Przemek Rudy
On Mon, Apr 28, 2014 at 12:46 AM, Przemek Rudy wrote:
> This patch is a proposal for a problem with not falling back to password
> request
> if the device with unlocking key for crypt volumes is not mounted for defined
> time.
Looks good to me (but I didn't test it). Only one minor nit below.
Also, you probably want to rewrite the subject of the patch (you can
drop the signed-off-by as we don't use that here).
Cheers,
Tom
> ---
> src/core/dbus-unit.c | 1 +
> src/core/load-fragment-gperf.gperf.m4 | 1 +
> src/core/load-fragment.c | 47 +++
> src/core/load-fragment.h | 1 +
> src/core/manager.c| 15
> src/core/manager.h| 6 ++
> src/core/mount.c | 25 +-
> src/core/unit.c | 144
> ++
> src/core/unit.h | 5 ++
> src/cryptsetup/cryptsetup-generator.c | 3 +-
> 10 files changed, 246 insertions(+), 2 deletions(-)
>
> diff --git a/src/core/dbus-unit.c b/src/core/dbus-unit.c
> index 07e7f20..31a35e9 100644
> --- a/src/core/dbus-unit.c
> +++ b/src/core/dbus-unit.c
> @@ -516,6 +516,7 @@ const sd_bus_vtable bus_unit_vtable[] = {
> SD_BUS_PROPERTY("ReloadPropagatedFrom", "as",
> property_get_dependencies, offsetof(Unit,
> dependencies[UNIT_RELOAD_PROPAGATED_FROM]), SD_BUS_VTABLE_PROPERTY_CONST),
> SD_BUS_PROPERTY("JoinsNamespaceOf", "as", property_get_dependencies,
> offsetof(Unit, dependencies[UNIT_JOINS_NAMESPACE_OF]),
> SD_BUS_VTABLE_PROPERTY_CONST),
> SD_BUS_PROPERTY("RequiresMountsFor", "as", NULL, offsetof(Unit,
> requires_mounts_for), SD_BUS_VTABLE_PROPERTY_CONST),
> +SD_BUS_PROPERTY("WantsMountsFor", "as", NULL, offsetof(Unit,
> wants_mounts_for), SD_BUS_VTABLE_PROPERTY_CONST),
> SD_BUS_PROPERTY("Documentation", "as", NULL, offsetof(Unit,
> documentation), SD_BUS_VTABLE_PROPERTY_CONST),
> SD_BUS_PROPERTY("Description", "s", property_get_description, 0,
> SD_BUS_VTABLE_PROPERTY_CONST),
> SD_BUS_PROPERTY("LoadState", "s", property_get_load_state,
> offsetof(Unit, load_state), SD_BUS_VTABLE_PROPERTY_CONST),
> diff --git a/src/core/load-fragment-gperf.gperf.m4
> b/src/core/load-fragment-gperf.gperf.m4
> index 21bccbb..4e51866 100644
> --- a/src/core/load-fragment-gperf.gperf.m4
> +++ b/src/core/load-fragment-gperf.gperf.m4
> @@ -139,6 +139,7 @@ Unit.PropagateReloadFrom,config_parse_unit_deps,
>UNIT_RELOAD
> Unit.PartOf, config_parse_unit_deps,
> UNIT_PART_OF, 0
> Unit.JoinsNamespaceOf, config_parse_unit_deps,
> UNIT_JOINS_NAMESPACE_OF, 0
> Unit.RequiresMountsFor, config_parse_unit_requires_mounts_for, 0,
>0
> +Unit.WantsMountsFor, config_parse_unit_wants_mounts_for, 0,
>0
> Unit.StopWhenUnneeded, config_parse_bool, 0,
>offsetof(Unit, stop_when_unneeded)
> Unit.RefuseManualStart, config_parse_bool, 0,
>offsetof(Unit, refuse_manual_start)
> Unit.RefuseManualStop, config_parse_bool, 0,
>offsetof(Unit, refuse_manual_stop)
> diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
> index 3b36d15..24c1849 100644
> --- a/src/core/load-fragment.c
> +++ b/src/core/load-fragment.c
> @@ -2048,6 +2048,52 @@ int config_parse_unit_requires_mounts_for(
> return 0;
> }
>
> +int config_parse_unit_wants_mounts_for(
> +const char *unit,
> +const char *filename,
> +unsigned line,
> +const char *section,
> +unsigned section_line,
> +const char *lvalue,
> +int ltype,
> +const char *rvalue,
> +void *data,
> +void *userdata) {
> +
> +Unit *u = userdata;
> +char *state;
> +size_t l;
> +char *w;
> +
> +assert(filename);
> +assert(lvalue);
> +assert(rvalue);
> +assert(data);
> +
> +FOREACH_WORD_QUOTED(w, l, rvalue, state) {
> +int r;
> +_cleanup_free_ char *n;
> +
> +n = strndup(w, l);
> +if (!n)
> +return log_oom();
> +
> +if (!utf8_is_valid(n)) {
> +log_invalid_utf8(unit, LOG_ERR, filename, line,
> EINVAL, rvalue);
> +continue;
> +}
> +
> +r = unit_want_mounts_for(u, n);
> +if (r < 0) {
> +log_syntax(unit, LOG_ERR, filename, line, r,
> + "Failed to add wanted mount for,
> ignoring: %s", rvalue);
> +
[systemd-devel] kvm modules don't load any more with kernel >= 3.11
Hello all,
a while ago we got a report (https://launchpad.net/bugs/1207705) that
with kernel >= 3.11 the kvm modules (in particular, kvm_intel) don't
get autoloaded any more. Andy (CC'ed) fixed that back then with the
attached patch to 80-drivers.rules. Yesterday on the Debian systemd
sprint this was confirmed by someone else who runs pure systemd on
Debian with the Debian kernel, so it doesn't seem to be an unique
quirk of either the Ubuntu kernel or the previous Ubuntu systemd
modifications.
I just confirmed that on linux 3.13, kmod 16, and systemd 204 (I know,
old, but the corresponding udev rules didn't change since then). Is
that something which ought to be in 80-drivers.rules, or is that a
kernel regression? Andy's description suggests the former, and he can
hopefully chime in.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From: Andy Whitcroft
Date: Sat, 26 Apr 2014 23:12:58 +0200
Subject: Always probe cpu support drivers
The kernel from v3.11 now reports (correctly) that there is a
CPU driver connected to the CPUs in the kernel. This causes udev
to ignore the device and prevents any CPU helper modules such as KVM or
AES optimisations from being loaded. These should be loaded regardless
of whether there is a CPU driver.
Reported-by: Chris J Arges
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1207705
Forwarded: no
---
rules/80-drivers.rules | 1 +
1 file changed, 1 insertion(+)
diff --git a/rules/80-drivers.rules b/rules/80-drivers.rules
index 01760ef..c65ea15 100644
--- a/rules/80-drivers.rules
+++ b/rules/80-drivers.rules
@@ -3,6 +3,7 @@
ACTION=="remove", GOTO="drivers_end"
DRIVER!="?*", ENV{MODALIAS}=="?*", RUN{builtin}="kmod load $env{MODALIAS}"
+SUBSYSTEM=="cpu", ENV{MODALIAS}=="?*", RUN{builtin}="kmod load $env{MODALIAS}"
SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="SD", RUN{builtin}="kmod load tifm_sd"
SUBSYSTEM=="tifm", ENV{TIFM_CARD_TYPE}=="MS", RUN{builtin}="kmod load tifm_ms"
SUBSYSTEM=="memstick", RUN{builtin}="kmod load ms_block mspro_block"
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Missing default route after boot with DHCP on a multi-homed server
Hi, I installed CoreOS 298 (with systemd 212) on a multi-homed machine with a public and a private interface. It’s a data-center machine, and the provider assigns both interfaces through DHCP. Stock CoreOS defaults to DHCP settings for all network interfaces. When I boot the machine, the public interface (eno1) is missing a default route, and the private interface eno2 instead has two (the first two lines in the routing table below): Apr 25 12:52:15 garry systemd[1]: Started Network Service. Apr 25 12:52:17 garry systemd-networkd[3041]: eno2: carrier on Apr 25 12:52:18 garry systemd-networkd[3041]: eno2: DHCPv4 address 10.60.120.27/26 via 0.0.0.0 Apr 25 12:52:18 garry systemd-networkd[3041]: eno1: carrier on Apr 25 12:52:18 garry systemd-networkd[3041]: eno2: link configured Apr 25 12:52:18 garry systemd-networkd[3041]: eno1: DHCPv4 address 33.112.217.84/24 via 33.112.217.1 Apr 25 12:52:18 garry systemd-networkd[3041]: eno1: link configured # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 0.0.0.0 255.255.255.255 UH0 00 eno2 0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 eno2 10.60.120.0 0.0.0.0 255.255.255.192 U 0 00 eno2 33.112.217.00.0.0.0 255.255.255.0 U 0 00 eno1 33.112.217.10.0.0.0 255.255.255.255 UH0 00 eno1 Restarting the systemd-networkd.service, correctly assigns the default route for eno1: # systemctl restart systemd-networkd.service Apr 25 12:54:09 garry systemd-networkd[3144]: eno1: DHCPv4 address 33.112.217.84/24 via 33.112.217.1 Apr 25 12:54:09 garry systemd-networkd[3144]: eno1: link configured Apr 25 12:54:09 garry systemd-networkd[3144]: eno2: DHCPv4 address 10.60.120.27/26 via 0.0.0.0 Apr 25 12:54:10 garry systemd-networkd[3144]: eno2: link configured # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 0.0.0.0 255.255.255.255 UH0 00 eno2 0.0.0.0 33.112.217.10.0.0.0 UG0 00 eno1 10.60.120.0 0.0.0.0 255.255.255.192 U 0 00 eno2 33.112.217.00.0.0.0 255.255.255.0 U 0 00 eno1 33.112.217.10.0.0.0 255.255.255.255 UH0 00 eno1 This happens consistently on every boot. I worked around this by assigning a static address to the public interface, but nevertheless wanted to point this out as a possible bug. Thanks, Damir ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kvm modules don't load any more with kernel >= 3.11
On Mon, Apr 28, 2014 at 12:09 PM, Martin Pitt wrote: > Hello all, > > a while ago we got a report (https://launchpad.net/bugs/1207705) that > with kernel >= 3.11 the kvm modules (in particular, kvm_intel) don't > get autoloaded any more. Andy (CC'ed) fixed that back then with the > attached patch to 80-drivers.rules. Yesterday on the Debian systemd > sprint this was confirmed by someone else who runs pure systemd on > Debian with the Debian kernel, so it doesn't seem to be an unique > quirk of either the Ubuntu kernel or the previous Ubuntu systemd > modifications. > > I just confirmed that on linux 3.13, kmod 16, and systemd 204 (I know, > old, but the corresponding udev rules didn't change since then). Is > that something which ought to be in 80-drivers.rules, or is that a > kernel regression? Andy's description suggests the former, and he can > hopefully chime in. http://cgit.freedesktop.org/systemd/systemd/commit/?id=bf7f800f2b3e93ccd1229d4717166f3a4d3af72f ? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Set default polling interval on removable devices as well
Hey Kay,
Kay Sievers [2014-04-26 19:55 +0200]:
> SUBSYSTEM=="module" is not so much about *loadable* modules, but about
> module *parameters*, which also apply to built-in modules. "block" is
> never a module.
Ah! That misled me then, thanks for clarifying.
> Is the value not applied at all, can you check the file?
> Is it only missing for some devices which might be created before the
> setting is applied?
Here I can only check in qemu with -cdrom and on my laptop (no CD
drive), and /sys/module/block/parameters/events_dfl_poll_msecs indeed
does get applied ("2000"). So the original rule works indeed.
> Are the module parameter rules included in the initramfs?
60-persistent-storage.rules (which has that rule) is in the initramfs;
or do you mean something else? In either case, as you said the rule
should also be (re)applied after initramfs in the real system after
coldplugging?
So several folks on the Debian bug still see this (last confirmation
in Feb this year), so somehow the new rule seems to help. I need to
reinvestigate this again (I was misled by block being not a module
from above), so please ignore the patch for now (if anything, the
description is bogus).
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kvm modules don't load any more with kernel >= 3.11
Hey Kay, Kay Sievers [2014-04-28 12:16 +0200]: > http://cgit.freedesktop.org/systemd/systemd/commit/?id=bf7f800f2b3e93ccd1229d4717166f3a4d3af72f Ah, cool, thanks! Will replace our patch with that. Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Run script before the first systemd-timer is triggered? Systemd-timer in UTC?
On Mon, Apr 28, 2014 at 10:48 AM, Manuel Reimer wrote: > > Hello, > > I want to run systemd on a embedded linux board. I have connected a RTC > module via I2C. > > What I want to do is to set the time via "hwclock --hctosys" during boot. I > have to do this before the first systemd-timer is triggered. Doesn't the kernel already do the same via CONFIG_RTC_HCTOSYS_DEVICE? -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Missing default route after boot with DHCP on a multi-homed server
Hi Damir, Thanks for the report. Umut just pointed out this problem the other day and how to fix it, so we should have it fixed by the next release. Cheers, Tom On Mon, Apr 28, 2014 at 11:40 AM, Damir Simunic wrote: > I installed CoreOS 298 (with systemd 212) on a multi-homed machine with a > public and a private interface. It’s a data-center machine, and the provider > assigns both interfaces through DHCP. Stock CoreOS defaults to DHCP settings > for all network interfaces. > > When I boot the machine, the public interface (eno1) is missing a default > route, and the private interface eno2 instead has two (the first two lines > in the routing table below): > > Apr 25 12:52:15 garry systemd[1]: Started Network Service. > Apr 25 12:52:17 garry systemd-networkd[3041]: eno2: carrier on > Apr 25 12:52:18 garry systemd-networkd[3041]: eno2: DHCPv4 address > 10.60.120.27/26 via 0.0.0.0 > Apr 25 12:52:18 garry systemd-networkd[3041]: eno1: carrier on > Apr 25 12:52:18 garry systemd-networkd[3041]: eno2: link configured > Apr 25 12:52:18 garry systemd-networkd[3041]: eno1: DHCPv4 address > 33.112.217.84/24 via 33.112.217.1 > Apr 25 12:52:18 garry systemd-networkd[3041]: eno1: link configured > > > # route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse > Iface > 0.0.0.0 0.0.0.0 255.255.255.255 UH0 00 eno2 > 0.0.0.0 0.0.0.0 0.0.0.0 U 0 00 eno2 > 10.60.120.0 0.0.0.0 255.255.255.192 U 0 00 eno2 > 33.112.217.00.0.0.0 255.255.255.0 U 0 00 eno1 > 33.112.217.10.0.0.0 255.255.255.255 UH0 00 eno1 > > > Restarting the systemd-networkd.service, correctly assigns the default route > for eno1: > > # systemctl restart systemd-networkd.service > > > Apr 25 12:54:09 garry systemd-networkd[3144]: eno1: DHCPv4 address > 33.112.217.84/24 via 33.112.217.1 > Apr 25 12:54:09 garry systemd-networkd[3144]: eno1: link configured > Apr 25 12:54:09 garry systemd-networkd[3144]: eno2: DHCPv4 address > 10.60.120.27/26 via 0.0.0.0 > Apr 25 12:54:10 garry systemd-networkd[3144]: eno2: link configured > > > # route -n > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse > Iface > 0.0.0.0 0.0.0.0 255.255.255.255 UH0 00 eno2 > 0.0.0.0 33.112.217.10.0.0.0 UG0 00 eno1 > 10.60.120.0 0.0.0.0 255.255.255.192 U 0 00 eno2 > 33.112.217.00.0.0.0 255.255.255.0 U 0 00 eno1 > 33.112.217.10.0.0.0 255.255.255.255 UH0 00 eno1 > > > This happens consistently on every boot. I worked around this by assigning a > static address to the public interface, but nevertheless wanted to point > this out as a possible bug. > > Thanks, > Damir > > > ___ > 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] Run script before the first systemd-timer is triggered? Systemd-timer in UTC?
Mantas Mikulėnas gmail.com> writes: > Doesn't the kernel already do the same via CONFIG_RTC_HCTOSYS_DEVICE? The kernel reads from "/dev/rtc0" which is the CPU built-in RTC (iMX233). My added RTC has to be registered first and then appears as /dev/rtc1. Greetings, Manuel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd freezes after rshd execution, if network connection is down
Hi, We stumbled upon a freeze/block in systemd. The problem occurs when a rshd (socket activated) execution is completed, the network connection is down and systemd is closing the socket. This causes a long (60 seconds) freeze where it's not possible to communicate with systemd. Do you have any idea on what is causing this or how we can investigate this further? To reproduce the problem: 1) Get latest Arch Linux 2) On remote machine execute rsh $target_ip -l root 'sleep 40' 3) Set link down on the interface which is assigned with $target_ip, on systemd machine ip link set down dev $if 4) On systemd machine, wait for 'sleep 40' to be completed. Then execute any systemd command systemctl list-jobs 5) After 60 seconds systemd is responding again By looking at the stack trace (see bellow), one can see that we are trying to close a socket and waiting on a system close call. So it's probably not a systemd problem, however systemd is affected by it. We've succesfully reproduced the problem on different hardware architectures (x86_64, arm, cris), systemd versions (208, 210, 212) and rshd implementations (netkit-rsh-0.17, inetutils 1.9.2-1). The problem occurs not only when the interface's link is set down, also when the IP address is removed or the ethernet cable is unplugged. ssh seems not to be affected by the problem. We generated a core dump: kill -SIGABRT 1 Here is the stack trace (the machine is running systemd 210). (gdb) bt #0 0xb6f4d830 in raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:46 #1 0x000527e8 in crash.4282 (sig=6) at apps/systemd/systemd/src/core/main.c:156 #2 #3 0xb6f4c28c in close () from target/armv6-axis-linux-gnueabi/lib/libpthread.so.0 #4 0x0009417c in close_nointr (fd=) at apps/systemd/systemd/src/shared/util.c:167 #5 0x00094250 in close_nointr_nofail (fd=) at apps/systemd/systemd/src/shared/util.c:191 #6 0x00073e0c in service_close_socket_fd.9824 (s=s@entry=0x1b6f918) at apps/systemd/systemd/src/core/service.c:229 #7 0x00079728 in service_set_state.9835 (s=s@entry=0x1b6f918, state=SERVICE_DEAD) at apps/systemd/systemd/src/core/service.c:1496 #8 0x00079b70 in service_enter_dead.9847 (s=0x1b6f918, f=, allow_restart=) at apps/systemd/systemd/src/core/service.c:1852 #9 0x00065470 in service_sigchld_event (u=0x1b6f918, pid=, code=1, status=0) at apps/systemd/systemd/src/core/service.c:3037 #10 0x00073490 in invoke_sigchld_event.5410 (m=m@entry=0x1ad7360, u=0x1b6f918, si=0xbe862670, si@entry=0xbe862668) at apps/systemd/systemd/src/core/manager.c:1430 #11 0x00054084 in manager_dispatch_sigchld.5415 (m=m@entry=0x1ad7360) at apps/systemd/systemd/src/core/manager.c:1477 #12 0x000629b0 in manager_dispatch_signal_fd.part.32 (userdata=) at apps/systemd/systemd/src/core/manager.c:1723 #13 manager_dispatch_signal_fd.5363 (source=, fd=, revents=, userdata=0x1ad7360) at apps/systemd/systemd/src/core/manager.c:1508 #14 0x0003e880 in source_dispatch (s=0x1ad7758) at apps/systemd/systemd/src/libsystemd/sd-event/sd-event.c:1861 #15 0x00041288 in sd_event_run (e=0x1ad61d8, timeout=) at apps/systemd/systemd/src/libsystemd/sd-event/sd-event.c:2117 #16 0x000103c8 in manager_loop (m=0x1ad7360) at apps/systemd/systemd/src/core/manager.c:1844 #17 main (argc=1, argv=0xbe862ee4) at apps/systemd/systemd/src/core/main.c:1704 Thanks, Jimmy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Run script before the first systemd-timer is triggered? Systemd-timer in UTC?
On 04/28/2014 01:36 PM, Manuel Reimer wrote: Mantas Mikulėnas gmail.com> writes: Doesn't the kernel already do the same via CONFIG_RTC_HCTOSYS_DEVICE? The kernel reads from "/dev/rtc0" which is the CPU built-in RTC (iMX233). My added RTC has to be registered first and then appears as /dev/rtc1. Hi, You can define which RTC (/dev/rtcX) should be read - "(rtc1) RTC used to set the system time" option in kernel menuconfig. Greetings, Manuel BR, -- Lukasz Skalski Samsung R&D Institute Poland Samsung Electronics l.skal...@samsung.com ___ 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] Run script before the first systemd-timer is triggered? Systemd-timer in UTC?
Lukasz Skalski samsung.com> writes: > You can define which RTC (/dev/rtcX) should be read - > "(rtc1) RTC used to set the system time" option in kernel menuconfig. Yes, this is possible. But my RTC does not exist until I do the following on shell: echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device Is there some other config option to tell the kernel to auto-initialize the I2C clock module? Thanks in advance. Greetings, Manuel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core/cryptsetup: Add WantsMountFor option to enable fallback to password request for crypt mounts. Signed-off-by: Przemek Rudy
Hi Tom,
Sure, I'll get rid of this signed-off soon and re-send.
It has been tested with fedora 20 for all three options:
- with device inserted
- with device removed during startup but inserted before the mount timeout
- with device removed
Thanks
Przemek
On 04/28/2014 10:15 AM, Tom Gundersen wrote:
> On Mon, Apr 28, 2014 at 12:46 AM, Przemek Rudy wrote:
>> This patch is a proposal for a problem with not falling back to password
>> request
>> if the device with unlocking key for crypt volumes is not mounted for
>> defined time.
>
> Looks good to me (but I didn't test it). Only one minor nit below.
>
> Also, you probably want to rewrite the subject of the patch (you can
> drop the signed-off-by as we don't use that here).
>
> Cheers,
>
> Tom
>
>> ---
>> src/core/dbus-unit.c | 1 +
>> src/core/load-fragment-gperf.gperf.m4 | 1 +
>> src/core/load-fragment.c | 47 +++
>> src/core/load-fragment.h | 1 +
>> src/core/manager.c| 15
>> src/core/manager.h| 6 ++
>> src/core/mount.c | 25 +-
>> src/core/unit.c | 144
>> ++
>> src/core/unit.h | 5 ++
>> src/cryptsetup/cryptsetup-generator.c | 3 +-
>> 10 files changed, 246 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/core/dbus-unit.c b/src/core/dbus-unit.c
>> index 07e7f20..31a35e9 100644
>> --- a/src/core/dbus-unit.c
>> +++ b/src/core/dbus-unit.c
>> @@ -516,6 +516,7 @@ const sd_bus_vtable bus_unit_vtable[] = {
>> SD_BUS_PROPERTY("ReloadPropagatedFrom", "as",
>> property_get_dependencies, offsetof(Unit,
>> dependencies[UNIT_RELOAD_PROPAGATED_FROM]), SD_BUS_VTABLE_PROPERTY_CONST),
>> SD_BUS_PROPERTY("JoinsNamespaceOf", "as",
>> property_get_dependencies, offsetof(Unit,
>> dependencies[UNIT_JOINS_NAMESPACE_OF]), SD_BUS_VTABLE_PROPERTY_CONST),
>> SD_BUS_PROPERTY("RequiresMountsFor", "as", NULL, offsetof(Unit,
>> requires_mounts_for), SD_BUS_VTABLE_PROPERTY_CONST),
>> +SD_BUS_PROPERTY("WantsMountsFor", "as", NULL, offsetof(Unit,
>> wants_mounts_for), SD_BUS_VTABLE_PROPERTY_CONST),
>> SD_BUS_PROPERTY("Documentation", "as", NULL, offsetof(Unit,
>> documentation), SD_BUS_VTABLE_PROPERTY_CONST),
>> SD_BUS_PROPERTY("Description", "s", property_get_description, 0,
>> SD_BUS_VTABLE_PROPERTY_CONST),
>> SD_BUS_PROPERTY("LoadState", "s", property_get_load_state,
>> offsetof(Unit, load_state), SD_BUS_VTABLE_PROPERTY_CONST),
>> diff --git a/src/core/load-fragment-gperf.gperf.m4
>> b/src/core/load-fragment-gperf.gperf.m4
>> index 21bccbb..4e51866 100644
>> --- a/src/core/load-fragment-gperf.gperf.m4
>> +++ b/src/core/load-fragment-gperf.gperf.m4
>> @@ -139,6 +139,7 @@ Unit.PropagateReloadFrom,config_parse_unit_deps,
>> UNIT_RELOAD
>> Unit.PartOf, config_parse_unit_deps,
>> UNIT_PART_OF, 0
>> Unit.JoinsNamespaceOf, config_parse_unit_deps,
>> UNIT_JOINS_NAMESPACE_OF, 0
>> Unit.RequiresMountsFor, config_parse_unit_requires_mounts_for, 0,
>> 0
>> +Unit.WantsMountsFor, config_parse_unit_wants_mounts_for, 0,
>> 0
>> Unit.StopWhenUnneeded, config_parse_bool, 0,
>> offsetof(Unit, stop_when_unneeded)
>> Unit.RefuseManualStart, config_parse_bool, 0,
>> offsetof(Unit, refuse_manual_start)
>> Unit.RefuseManualStop, config_parse_bool, 0,
>> offsetof(Unit, refuse_manual_stop)
>> diff --git a/src/core/load-fragment.c b/src/core/load-fragment.c
>> index 3b36d15..24c1849 100644
>> --- a/src/core/load-fragment.c
>> +++ b/src/core/load-fragment.c
>> @@ -2048,6 +2048,52 @@ int config_parse_unit_requires_mounts_for(
>> return 0;
>> }
>>
>> +int config_parse_unit_wants_mounts_for(
>> +const char *unit,
>> +const char *filename,
>> +unsigned line,
>> +const char *section,
>> +unsigned section_line,
>> +const char *lvalue,
>> +int ltype,
>> +const char *rvalue,
>> +void *data,
>> +void *userdata) {
>> +
>> +Unit *u = userdata;
>> +char *state;
>> +size_t l;
>> +char *w;
>> +
>> +assert(filename);
>> +assert(lvalue);
>> +assert(rvalue);
>> +assert(data);
>> +
>> +FOREACH_WORD_QUOTED(w, l, rvalue, state) {
>> +int r;
>> +_cleanup_free_ char *n;
>> +
>> +n = strndup(w, l);
>> +if (!n)
>> +return log_oom();
>> +
>> +if (!utf8_is_va
Re: [systemd-devel] Run script before the first systemd-timer is triggered? Systemd-timer in UTC?
On 04/28/2014 02:22 PM, Manuel Reimer wrote:
Lukasz Skalski samsung.com> writes:
You can define which RTC (/dev/rtcX) should be read -
"(rtc1) RTC used to set the system time" option in kernel menuconfig.
Yes, this is possible. But my RTC does not exist until I do the following on
shell:
echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
Is there some other config option to tell the kernel to auto-initialize the
I2C clock module?
One of possibilities is add i2c_board_info struct in
../arch/arm/XXX-mach/your_device.c file. For example:
static struct i2c_board_info __initdata XXX_i2c_devices[] = {
{
I2C_BOARD_INFO("rtc-ds1307", 0x68),
.type = "ds1307",
},
};
And in the same file (in __init XXX_init(void) function):
i2c_register_board_info(1,bcm2708_i2c_devices,ARRAY_SIZE(XXX_i2c_devices));
BR,
--
Lukasz Skalski
Samsung R&D Institute Poland
Samsung Electronics
l.skal...@samsung.com
Thanks in advance.
Greetings,
Manuel
___
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] Accessing journal entries
I am trying to access the journal using the HTTP interface, as described here: http://www.freedesktop.org/software/systemd/man/systemd-journal-gatewayd.service.html I want to filter journal entries by starting date/time or until a specific date/time and by number of lines. These are similar to journalctl's --since, --until and -n switches. The question was, can it done by the HTTP API exposed by journal ? I really appreciate your feedback. Thanks, Rupak Ganguly ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Host and machine ids are equal (4c93d957bcf44b289c3e4edb5bd5c355): refusing to link journals
On Sat, 26.04.14 15:35, Ruben Kerkhof (ru...@rubenkerkhof.com) wrote: > Hi list, > > I was just playing with systemd-nspawn, and noticed that when I start a > container in a virtual machine running on KVM, > it gets the same machine-id as the vm itself, resulting in: > Host and machine ids are equal (4c93d957bcf44b289c3e4edb5bd5c355): refusing > to link journals > > Is this by design, or is this a bug? How did you create the container tree? Did you copy the host's root into a subdirectory? Note that you need to make sure that /etc/machine-id is unique. When you copy the same image into multiple directories you hence need to regenerate the machine-id. Alternatively, remove the file in the container, as it will then create a new machine id on boot automatically, and store in the file. 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] [PATCH] logind: allow suspending if there are no displays
On Mon, 28.04.14 00:44, Mantas Mikulėnas (graw...@gmail.com) wrote:
> With proprietary graphics drivers, there won't be any 'drm' devices in
> sysfs, so logind will never suspend the system upon closing the lid,
> even if only one (internal) display is connected. This has been reported
> by multiple users so far.
>
> IMHO, it's better to suspend the system in this case for safety reasons,
> to avoid having nvidia blob users' laptops overheat, for the same reason
> that sleep inhibitors are overridden (LidSwitchIgnoreInhibited=yes).
Isn't the right approach to ask nivida to just support the normal kernel
APIs for this? I mean, we can tape over things, and we can shift arounds
so that things keep breaking for other people, but how about just asking
them to fix their stuff?
> ---
> src/login/logind-action.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/login/logind-action.c b/src/login/logind-action.c
> index 1928f43..c488f04 100644
> --- a/src/login/logind-action.c
> +++ b/src/login/logind-action.c
> @@ -86,7 +86,7 @@ int manager_handle_action(
> n = manager_count_displays(m);
> if (n < 0)
> log_warning("Display counting failed: %s",
> strerror(-n));
> -else if (n != 1) {
> +else if (n > 1) {
> log_debug("Ignoring lid switch request, %i displays
> connected.", n);
> return 0;
> }
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] [PATCH] core/cryptsetup: Add WantsMountFor option to enable fallback to password request for crypt mounts. Signed-off-by: Przemek Rudy
On Sun, 27.04.14 23:46, Przemek Rudy (pru...@o2.pl) wrote:
>
> This patch is a proposal for a problem with not falling back to password
> request
> if the device with unlocking key for crypt volumes is not mounted for
> defined time.
Can you elaborate on the usecase? I mean, this would still result in in
90s timeout, right? Or what's your idea here?
> +int config_parse_unit_wants_mounts_for(
> +const char *unit,
> +const char *filename,
> +unsigned line,
> +const char *section,
> +unsigned section_line,
> +const char *lvalue,
> +int ltype,
> +const char *rvalue,
> +void *data,
> +void *userdata) {
> +}
Sounds like a call to unify with
config_parse_unit_requires_mounts_for(), and use the "ltype" param to
distuingish them.
> +/* Adds in links to other units that use (want) this path or paths
> + * further down in the hierarchy */
> +s = manager_get_units_want_mounts_for(UNIT(m)->manager, m->where);
> +SET_FOREACH(other, s, i) {
> +
> +if (other->load_state != UNIT_LOADED)
> +continue;
> +
> +if (other == UNIT(m))
> +continue;
> +
> +r = unit_add_dependency(other, UNIT_AFTER, UNIT(m), true);
> +if (r < 0)
> +return r;
> +
> +if (UNIT(m)->fragment_path) {
> +/* If we have fragment configuration, then make this
> dependency required */
> +r = unit_add_dependency(other, UNIT_WANTS, UNIT(m),
> true);
> +if (r < 0)
> +return r;
> +}
> +}
> +
Something to unify with the "requires" codepath. For example, it should
be easy to turn most of the loop's body into a function of its own, that
could then be reused...
> +static void unit_free_wants_mounts_for(Unit *u) {
Same here..
Please, let's not let turn this into a game of copy/paste...
> +if (!strv_isempty(u->wants_mounts_for)) {
> +fprintf(f,
> +"%s\tWantsMountsFor:", prefix);
> +
> +STRV_FOREACH(j, u->wants_mounts_for)
> +fprintf(f, " %s", *j);
> +
> +fputs("\n", f);
> +}
> +
Same here...
> +STRV_FOREACH(i, u->wants_mounts_for) {
> +char prefix[strlen(*i) + 1];
> +
> +PATH_FOREACH_PREFIX_MORE(prefix, *i) {
> +Unit *m;
> +
> +r = manager_get_unit_by_path(u->manager, prefix,
> ".mount", &m);
> +if (r < 0)
> +return r;
> +if (r == 0)
> +continue;
> +if (m == u)
> +continue;
> +
> +if (m->load_state != UNIT_LOADED)
> +continue;
> +
> +r = unit_add_dependency(u, UNIT_AFTER, m, true);
> +if (r < 0)
> +return r;
> +
> +if (m->fragment_path) {
> +r = unit_add_dependency(u, UNIT_WANTS, m,
> true);
> +if (r < 0)
> +return r;
> +}
> +}
> +}
> +
Not funny anymore.
> return 0;
> }
>
> @@ -3289,6 +3357,82 @@ int unit_require_mounts_for(Unit *u, const char *path)
> {
> return 0;
> }
>
> +int unit_want_mounts_for(Unit *u, const char *path) {
Totally not funny anymore...
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] Run script before the first systemd-timer is triggered? Systemd-timer in UTC?
On Mon, 28.04.14 07:48, Manuel Reimer (manuel.s...@nurfuerspam.de) wrote: > Hello, > > I want to run systemd on a embedded linux board. I have connected a RTC > module via I2C. > > What I want to do is to set the time via "hwclock --hctosys" during > boot. I can only recommend to make sure that the kernel knows how to reach the RTC, so that it comes up with the RTC initialized right-away. > I have to do this before the first systemd-timer is triggered. > > How do I have to create my service-file to set the time as early as > possible? All timers by default are ordered after sysinit.target (unless this is explicitly disabled via DefaultDependencies=no on the timer unit files). Hence, if you order your services before sysinit.target (which means the service should itself have DefaultDependencies=no), then you should be fine. Also note that systemd will notice system clock changes and recalculate the next elapsation. > Second question: Do I have to use "localtime" for systemd timers or is it > possible to set a timer wich, for example, is triggered daily at 04:00 > UTC? Currently we only support the local timezone, but we have a TODO list item to make it possible to specify times in UTC too. However, full timezone support is going to be difficult, because the Unix timezone APIs are so bad... 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] Host and machine ids are equal (4c93d957bcf44b289c3e4edb5bd5c355): refusing to link journals
On Mon, Apr 28, 2014 at 5:07 PM, Lennart Poettering wrote: > On Sat, 26.04.14 15:35, Ruben Kerkhof (ru...@rubenkerkhof.com) wrote: > >> Hi list, >> >> I was just playing with systemd-nspawn, and noticed that when I start a >> container in a virtual machine running on KVM, >> it gets the same machine-id as the vm itself, resulting in: >> Host and machine ids are equal (4c93d957bcf44b289c3e4edb5bd5c355): refusing >> to link journals >> >> Is this by design, or is this a bug? > > How did you create the container tree? Did you copy the host's root into > a subdirectory? Note that you need to make sure that /etc/machine-id is > unique. When you copy the same image into multiple directories you hence > need to regenerate the machine-id. I used pacstrap on Arch to create the tree, as described in https://wiki.archlinux.org/index.php/Arch_systemd_container After running 'pacstrap -i -c -d ~/testcontainer base' ~/testcontainer/etc/machine-id is indeed a copy of /etc/machine-id on the host. I'm not sure how it gets there yet, looking into it... > > Alternatively, remove the file in the container, as it will then create > a new machine id on boot automatically, and store in the file. Tried that, it does generate a machine-id, but the same one as on the host. [ruben@vm ~]$ sudo rm testcontainer/etc/machine-id [ruben@vm ~]$ sudo systemd-nspawn -bD ~/testcontainer And on the third line, the boot output shows: Initializing machine ID from KVM UUID. Looking at the code in machine-id-setup.c:generate, it seems that it first checks if we're running in a kvm vm, and only if that's not the case, if we're running in a container. > > Lennart Kind regards, Ruben ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Run script before the first systemd-timer is triggered? Systemd-timer in UTC?
On Mon, 28.04.14 11:36, Manuel Reimer (manuel.s...@nurfuerspam.de) wrote: > Mantas Mikulėnas gmail.com> writes: > > Doesn't the kernel already do the same via CONFIG_RTC_HCTOSYS_DEVICE? > > The kernel reads from "/dev/rtc0" which is the CPU built-in RTC (iMX233). My > added RTC has to be registered first and then appears as /dev/rtc1. Why do you have two RTCs even enabled? What's the logic there? And why isn't rtc0 just fine? If it doesn't work, why have it enabled at all? 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] Run script before the first systemd-timer is triggered? Systemd-timer in UTC?
On Mon, 28.04.14 12:22, Manuel Reimer (manuel.s...@nurfuerspam.de) wrote: > > Lukasz Skalski samsung.com> writes: > > You can define which RTC (/dev/rtcX) should be read - > > "(rtc1) RTC used to set the system time" option in kernel menuconfig. > > Yes, this is possible. But my RTC does not exist until I do the following on > shell: > > echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device > > Is there some other config option to tell the kernel to auto-initialize the > I2C clock module? Isn't this something devicetree can solve? (not that i knew anything about devicetree or embedded hardware...) 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] [PATCH 1/1] networkd: Introduce ipip tunnel
On Fri, 25.04.14 19:36, Tom Gundersen (t...@jklm.no) wrote: > [sorry for breaking the quoting, hopefully it is clear who said what] > > I actually think this is the correct way to do it, as the addresses > (which I assume is what Jóhann is objecting to?) are properties of the > link (similar to mac addresses, mtu, etc) rather than regular ip > addresses that you can configure for normal devices. Or maybe I'm > missing something? Anyone else have any input on this? This is solely about whether Local= and Remote= belong in .netdev? I am pretty sure they do, after all this is a weird setup: a tunnel is something where the link level is actually the network level of the underlying stack. Hence I think it is right to configure the "low-level" local and remot IP addresses of the tunnel in .netdev, as long as the "high-level" local/remote IP addresses of the tunnel stay in .network, if what I write here makes any sense... 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] [PATCH 1/1] networkd: Introduce ipip tunnel
On Mon, Apr 28, 2014 at 5:53 PM, Lennart Poettering wrote: > > This is solely about whether Local= and Remote= belong in .netdev? That's my take. > I am > pretty sure they do, after all this is a weird setup: a tunnel is > something where the link level is actually the network level of the > underlying stack. Hence I think it is right to configure the "low-level" > local and remot IP addresses of the tunnel in .netdev, as long as the > "high-level" local/remote IP addresses of the tunnel stay in .network, > if what I write here makes any sense... Then we agree. -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Run script before the first systemd-timer is triggered? Systemd-timer in UTC?
On 04/28/2014 05:47 PM, Lennart Poettering wrote: Why do you have two RTCs even enabled? What's the logic there? And why isn't rtc0 just fine? If it doesn't work, why have it enabled at all? "rtc0" is part of the CPU (iMX233) and only works if a LiPo battery is connected. I prefer a RTC chip with small 3V lithium button cell backup which is connected as second RTC (rtc1). So you are right. The right way to go is to disable rtc0 at all and get my added RTC chip enabled as the one and only primary RTC. I'll have a look at "device tables" to see if it's possible to solve my problem with this. Thanks to everyone for the help. Greetings, Manuel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Host and machine ids are equal (4c93d957bcf44b289c3e4edb5bd5c355): refusing to link journals
On Mon, 28.04.14 17:45, Ruben Kerkhof (ru...@rubenkerkhof.com) wrote: > > Alternatively, remove the file in the container, as it will then create > > a new machine id on boot automatically, and store in the file. > > Tried that, it does generate a machine-id, but the same one as on the host. > > [ruben@vm ~]$ sudo rm testcontainer/etc/machine-id > [ruben@vm ~]$ sudo systemd-nspawn -bD ~/testcontainer > > And on the third line, the boot output shows: > Initializing machine ID from KVM UUID. Oh yuck, this looks like a bug in systemd. Currently if /etc/machine-id is missing we will try to initialize it from the UUID that KVM maintaines for each machine. However, this is a bad idea if we are actually running inside a container already... I fixed this now in 984233ceb6dfeecd8b43864795a660a200e4ac78 (I hope). Please verify. 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] [PATCH] core/cryptsetup: Add WantsMountFor option to enable fallback to password request for crypt mounts. Signed-off-by: Przemek Rudy
Hi Lennart,
inline...
On 04/28/2014 04:31 PM, Lennart Poettering wrote:
> On Sun, 27.04.14 23:46, Przemek Rudy (pru...@o2.pl) wrote:
>
>>
>> This patch is a proposal for a problem with not falling back to password
>> request
>> if the device with unlocking key for crypt volumes is not mounted for
>> defined time.
>
> Can you elaborate on the usecase? I mean, this would still result in in
> 90s timeout, right? Or what's your idea here?
This does not change any cryptsetup timeout. It simply allows using it.
As when the key device is not in place the cryptsetup is not started at
all and thus its internal timeout does not work either.
>
>> +int config_parse_unit_wants_mounts_for(
>> +const char *unit,
>> +const char *filename,
>> +unsigned line,
>> +const char *section,
>> +unsigned section_line,
>> +const char *lvalue,
>> +int ltype,
>> +const char *rvalue,
>> +void *data,
>> +void *userdata) {
>> +}
>
> Sounds like a call to unify with
> config_parse_unit_requires_mounts_for(), and use the "ltype" param to
> distuingish them.
Yes, duplicated code. However still the question what is worth more -
duplicate one loop or add a parameter change body adding two if-f and
then replace all original calls to original function...
I do not insists on any, keep this for purists.
>
>> +/* Adds in links to other units that use (want) this path or paths
>> + * further down in the hierarchy */
>> +s = manager_get_units_want_mounts_for(UNIT(m)->manager, m->where);
>> +SET_FOREACH(other, s, i) {
>> +
>> +if (other->load_state != UNIT_LOADED)
>> +continue;
>> +
>> +if (other == UNIT(m))
>> +continue;
>> +
>> +r = unit_add_dependency(other, UNIT_AFTER, UNIT(m), true);
>> +if (r < 0)
>> +return r;
>> +
>> +if (UNIT(m)->fragment_path) {
>> +/* If we have fragment configuration, then make
>> this dependency required */
>> +r = unit_add_dependency(other, UNIT_WANTS, UNIT(m),
>> true);
>> +if (r < 0)
>> +return r;
>> +}
>> +}
>> +
>
> Something to unify with the "requires" codepath. For example, it should
> be easy to turn most of the loop's body into a function of its own, that
> could then be reused...
>
>> +static void unit_free_wants_mounts_for(Unit *u) {
>
> Same here..
>
> Please, let's not let turn this into a game of copy/paste...
>
>> +if (!strv_isempty(u->wants_mounts_for)) {
>> +fprintf(f,
>> +"%s\tWantsMountsFor:", prefix);
>> +
>> +STRV_FOREACH(j, u->wants_mounts_for)
>> +fprintf(f, " %s", *j);
>> +
>> +fputs("\n", f);
>> +}
>> +
>
> Same here...
>
>> +STRV_FOREACH(i, u->wants_mounts_for) {
>> +char prefix[strlen(*i) + 1];
>> +
>> +PATH_FOREACH_PREFIX_MORE(prefix, *i) {
>> +Unit *m;
>> +
>> +r = manager_get_unit_by_path(u->manager, prefix,
>> ".mount", &m);
>> +if (r < 0)
>> +return r;
>> +if (r == 0)
>> +continue;
>> +if (m == u)
>> +continue;
>> +
>> +if (m->load_state != UNIT_LOADED)
>> +continue;
>> +
>> +r = unit_add_dependency(u, UNIT_AFTER, m, true);
>> +if (r < 0)
>> +return r;
>> +
>> +if (m->fragment_path) {
>> +r = unit_add_dependency(u, UNIT_WANTS, m,
>> true);
>> +if (r < 0)
>> +return r;
>> +}
>> +}
>> +}
>> +
>
> Not funny anymore.
>
>> return 0;
>> }
>>
>> @@ -3289,6 +3357,82 @@ int unit_require_mounts_for(Unit *u, const char
>> *path) {
>> return 0;
>> }
>>
>> +int unit_want_mounts_for(Unit *u, const char *path) {
>
> Totally not funny anymore...
Same answer to all, duplicate few loops or do more changes?
So do I understand correctly, you want this to be funny somehow? What
are the preferences tehn, using parameter to all common functions?
I'll wait anyway few days for any more comments on this, if no more I
can do the changes.
>
> Lennart
>
Thanks
Przemek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] unit: add waiting jobs to run queue in unit_coldplug
On Fri, 25.04.14 15:39, Brandon Philips (bran...@ifup.co) wrote: > On Wed, Apr 23, 2014 at 2:36 PM, Lennart Poettering > wrote: > > This looks correct, but could you move this into job_coldplug()? > > I rewrote the patch to be in job_coldplug() and tested. Patch attached. This has been applied 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] [PATCH 2/2] core: let selinux_setup() load policy more than once
On Fri, Apr 25, 2014 at 6:26 PM, Will Woods wrote: But if SELinux was already initialized, selinux_setup() skips loading policy and returns 0. So if you load policy normally, and then you switch-root to a new root that has new policy, selinux_setup() never loads the new policy. What gives? I think your analysis is correct, and the patch looks good to me. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: let selinux_setup() load policy more than once
On Fri, 2014-04-25 at 18:26 -0400, Will Woods wrote: > Currently, systemd refuses to load SELinux policy more than once. > > Normal systems don't care, because they either: > a) have initramfs without policy, then load policy after switch-root, or > b) load policy in initramfs, and never switch-root out. > > But if you *do* switch-root more than once - which fedup does! - you're > supposed to run selinux_init_load_policy() afterward to ensure that you set up > selinuxfs and load the new SELinux policy correctly. For reference, here's the thread from seli...@tycho.nsa.gov where this was discussed: http://marc.info/?l=selinux&m=139782596307221&w=2 The upshot is: yes, we're supposed to do selinux_init_load_policy() after *every* switch-root. -w ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] core: Filter by state behind the D-Bus API, not in the systemctl client.
From: David Strauss
---
src/core/dbus-manager.c| 24 +++-
src/core/org.freedesktop.systemd1.conf | 4
src/systemctl/systemctl.c | 24 +---
3 files changed, 40 insertions(+), 12 deletions(-)
diff --git a/src/core/dbus-manager.c b/src/core/dbus-manager.c
index 135d314..febf475 100644
--- a/src/core/dbus-manager.c
+++ b/src/core/dbus-manager.c
@@ -728,7 +728,7 @@ static int method_reset_failed(sd_bus *bus, sd_bus_message
*message, void *userd
return sd_bus_reply_method_return(message, NULL);
}
-static int method_list_units(sd_bus *bus, sd_bus_message *message, void
*userdata, sd_bus_error *error) {
+static int list_units_filtered(sd_bus *bus, sd_bus_message *message, void
*userdata, sd_bus_error *error, char **states) {
_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
Manager *m = userdata;
const char *k;
@@ -761,6 +761,12 @@ static int method_list_units(sd_bus *bus, sd_bus_message
*message, void *userdat
following = unit_following(u);
+if (!strv_isempty(states) &&
+!strv_contains(states,
unit_load_state_to_string(u->load_state)) &&
+!strv_contains(states,
unit_active_state_to_string(unit_active_state(u))) &&
+!strv_contains(states, unit_sub_state_to_string(u)))
+continue;
+
unit_path = unit_dbus_path(u);
if (!unit_path)
return -ENOMEM;
@@ -794,6 +800,21 @@ static int method_list_units(sd_bus *bus, sd_bus_message
*message, void *userdat
return sd_bus_send(bus, reply, NULL);
}
+static int method_list_units(sd_bus *bus, sd_bus_message *message, void
*userdata, sd_bus_error *error) {
+return list_units_filtered(bus, message, userdata, error, NULL);
+}
+
+static int method_list_units_filtered(sd_bus *bus, sd_bus_message *message,
void *userdata, sd_bus_error *error) {
+_cleanup_strv_free_ char **states = NULL;
+int r;
+
+r = sd_bus_message_read_strv(message, &states);
+if (r < 0)
+return r;
+
+return list_units_filtered(bus, message, userdata, error, states);
+}
+
static int method_list_jobs(sd_bus *bus, sd_bus_message *message, void
*userdata, sd_bus_error *error) {
_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
Manager *m = userdata;
@@ -1670,6 +1691,7 @@ const sd_bus_vtable bus_manager_vtable[] = {
SD_BUS_METHOD("ClearJobs", NULL, NULL, method_clear_jobs, 0),
SD_BUS_METHOD("ResetFailed", NULL, NULL, method_reset_failed, 0),
SD_BUS_METHOD("ListUnits", NULL, "a(ssouso)", method_list_units,
SD_BUS_VTABLE_UNPRIVILEGED),
+SD_BUS_METHOD("ListUnitsFiltered", "as", "a(ssouso)",
method_list_units_filtered, SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_METHOD("ListJobs", NULL, "a(usssoo)", method_list_jobs,
SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_METHOD("Subscribe", NULL, NULL, method_subscribe,
SD_BUS_VTABLE_UNPRIVILEGED),
SD_BUS_METHOD("Unsubscribe", NULL, NULL, method_unsubscribe,
SD_BUS_VTABLE_UNPRIVILEGED),
diff --git a/src/core/org.freedesktop.systemd1.conf
b/src/core/org.freedesktop.systemd1.conf
index a375dce..9dfca81 100644
--- a/src/core/org.freedesktop.systemd1.conf
+++ b/src/core/org.freedesktop.systemd1.conf
@@ -64,6 +64,10 @@
+
+
load_state) ||
-strv_contains(arg_states, u->sub_state) ||
-strv_contains(arg_states, u->active_state);
-
if (!strv_isempty(patterns)) {
char **pattern;
@@ -513,6 +507,7 @@ static int get_unit_list(
int c,
sd_bus_message **_reply) {
+_cleanup_bus_message_unref_ sd_bus_message *m = NULL;
_cleanup_bus_error_free_ sd_bus_error error = SD_BUS_ERROR_NULL;
_cleanup_bus_message_unref_ sd_bus_message *reply = NULL;
size_t size = c;
@@ -523,15 +518,22 @@ static int get_unit_list(
assert(unit_infos);
assert(_reply);
-r = sd_bus_call_method(
+r = sd_bus_message_new_method_call(
bus,
+&m,
"org.freedesktop.systemd1",
"/org/freedesktop/systemd1",
"org.freedesktop.systemd1.Manager",
-"ListUnits",
-&error,
-&reply,
-NULL);
+"ListUnitsFiltered");
+
+if (r < 0)
+return bus_log_create_error(r);
+
+r = sd_bus_message_append_strv(m, arg_states);
+if (r < 0)
+return bus_log_create_error(r);
+
+r = sd_bus_call(bus, m, 0, &error, &reply);
if (r < 0) {
log_error("Faile
Re: [systemd-devel] [PATCH] core: Filter by state behind the D-Bus API, not in the systemctl client.
This is a completed version of the patch Lennart and I worked on at the hackfest. The version we worked on had separate string arguments for each type of state. This patch harmonizes it more with the way systemctl --state already works, which is an array of possible states to match across all state types. ListUnits is retained for API compatibility, but systemctl is updated to always use ListUnitsFiltered, even with an empty array. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Host and machine ids are equal (4c93d957bcf44b289c3e4edb5bd5c355): refusing to link journals
On Mon, Apr 28, 2014 at 6:12 PM, Lennart Poettering wrote: > Oh yuck, this looks like a bug in systemd. > > Currently if /etc/machine-id is missing we will try to initialize it > from the UUID that KVM maintaines for each machine. However, this is a > bad idea if we are actually running inside a container already... > > I fixed this now in 984233ceb6dfeecd8b43864795a660a200e4ac78 (I > hope). Please verify. Thanks. Systemd now generates a random id instead of using the uuid from my kvm vm: Detected virtualization 'systemd-nspawn'. Detected architecture 'x86-64'. Welcome to Arch Linux! Initializing machine ID from random generator. Passing in a uuid doesn't seem to work though: [ruben@vm ~]$ sudo rm testcontainer/etc/machine-id [ruben@vm ~]$ uuid=$(uuidgen); echo $uuid d9611cff-f011-4c7c-8c76-2fe4154f7ed3 [ruben@vm ~]$ sudo systemd-nspawn -bD ~/testcontainer --uuid=$uuid Detected virtualization 'systemd-nspawn'. Detected architecture 'x86-64'. Welcome to Arch Linux! Initializing machine ID from random generator. I would have expected that to be 'Initializing machine ID from container UUID.' container_uuid is set in the environment: [root@testcontainer ~]# tr '\0' '\n' < /proc/1/environ | grep container container=systemd-nspawn container_uuid=d9611cfff0114c7c8c762fe4154f7ed3 Any ideas? Kind regards, Ruben ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] logind: allow suspending if there are no displays
Lennart Poettering poettering.net> writes:
>
> On Mon, 28.04.14 00:44, Mantas Mikulėnas (grawity gmail.com) wrote:
>
> > With proprietary graphics drivers, there won't be any 'drm' devices in
> > sysfs, so logind will never suspend the system upon closing the lid,
> > even if only one (internal) display is connected. This has been reported
> > by multiple users so far.
> >
> > IMHO, it's better to suspend the system in this case for safety reasons,
> > to avoid having nvidia blob users' laptops overheat, for the same reason
> > that sleep inhibitors are overridden (LidSwitchIgnoreInhibited=yes).
(Apologies if this messes up the thread - replying via gmane.org, since I
wasn't subscribed and wanted to reply in-thread easily.)
I was (probably) the last person on IRC to report the problem, the final
reason for this thread. grawity/Mantas was extremely helpful and tracked
down my problem remotely: Close the laptop, move elsewhere, laptop is
extremely hot and smells like warm plastic when I open it again. Happened
about half a dozen times and every time I unpacked that thing I expected it
to be dead for good, due to the temperature.
> Isn't the right approach to ask nivida to just support the normal kernel
> APIs for this? I mean, we can tape over things, and we can shift arounds
> so that things keep breaking for other people, but how about just asking
> them to fix their stuff?
Frankly? No. I'm a fan of your work and I happily run systemd. But if you
think that "Let's just make nvidia fix their drivers" is the right attitude,
I think that's a little extreme.. There's another guy that tried that
already - it would be just like giving Linus' middle finger again.
As a user:
- everything worked until recently (i.e. one of the recent systemd releases
broke what worked before - for this particular setup that behavior is a
regression)
- I didn't want the nvidia card (corporate laptop, not my choice) but need
3d acceleration at times. I have to keep the blob for now.
- I'd at least expect a workaround. If that's the way systemd/logind is
playing this out, there should be a way to say 'Okay, okay. I understand
that nvidia should cave in, but please suspend anyway'. As far as I know
there's none right now, other than running a (forever?) patched systemd from
source (with grawity/Mantas' patch).
- I first and foremost expect that the software I'm running isn't so
idealistic that it might cause damage to my hardware
Please reconsider this patch or document that limitation prominently. I'm
really trying to follow interesting/special news about all things systemd
and this change is totally unexpected (heck, logind isn't even logging
anything about it unless you learn the magic 'enable debug' incantation and
understand that it thinks that you have no display attached) and the
solutions present at the moment are all coming with major limitations
- Never close the lid w/o turning off the machine first
- Go back to a free driver and stop using everything 3d
- Stop using the upstream systemd packages and fork to fix the issues above
- Move to a different system / away from systemd
All of these suck. I hope you (both the team and you personally) think about
this some more and fix it in the single one possible place - where it was
introduced just a short while ago, here in logind.
As stated in the original patch notes: People that actually want to supress
suspend on lid close already have a way to do that and can still do that,
with that patch applied. The inverse - please, please do suspend whatever
displays you think I have - doesn't seem to exist.
Regards,
Ben
> > ---
> > src/login/logind-action.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/src/login/logind-action.c b/src/login/logind-action.c
> > index 1928f43..c488f04 100644
> > --- a/src/login/logind-action.c
> > +++ b/src/login/logind-action.c
> > -86,7 +86,7 int manager_handle_action(
> > n = manager_count_displays(m);
> > if (n < 0)
> > log_warning("Display counting failed: %s",
strerror(-n));
> > -else if (n != 1) {
> > +else if (n > 1) {
> > log_debug("Ignoring lid switch request, %i
displays connected.", n);
> > return 0;
> > }
>
> Lennart
>
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] nspawn: move container wait logic into wait_for_container() function
On Fri, Apr 25, 2014 at 08:07:29PM +0200, Tom Gundersen wrote:
> On Fri, Apr 11, 2014 at 2:45 AM, Djalal Harouni wrote:
> > Move the container wait logic into its own wait_for_container() function
> > and add two status codes: CONTAINER_TERMINATED or CONTAINER_REBOOTED
> >
> > These status codes are used to terminate nspawn or loop again in case of
> > CONTAINER_REBOOTED.
>
> Looks good, but some nit-picks below.
Ok
> > ---
> > src/nspawn/nspawn.c | 114
> > ++--
> > 1 file changed, 75 insertions(+), 39 deletions(-)
> >
> > diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
> > index 0bd52da..d606bf2 100644
> > --- a/src/nspawn/nspawn.c
> > +++ b/src/nspawn/nspawn.c
> > @@ -92,6 +92,11 @@
> > #include "seccomp-util.h"
> > #endif
> >
> > +typedef enum ContainerStatus {
> > +CONTAINER_TERMINATED,
> > +CONTAINER_REBOOTED
> > +} ContainerStatus;
> > +
> > typedef enum LinkJournal {
> > LINK_NO,
> > LINK_AUTO,
> > @@ -2565,6 +2570,72 @@ static int change_uid_gid(char **_home) {
> > return 0;
> > }
> >
> > +/* Return 0 in case the container is being rebooted, has been shut
> > + * down or exited succesfully. On failures a non-zero value is
> > + * returned.
> > + *
> > + * The status of the container "CONTAINER_TERMINATED" or
> > + * "CONTAINER_REBOOTED" will be saved in the container argument */
> > +static int wait_for_container(pid_t pid, ContainerStatus *container) {
> > +int r, k;
> > +siginfo_t status;
> > +
> > +/* Explicitly set this to CONTAINER_TERMINATED. If the reboot
> > + * conditions are met it will be updated to CONTAINER_REBOOTED */
> > +*container = CONTAINER_TERMINATED;
>
> We don't usually clobber the arguments unless we return successfully,
> so maybe delay this until we return.
Yes, but in this case in all the other paths it will be
CONTAINER_TERMINATED, so I just avoided the:
if (!x) x = 1;
And here it doesn't matter if we return successfully, since on errors
the container will also be considered terminated. So I didn't want to
change the semantics.
> > +r = EXIT_FAILURE;
> > +k = wait_for_terminate(pid, &status);
> > +if (k < 0)
> > +return r;
>
> Maybe better to just return k here, as EXIT_FAILURE is usually only
> used in main() (also I think you can then drop k and just use r).
Yes, thanks, will do.
> > +if (status.si_code == CLD_EXITED) {
>
> Wouldn't this be better as a big switch?
Ok I'll try it.
> > +r = status.si_status;
> > +if (status.si_status != 0) {
> > +log_error("Container %s failed with error code
> > %i.",
> > + arg_machine, status.si_status);
> > +goto out;
>
> Why not just "return status.si_status" and drop the out: label?
Please see below
> > +}
> > +
> > +if (!arg_quiet)
> > +log_debug("Container %s exited successfully.",
> > + arg_machine);
> > +
> > +} else if (status.si_code == CLD_KILLED &&
> > + status.si_status == SIGINT) {
> > +
> > +if (!arg_quiet)
> > +log_info("Container %s has been shut down.",
> > + arg_machine);
> > +r = 0;
>
> Same, just return directly, or let it fall through to a final "return
> 0" (and set *container here).
Usually I find it easy to read, if there is a one final return for the
multiple branches. So I'll keep your second suggestion.
Ok, Tom will update and re-send, (sorry for the late response).
> > +} else if (status.si_code == CLD_KILLED &&
> > + status.si_status == SIGHUP) {
> > +
> > +if (!arg_quiet)
> > +log_info("Container %s is being rebooted.",
> > + arg_machine);
> > +r = 0;
> > +*container = CONTAINER_REBOOTED;
> > +
> > +} else if (status.si_code == CLD_KILLED ||
> > + status.si_code == CLD_DUMPED) {
> > +
> > +log_error("Container %s terminated by signal %s.",
> > + arg_machine, signal_to_string(status.si_status));
> > +r = EXIT_FAILURE;
> > +
> > +} else {
> > +log_error("Container %s failed due to unknown reason.",
> > + arg_machine);
> > +r = EXIT_FAILURE;
> > +}
> > +
> > +out:
> > +return r;
> > +}
> > +
> > int main(int argc, char *argv[]) {
> >
> > _cleanup_free_ char *kdbus_domain = NULL, *device_path = NULL,
> > *root_device = NULL, *home_device = NULL, *srv_device = NULL;
> > @@ -2743,8 +2814,8 @@ int main(int argc, char *argv[]) {
> > assert_se(sigprocmask(SIG_BLOCK, &mask, NULL) == 0);
> >
>
Re: [systemd-devel] [PATCH 3/3] nspawn: allow to bind mount journal on top of a non empty container journal dentry
On Fri, Apr 25, 2014 at 08:30:36PM +0200, Tom Gundersen wrote:
> On Fri, Apr 11, 2014 at 2:45 AM, Djalal Harouni wrote:
> > Currently if nspawn was called with --link-journal=host or
> > --link-journal=auto and the right /var/log/journal/machine-id/ exists
> > then the bind mount the subdirectory into the container might fail due
> > to the ~/mycontainer/var/log/journal/machine-id/ of the container not
> > being empty.
> >
> > There is no reason to check if the container journal subdir is empty
> > since there will be a bind mount on top of it. The user asked for a bind
> > mount so give it.
> >
> > Note: a next call with --link-journal=guest may fail due to the
> > /var/log/journal/machine-id/ on the host not being empty.
> >
> > https://bugs.freedesktop.org/show_bug.cgi?id=76193
>
> Hm, so this will allow some journal entries to be saved on the host
> and some on the guest, but only one of them
> will be shown by "journalctl --merge" at any given time... Won't this
> be confusing? Either way I guess this case
> should be documented in the manpage (either that it is not allowed, or
> that it may be confusing)...
Yes, to be honest, I'm also not sure! but I guess if the user wants to
move to the host, perhaps give him a chance, or at least document as you
have suggested, and warn during systemd-nspawn (will verify it later).
So I'll wait to see what others think, or perhaps extend journalctl to
make this part of --merge ... ?
Thanks!
> > Reported-by: Tobias Hunger
> > ---
> > src/nspawn/nspawn.c | 5 -
> > 1 file changed, 5 deletions(-)
> >
> > diff --git a/src/nspawn/nspawn.c b/src/nspawn/nspawn.c
> > index 21322f7..afb003c 100644
> > --- a/src/nspawn/nspawn.c
> > +++ b/src/nspawn/nspawn.c
> > @@ -1152,11 +1152,6 @@ static int setup_journal(const char *directory) {
> > } else if (access(p, F_OK) < 0)
> > return 0;
> >
> > -if (dir_is_empty(q) == 0) {
> > -log_error("%s not empty.", q);
> > -return -ENOTEMPTY;
> > -}
> > -
> > r = mkdir_p(q, 0755);
> > if (r < 0) {
> > log_error("Failed to create %s: %m", q);
> > --
> > 1.8.5.3
> >
> > ___
> > systemd-devel mailing list
> > systemd-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Djalal Harouni
http://opendz.org
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Run script before the first systemd-timer is triggered? Systemd-timer in UTC?
Op 28 apr. 2014, om 17:48 heeft Lennart Poettering het
volgende geschreven:
> On Mon, 28.04.14 12:22, Manuel Reimer (manuel.s...@nurfuerspam.de) wrote:
>
>>
>> Lukasz Skalski samsung.com> writes:
>>> You can define which RTC (/dev/rtcX) should be read -
>>> "(rtc1) RTC used to set the system time" option in kernel menuconfig.
>>
>> Yes, this is possible. But my RTC does not exist until I do the following on
>> shell:
>>
>> echo ds1307 0x68 > /sys/class/i2c-adapter/i2c-1/new_device
>>
>> Is there some other config option to tell the kernel to auto-initialize the
>> I2C clock module?
>
> Isn't this something devicetree can solve? (not that i knew anything
> about devicetree or embedded hardware...)
Devicetree can handle that, but the following under the i2c node:
rtc@68 {
compatible = "dallas,ds1307";
reg = <0x68>;
};
While I haven't tried it, you might be able to use aliases to make the ds1307
rtc0, but if not, do a 'status=disabled' in the on-chip rtc node.
regards,
Koen
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
