Re: [systemd-devel] systemd-timesyncd with read-only root filesystem
Hello André, André Hartmann [2016-12-08 9:28 +0100]: > My main problem is that I cannot disable NTP by setting > the link to /dev/null as the root partition is read-only. Well, of course you can't change the image configuration after building it -- you need to disable the service in the image build process. If you don't have any writable files you can naturally not change the unit configuration. Maybe I'm missing something here, but this in no way timedated or even systemd specific? > And till now I don't understand how timedatectl decides > "NTP enabled: yes/no". I need a possibility to disable NTP > in case the user will set the date by hand (also enabling > it again if the user decides otherwise). This actually sounds like you do want to keep at least parts of /etc/ writable, as otherwise there is no place to store things like "disabled services" or "changed time zone". > Which confuses me is the inconsistency between > "systemctl status systemd.timesyncd" and "timedatectl status": > > # systemctl status systemd.timesyncd > * systemd.timesyncd.service >Loaded: not-found (Reason: No such file or directory) >Active: inactive (dead) > > # timedatectl status > Local time: Wed 2016-12-07 16:18:06 UTC > Universal time: Wed 2016-12-07 16:18:06 UTC > RTC time: n/a >Time zone: Universal (UTC, +) > NTP enabled: yes > NTP synchronized: no > RTC in local TZ: no > DST active: n/a I don't see an inconsistency? If timedated is not running then timedatectl can't actualy talk to it and just shows values which it can make up by itself. 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 https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timesyncd with read-only root filesystem
On Thu, 8 Dec 2016, André Hartmann wrote: [...] Which confuses me is the inconsistency between "systemctl status systemd.timesyncd" and "timedatectl status": # systemctl status systemd.timesyncd * systemd.timesyncd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) You've got a typo there -- the unit is called systemd-timesyncd.service, with a hyphen: $ systemctl status systemd-timesyncd.service ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: disabled) ... (You can also just use "systemd-timesyncd", since systemctl will assume a .service suffix.) - Michael___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] About http://0pointer.net/blog/avoiding-cve-2016-8655-with-systemd.html
On Fri, 09.12.16 02:01, Reindl Harald (h.rei...@thelounge.net) wrote: > > > Am 09.12.2016 um 01:56 schrieb Michael Biebl: > > Btw, I think we are lacking a good systemd sandboxing howto/tutorial. > > The one linked from fdo > > (http://0pointer.de/blog/projects/security.html) is pretty dated and > > the systemd.exec man page is not coherent enough with regards to > > security/sandboxing. > > > > Related to that, I think it would be good if we would annotate in the > > man page, which sandboxing features work for user services and which > > don't. It's not always immediately obvious which feature requires root > > privileges > > "requires root privileges" - a question here > > in my understaing that features are applied *before* drop the privileges to > "User" and "Group" All sandboxing features should work for services run by systemd running as PID 1, regardless if in combination with User=, or not. Services of the systemd --user instances have a more limited set. There pretty much only the options basedon seccomp are available, as that's the only interface that doesn't require privileges. Specifically that's RestrictNamespaces=, RestrictAddressFamilies=, SystemCallArchitectures=, SystemCallFilter=. And yes, this could use some better documentation, and there's a bug open about it. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timesyncd with read-only root filesystem
Hi Martin, thanks for keeping our dialog alive :) To sum up again what I actually want to achive: I want to use NTP after bootup by default, but in case no NTP is available, the user should be able to set the date and time by hand with timedatectl. But timedatectl refuses to do so, if "NTP is enabled". And this is my main problem: I don't know how timedatectl decides if NTP is enabled or not. The one and only thing I need, is to set the date by hand if necessary. Preferable without file write access in /etc. The configuration of most of our programs is fixed, and for the ones that need it, we have a symlink to a writeable partition. I didn't get this to work for the time configuration so far. Which confuses me is the inconsistency between "systemctl status systemd.timesyncd" and "timedatectl status": # systemctl status systemd.timesyncd * systemd.timesyncd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) # timedatectl status Local time: Wed 2016-12-07 16:18:06 UTC Universal time: Wed 2016-12-07 16:18:06 UTC RTC time: n/a Time zone: Universal (UTC, +) NTP enabled: yes NTP synchronized: no RTC in local TZ: no DST active: n/a I don't see an inconsistency? If timedated is not running then timedatectl can't actualy talk to it and just shows values which it can make up by itself. The inconsistence here is, that timesyncd is not running/dead (could not be started because no valid symlink to /lib/systemd/system/systemd-timesyncd exists) but timedatectl insists that NTP is enabled. Thanks for your help, André ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timesyncd with read-only root filesystem
Hi Michael, Am 09.12.2016 um 10:25 schrieb Michael Chapman: On Thu, 8 Dec 2016, André Hartmann wrote: [...] Which confuses me is the inconsistency between "systemctl status systemd.timesyncd" and "timedatectl status": # systemctl status systemd.timesyncd * systemd.timesyncd.service Loaded: not-found (Reason: No such file or directory) Active: inactive (dead) You've got a typo there -- the unit is called systemd-timesyncd.service, Your'e right, I had a typo. But after checking again, I discovered the following: cat /etc/systemd/system/sysinit.target.wants/systemd-timesyncd (empty) But systemctl status systemd-timesyncd says active (running) The link structure is as follows: /etc/systemd/system/sysinit.target.wants/systemd-timesyncd -> /mnt/writeable/systemd-timesyncd -> /dev/null So there is no inconsistency, but timesyncd is started even if it's not linked from /etc/systemd/system/sysinit.target.wants This is not what I expect. Thanks, André $ systemctl status systemd-timesyncd.service ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: disabled) ... (You can also just use "systemd-timesyncd", since systemctl will assume a .service suffix.) - Michael -- Best regards / Mit freundlichen Grüßen André Hartmann, Dipl.-Ing. (FH) Software Project Manager iseg Spezialelektronik GmbH | phone: ++49 (0)351 26996-43 Bautzner Landstr. 23| fax: ++49 (0)351 26996-21 D-01454 Radeberg / Rossendorf | web: www.iseg-hv.com Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig Amtsgericht / Lower district court: Dresden HRB 16250 Ust.-Id.-Nr. / VAT-ID: DE812508942 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] using SYSTEMD_ALIAS with devices that re-appear on different sysfs path
Hi!
I'd like to uniquely identify USB-disks according to their GTP disk UUID
and assign a corresponding systemd device unit in order to be able to
start/stop services based on them.
However, whenever a USB device is unplugged and replugged again soon
(within a few seconds), there seems to be a small amount of time, where
the old block device node is still there:
Dez 08 21:14:35 apu systemd[1]: Device
sys-block-by\x2duuid-d28e3352\x2d7ce6\x2d4aab\x2d802a\x2d59270088604e.device
appeared twice with different sysfs paths
/sys/devices/pci:00/:00:1d.0/:03:00.0/usb4/4-1/4-1:1.0/host5/target5:0:0/5:0:0:0/block/sdc
and
/sys/devices/pci:00/:00:1d.0/:03:00.0/usb4/4-1/4-1:1.0/host6/target6:0:0/6:0:0:0/block/sdg
In those cases, the new SYSTEMD_ALIAS device is not created. (The alias
pointing to the old sysfs path is also removed some moments later.)
Is there a way to override this behavior so that the new device alias
will override the old one?
Thanks,
--leo
I am using systemd-219-19.el7_2.13.x86_64.
udev rules:
---
KERNEL=="sd*", ENV{DEVTYPE}=="disk", ENV{ID_DISK_GUID}!="?*",
IMPORT{program}="/etc/udev/gpt-disk-uuid.sh $devnode"
ENV{DEVTYPE}=="disk", ENV{ID_DISK_GUID}=="?*", RUN+="/usr/bin/logger -t
udevinfo -p daemon.info disk %k, guid: $env{ID_DISK_GUID}"
ENV{DEVTYPE}=="disk", ENV{ID_DISK_GUID}=="?*",
SYMLINK+="disk/by-uuid/$env{ID_DISK_GUID}"
ENV{DEVTYPE}=="disk", ENV{ID_DISK_GUID}=="?*",
ENV{SYSTEMD_ALIAS}+="/sys/block/by-uuid/$env{ID_DISK_GUID}"
syslog:
---
disconnect:
Dez 08 21:14:26 apu kernel: usb 4-1: USB disconnect, device number 17
Dez 08 21:14:26 apu kernel: scsi 5:0:0:0: rejecting I/O to offline device
Dez 08 21:14:26 apu kernel: scsi 5:0:0:0: [sdc] killing request
Dez 08 21:14:26 apu kernel: scsi 5:0:0:0: [sdc] FAILED Result:
hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
Dez 08 21:14:26 apu kernel: scsi 5:0:0:0: [sdc] CDB: Read(16) 88 00 00
00 00 00 08 00 10 60 00 00 00 20 00 00
Dez 08 21:14:26 apu kernel: blk_update_request: I/O error, dev sdc,
sector 134221920
Dez 08 21:14:26 apu systemd[1]: Stopping LVM2 PV scan on device 8:33...
Dez 08 21:14:26 apu systemd[1]: Stopping Spin down idle harddisk
d28e3352-7ce6-4aab-802a-59270088604e...
Dez 08 21:14:26 apu systemd[1]: Stopped Spin down idle harddisk
d28e3352-7ce6-4aab-802a-59270088604e.
Dez 08 21:14:26 apu lvm[10494]: Device 8:33 not found. Cleared from
lvmetad cache.
Dez 08 21:14:26 apu systemd[1]: Stopped LVM2 PV scan on device 8:33.
Dez 08 21:14:26 apu systemd[1]: Stopping LVM2 PV scan on device 8:81...
Dez 08 21:14:26 apu systemd[1]: Stopping Spin down idle harddisk
84128055-e167-4f20-bb14-b3634d177d5e...
Dez 08 21:14:26 apu systemd[1]: Stopped Spin down idle harddisk
84128055-e167-4f20-bb14-b3634d177d5e.
Dez 08 21:14:26 apu lvm[10500]: Device 8:81 not found. Cleared from
lvmetad cache.
Dez 08 21:14:26 apu systemd[1]: Stopped LVM2 PV scan on device 8:81.
Dez 08 21:14:26 apu systemd-udevd[651]: error opening USB device
'descriptors' file
Dez 08 21:14:34 apu kernel: usb 4-1: new SuperSpeed USB device number 18
using xhci_hcd
Dez 08 21:14:34 apu kernel: usb 4-1: New USB device found,
idVendor=152d, idProduct=9561
Dez 08 21:14:34 apu kernel: usb 4-1: New USB device strings: Mfr=1,
Product=2, SerialNumber=5
Dez 08 21:14:34 apu kernel: usb 4-1: Product: JMS56x Series
Dez 08 21:14:34 apu kernel: usb 4-1: Manufacturer: JMicron
Dez 08 21:14:34 apu kernel: usb 4-1: SerialNumber:
Dez 08 21:14:34 apu kernel: usb 4-1: UAS is blacklisted for this device,
using usb-storage instead
Dez 08 21:14:34 apu kernel: usb-storage 4-1:1.0: USB Mass Storage device
detected
Dez 08 21:14:34 apu kernel: usb-storage 4-1:1.0: Quirks match for vid
152d pid 9561: 900400
Dez 08 21:14:34 apu kernel: scsi host6: usb-storage 4-1:1.0
Dez 08 21:14:35 apu kernel: scsi 6:0:0:0: Direct-Access WDC WD30
PURX-64P6ZY0 0106 PQ: 0 ANSI: 6
Dez 08 21:14:35 apu kernel: scsi 6:0:0:1: Direct-Access WDC WD30
PURX-64P6ZY0 0106 PQ: 0 ANSI: 6
Dez 08 21:14:35 apu kernel: sd 6:0:0:0: Attached scsi generic sg1 type 0
Dez 08 21:14:35 apu kernel: sd 6:0:0:1: Attached scsi generic sg2 type 0
Dez 08 21:14:35 apu kernel: sd 6:0:0:0: [sdg] Very big device. Trying to
use READ CAPACITY(16).
Dez 08 21:14:35 apu kernel: sd 6:0:0:0: [sdg] 5860533168 512-byte
logical blocks: (3.00 TB/2.73 TiB)
Dez 08 21:14:35 apu kernel: sd 6:0:0:1: [sdh] Very big device. Trying to
use READ CAPACITY(16).
Dez 08 21:14:35 apu kernel: sd 6:0:0:0: [sdg] Write Protect is off
Dez 08 21:14:35 apu kernel: sd 6:0:0:0: [sdg] Mode Sense: 47 00 10 08
Dez 08 21:14:35 apu kernel: sd 6:0:0:1: [sdh] 5860533168 512-byte
logical blocks: (3.00 TB/2.73 TiB)
Dez 08 21:14:35 apu kernel: sd 6:0:0:0: [sdg] No Caching mode page found
Dez 08 21:14:35 apu kernel: sd 6:0:0:0: [sdg] Assuming drive cache:
write through
Dez 08 21:14:35 apu kernel: sd 6:0:0:1: [sdh] Write Protect is off
Dez 08 21:14:35 apu kernel: sd 6:0:0:1: [sdh] Mode Sense: 47 00 10 08
Dez 08 21:14:35 apu kernel: sd 6:0:
Re: [systemd-devel] systemd-timesyncd with read-only root filesystem
On Fri, 9 Dec 2016, André Hartmann wrote: Hi Michael, Am 09.12.2016 um 10:25 schrieb Michael Chapman: On Thu, 8 Dec 2016, André Hartmann wrote: [...] > Which confuses me is the inconsistency between > "systemctl status systemd.timesyncd" and "timedatectl status": > > # systemctl status systemd.timesyncd > * systemd.timesyncd.service > Loaded: not-found (Reason: No such file or directory) > Active: inactive (dead) You've got a typo there -- the unit is called systemd-timesyncd.service, Your'e right, I had a typo. But after checking again, I discovered the following: cat /etc/systemd/system/sysinit.target.wants/systemd-timesyncd (empty) But systemctl status systemd-timesyncd says active (running) The link structure is as follows: /etc/systemd/system/sysinit.target.wants/systemd-timesyncd -> /mnt/writeable/systemd-timesyncd -> /dev/null You will need to use the .service extension on at least the first of those links. systemd will only consider links in that directory that have valid unit names. (I'm pretty sure the intermediate link's name doesn't matter, but I wouldn't want to rely on that -- best just to use valid full unit names everywhere.) - Michael___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timesyncd with read-only root filesystem
On Fri, 9 Dec 2016, Michael Chapman wrote: [...] Your'e right, I had a typo. But after checking again, I discovered the following: cat /etc/systemd/system/sysinit.target.wants/systemd-timesyncd (empty) But systemctl status systemd-timesyncd says active (running) The link structure is as follows: /etc/systemd/system/sysinit.target.wants/systemd-timesyncd -> /mnt/writeable/systemd-timesyncd -> /dev/null You will need to use the .service extension on at least the first of those links. systemd will only consider links in that directory that have valid unit names. (I'm pretty sure the intermediate link's name doesn't matter, but I wouldn't want to rely on that -- best just to use valid full unit names everywhere.) Oh, something else I thought of... I'm pretty sure it doesn't make sense having a symlink to /dev/null inside a .wants directory. Really, only the name of those links are considered. The links aren't actually dereferenced. - Michael ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timesyncd with read-only root filesystem
On Fri, Dec 09, 2016 at 10:46:51AM +0100, André Hartmann wrote: > Hi Martin, > > thanks for keeping our dialog alive :) > > To sum up again what I actually want to achive: > > I want to use NTP after bootup by default, but in case no NTP is available, > the user should be able to set the date and time by hand > with timedatectl. But timedatectl refuses to do so, if "NTP is enabled". > > And this is my main problem: I don't know how timedatectl decides > if NTP is enabled or not. Just use the source code? Anyway, if you use systemd's implementation of that API (systemd-timesyncd), the check is here: https://github.com/systemd/systemd/blob/master/src/timedate/timedated.c#L180 i.e. timedated checks if systemd-timesyncd is enabled. If you use other implementations, the check can be different. For example timedatex checks if any of units listed in /etc/systemd/ntp-units.d:/usr/lib/systemd/ntp-units.d is enabled. Implementation in systembsd runs "/etc/rc.d/ntpd status" and checks status. And so on. -- Tomasz .. oo o. oo o. .o .o o. o. oo o. .. Torcz.. .o .o .o .o oo oo .o .. .. oo oo o.o.o. .o .. o. o. o. o. o. o. oo .. .. o. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timesyncd with read-only root filesystem
Hi Michael, Am 09.12.2016 um 12:43 schrieb Michael Chapman: On Fri, 9 Dec 2016, Michael Chapman wrote: [...] You will need to use the .service extension on at least the first of those links. systemd will only consider links in that directory that have valid unit names. (I'm pretty sure the intermediate link's name doesn't matter, but I wouldn't want to rely on that -- best just to use valid full unit names everywhere.) Oh, something else I thought of... I'm pretty sure it doesn't make sense having a symlink to /dev/null inside a .wants directory. Really, only the name of those links are considered. The links aren't actually dereferenced. I have to disagree on this, the name does not matter, the link target does matter (see log below, the relevant status is marked with <---). If I create a link named foo pointing to /lib/systemd/system/systemd-timesyncd.service the service is enabled and started. If I delete the link, the service is disabled and not started. Everything is fine. But it requires write access to /etc. If I create a link structure like this: /etc/systemd/system/sysinit.target.wants/systemd-timesyncd -> /mnt/writeable/systemd-timesyncd -> /lib/systemd/system/systemd-timesyncd.service the service is also started (Good). But if I then change the structure to /etc/systemd/system/sysinit.target.wants/systemd-timesyncd -> /mnt/writeable/systemd-timesyncd -> /dev/null timedatectl still says "NTP is enabled". And at this point I don't know how to proceed. Best regards, André Log: $ ssh root@192.168.16.14 Password: root@apalis-imx6:~# rm /etc/systemd/system/sysinit.target.wants/systemd-timesyncd.service root@apalis-imx6:~# reboot Connection to 192.168.16.14 closed by remote host. $ ssh root@192.168.16.14 Password: root@apalis-imx6:~# systemctl status systemd-timesyncd ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; disabled; vendor preset: enabled) <--- Active: inactive (dead) Docs: man:systemd-timesyncd.service(8) root@apalis-imx6:~# timedatectl Local time: Fri 2016-12-09 13:20:46 UTC Universal time: Fri 2016-12-09 13:20:46 UTC RTC time: n/a Time zone: Universal (UTC, +) NTP enabled: no < NTP synchronized: no RTC in local TZ: no DST active: n/a root@apalis-imx6:~# cd /etc/systemd/system/sysinit.target.wants/ root@apalis-imx6:/etc/systemd/system/sysinit.target.wants# mount-rw / root@apalis-imx6:/etc/systemd/system/sysinit.target.wants# ln -s /lib/systemd/system/systemd-timesyncd.service foo root@apalis-imx6:/etc/systemd/system/sysinit.target.wants# ll foo lrwxrwxrwx1 root root45 Dec 9 13:21 foo -> /lib/systemd/system/systemd-timesyncd.service root@apalis-imx6:/etc/systemd/system/sysinit.target.wants# reboot Connection to 192.168.16.14 closed by remote host. $ ssh root@192.168.16.14 Warning: Permanently added '192.168.16.14' (ECDSA) to the list of known hosts. Password: root@apalis-imx6:~# systemctl status systemd-timesyncd ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) <--- Active: inactive (dead) Docs: man:systemd-timesyncd.service(8) root@apalis-imx6:~# timedatectl Local time: Fri 2016-12-09 13:21:51 UTC Universal time: Fri 2016-12-09 13:21:51 UTC RTC time: n/a Time zone: Universal (UTC, +) NTP enabled: yes <--- NTP synchronized: no RTC in local TZ: no DST active: n/a root@apalis-imx6:~# ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-timesyncd with read-only root filesystem
On Fri, 9 Dec 2016, André Hartmann wrote: Hi Michael, Am 09.12.2016 um 12:43 schrieb Michael Chapman: On Fri, 9 Dec 2016, Michael Chapman wrote: [...] > You will need to use the .service extension on at least the first of > those links. systemd will only consider links in that directory that > have valid unit names. (I'm pretty sure the intermediate link's name > doesn't matter, but I wouldn't want to rely on that -- best just to > use valid full unit names everywhere.) Oh, something else I thought of... I'm pretty sure it doesn't make sense having a symlink to /dev/null inside a .wants directory. Really, only the name of those links are considered. The links aren't actually dereferenced. I have to disagree on this, the name does not matter, the link target does matter (see log below, the relevant status is marked with <---). Your log only shows that it's the presence of the link that matters, not what the link is pointing to. Here, I'll demonstrate: # cat >/etc/systemd/system/example.service
Re: [systemd-devel] About http://0pointer.net/blog/avoiding-cve-2016-8655-with-systemd.html
On 12/09/16 00:56, Michael Biebl wrote: > Btw, I think we are lacking a good systemd sandboxing howto/tutorial. > The one linked from fdo > (http://0pointer.de/blog/projects/security.html) is pretty dated and > the systemd.exec man page is not coherent enough with regards to > security/sandboxing. > > Related to that, I think it would be good if we would annotate in the > man page, which sandboxing features work for user services and which > don't. It's not always immediately obvious which feature requires root > privileges. Agreed. I started making a tool that helps with the systemd service unit settings. It's not finished (is any software ever finished), but can generate reasonable values from a representative test run of the service. Please check out: https://github.com/topimiettinen/systemd-settings-generator/blob/master/strace.stp Earlier announcement: https://lists.freedesktop.org/archives/systemd-devel/2016-August/037310.html -Topi ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
