Re: [systemd-devel] [PATCH 0/2] units: add and use ConditionInitrd= instead of checking for /etc/initrd-release.
Am 27.08.2014 um 22:48 schrieb Thomas Bächler: Am 27.08.2014 um 20:25 schrieb Ivan Shapovalov: On Wednesday 27 August 2014 at 20:19:45, Lennart Poettering wrote: On Wed, 27.08.14 20:26, Ivan Shapovalov (intelfx...@gmail.com) wrote: This is as proposed by Thomas in review of my hibernate-resume patchset. The objective benefit of this change is that in_initrd() function is used for checking, which not only checks for /etc/initrd-release, but also verifies that the rootfs is on a virtual device. If we add a new condition then I want to hear a strong case for it. On that note, where's the strong case for 'ConditionFirstBoot='? It's equivalent to ConditionPathExists=/run/systemd/first-boot. And it's needed in a single service. What makes this different from ConditionInitrd=? 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] [PATCHv6 2/3] hibernate-resume: add a tool to write a device node's major:minor to /sys/power/resume.
Am 26.08.2014 um 22:17 schrieb Ivan Shapovalov: This can be used to initiate a resume from hibernation by path to a swap device containing the hibernation image. The respective templated unit is also added. It is instantiated using path to the desired resume device. Really great stuff, this was really missing from systemd initrd. I only saw this because of your posting to the arch-projects list, so I am late to the party. Anyway, although this is commited to systemd.git, there's no reason it can't still be improved. diff --git a/units/systemd-hibernate-res...@.service.in b/units/systemd-hibernate-res...@.service.in new file mode 100644 index 000..6db584d --- /dev/null +++ b/units/systemd-hibernate-res...@.service.in @@ -0,0 +1,20 @@ +# This file is part of systemd. +# +# systemd is free software; you can redistribute it and/or modify it +# under the terms of the GNU Lesser General Public License as published by +# the Free Software Foundation; either version 2.1 of the License, or +# (at your option) any later version. + +[Unit] +Description=Resume from hibernation using device %f +Documentation=man:systemd-hibernate-resume@.service(8) +DefaultDependencies=no +BindsTo=%i.device What's the purpose of BindsTo= as opposed to Requires= here. They are both the same for a oneshot service, but the former is more confusing. +Wants=local-fs-pre.target +After=%i.device +Before=local-fs-pre.target systemd-remount-fs.service systemd-fsck-root.service The part of ordering this Before=local-fs-pre.target is so crucial, it can't be stressed enough. If _anything_ writes to _any_ file system before this service runs, your system is broken and your data is lost. That said, are you sure that all services are properly ordered against the target? What's the purpose of ordering this against systemd-fsck-root.service? This service is not run in initrd ever, because it checks 'ConditionPathIsReadWrite=!/', which always fails in initrd. +ConditionPathExists=/etc/initrd-release We should have and use ConditionInitrd=. I am surprised that this doesn't exist, but it really should. 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] [PATCHv6 2/3] hibernate-resume: add a tool to write a device node's major:minor to /sys/power/resume.
Am 27.08.2014 um 09:22 schrieb Ivan Shapovalov: +[Unit] +Description=Resume from hibernation using device %f +Documentation=man:systemd-hibernate-resume@.service(8) +DefaultDependencies=no +BindsTo=%i.device What's the purpose of BindsTo= as opposed to Requires= here. They are both the same for a oneshot service, but the former is more confusing. This is just because systemd-fsck@.service does the same. Seems like it's the established usage, as Andrei says. BindsTo= Configures requirement dependencies, very similar in style to Requires=, however in addition to this behavior, it also declares that this unit is stopped when any of the units listed suddenly disappears. Stopping a oneshot unit makes no sense, that's why I find BindsTo confusing. If systemd-fsck@.service does the same, then we should do the same thing here. The part of ordering this Before=local-fs-pre.target is so crucial, it can't be stressed enough. If _anything_ writes to _any_ file system before this service runs, your system is broken and your data is lost. That said, are you sure that all services are properly ordered against the target? I've spent quite some time verifying this. The only thing not covered is usr.mount (not sysroot-usr.mount), but Lennart says any configuration with initramfs's /usr split off is broken. I've never heard of such a configuration. (Yes, I assume that lvm2, mdadm/mdmon, dm-event and so on don't write to filesystems. If I'm wrong -- this needs to be fixed...) They really shouldn't. And they may be required for resuming (you can resume from swap on lvm on an encrypted container, which is a rather common setup). +ConditionPathExists=/etc/initrd-release We should have and use ConditionInitrd=. I am surprised that this doesn't exist, but it really should. Would you accept a patch adding that (using in_initrd()) and converting all uses of ConditionPathExists=/etc/initrd-release to this new condition statement? I am not the one to accept patches here, but I'd love to see this implemented. 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 0/2] units: add and use ConditionInitrd= instead of checking for /etc/initrd-release.
Am 27.08.2014 um 20:25 schrieb Ivan Shapovalov: On Wednesday 27 August 2014 at 20:19:45, Lennart Poettering wrote: On Wed, 27.08.14 20:26, Ivan Shapovalov (intelfx...@gmail.com) wrote: This is as proposed by Thomas in review of my hibernate-resume patchset. The objective benefit of this change is that in_initrd() function is used for checking, which not only checks for /etc/initrd-release, but also verifies that the rootfs is on a virtual device. If we add a new condition then I want to hear a strong case for it. I mean, what's wrong with checking for initrd-release? Why would that not suffice? Whether or not we are in initrd is what we want to check. The existence of /etc/initrd-release is an implementation detail. Having the same file check as a condition in units duplicates the code that has been implemented in the in_initrd() function. In addition, someone who writes unit files should not be forced to know these implementation details, but should have the proper condition documented for the purpose. That is all there is. 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] Networkd fails to activate the device on boot
Am 18.08.2014 um 12:41 schrieb Tom Gundersen: 1) The enp3s0 interface does not activate on boot. I need to restart networkd manually to make it work. Hm, that is decidedly uncool. It seems we are not aware of the link. Could you try with Environment=SYSTEMD_LOG_LEVEL=debug in your service file to get some more info (of course that may hide the bug)? Is this reproducible with current git (I don't know of any fix to this, but you never know). [2.211121] lije systemd[1]: Starting Network Service... [2.230579] lije systemd-networkd[356]: timestamp of '/etc/systemd/network' changed [2.231454] lije systemd-networkd[356]: qemu: Creating tuntap netdev: tap [2.232121] lije systemd-networkd[356]: qemu: loaded tap [2.234423] lije systemd-networkd[356]: qemu: link 3 added [2.234527] lije systemd-networkd[356]: qemu: udev initialized link [2.234630] lije systemd-networkd[356]: qemu: netdev has index 3 [2.234720] lije systemd-networkd[356]: qemu: flags change: +MULTICAST +BROADCAST [2.236465] lije systemd-networkd[356]: qemu: udev initialized link [2.236562] lije systemd-networkd[356]: sd-rtnl: discarding 20 bytes of incoming message [2.236703] lije systemd-networkd[356]: Sent message type=method_call sender=n/a destination=org.freedesktop.DBus object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0 error=n/a [2.236852] lije systemd-networkd[356]: qemu: link state is up-to-date [2.237117] lije systemd-networkd[356]: qemu: found matching network '/etc/systemd/network/01-qemu.network' [2.237673] lije systemd-networkd[356]: qemu: enslaved [2.23] lije systemd-networkd[356]: qemu: bringing link up [2.237876] lije systemd-networkd[356]: qemu: setting addresses [2.237972] lije systemd-networkd[356]: sd-rtnl: discarding 20 bytes of incoming message [2.238057] lije systemd-networkd[356]: rtnl: received address for a nonexistent link, ignoring [2.238155] lije systemd[1]: Started Network Service. [2.238263] lije systemd-networkd[356]: rtnl: received address for a nonexistent link, ignoring [2.238608] lije systemd-networkd[356]: qemu: flags change: +UP +RUNNING [2.238702] lije systemd-networkd[356]: Got message type=method_return sender=org.freedesktop.DBus destination=:1.2 object=n/a interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a [2.238810] lije systemd-networkd[356]: Got message type=signal sender=org.freedesktop.DBus destination=:1.2 object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 error=n/a [2.238906] lije systemd-networkd[356]: qemu: added address: 10.23.42.129/26 [2.238993] lije systemd-networkd[356]: qemu: addresses set [2.239328] lije systemd-networkd[356]: qemu: link configured [2.239430] lije systemd-networkd[356]: qemu: MAC address: 1a:de:ad:be:ef:01 [2.241023] lije systemd-networkd[356]: qemu: flags change: +LOWER_UP [2.241121] lije systemd-networkd[356]: qemu: gained carrier [3.316936] lije systemd-networkd[356]: qemu: added address: fe80::18de:adff:febe:ef01/64 (There is a service in the background that changes the MAC address of the qemu interface, that's why it changes). As you can see, there is no indication of either enp3s0 or lo. Now, if I bring enp3s0 up manually (ip link set dev enp3s0 up), this happens: [ 68.472579] lije systemd-networkd[356]: enp3s0 : link 2 added [ 68.472864] lije systemd-networkd[356]: enp3s0 : udev initialized link [ 68.473060] lije systemd-networkd[356]: enp3s0 : flags change: +UP +MULTICAST +BROADCAST [ 68.473242] lije systemd-networkd[356]: enp3s0 : link state is up-to-date [ 68.473429] lije systemd-networkd[356]: enp3s0 : found matching network '/etc/systemd/network/01-lan.network' [ 68.473578] lije systemd-networkd[356]: enp3s0 : enslaved [ 68.473718] lije systemd-networkd[356]: enp3s0 : setting addresses [ 68.473854] lije systemd-networkd[356]: sd-rtnl: discarding 20 bytes of incoming message [ 68.473988] lije systemd-networkd[356]: rtnl: received address for a nonexistent link, ignoring [ 68.474137] lije systemd-networkd[356]: rtnl: received address for a nonexistent link, ignoring [ 68.474275] lije systemd-networkd[356]: enp3s0 : added address: 10.23.42.4/26 [ 68.474424] lije systemd-networkd[356]: enp3s0 : addresses set [ 68.474565] lije systemd-networkd[356]: enp3s0 : setting routes [ 68.474975] lije systemd-networkd[356]: enp3s0 : routes set [ 68.475132] lije systemd-networkd[356]: enp3s0 : link configured [ 70.054677] lije systemd-networkd[356]: enp3s0 :
Re: [systemd-devel] Networkd fails to activate the device on boot
Am 18.08.2014 um 12:41 schrieb Tom Gundersen: 1) The enp3s0 interface does not activate on boot. I need to restart networkd manually to make it work. Hm, that is decidedly uncool. It seems we are not aware of the link. Could you try with Environment=SYSTEMD_LOG_LEVEL=debug in your service file to get some more info (of course that may hide the bug)? Is this reproducible with current git (I don't know of any fix to this, but you never know). I don't know if I'll get to it today, but I'll try to do it ASAP. I did not try latest git, and I'd like to avoid it on real hardware if possible. 2) The qemu interface does not have the correct MAC address. It gains a seemingly random address that is inconsistent across reboots. Oh fun, I should have known that allowing tun/tap devices to be special-cased would come back to bite us. The issue here is that we create tun/tap devices using an ioctl rather than the standard rtnl interface. This ioctl does not allow us to set MTU, mac address etc. We would have to fix that up after creating the device (over rtnl). I think the best solution would be to simply add support to the kernel for creating persistent tun/tap links over rtnl (seems like it should be very simple), so I don't think we should work around this in networkd. In the meantime, I will add warnings/documentation to networkd so people know that this won't work. I didn't know you can simply fix anything in the kernel. With the general inertia of kernel development, such a fix would take between 4 and 6 months to be available in a mainline release. Personally, I'd opt for the two-step process with ioctl+rtnl, which we could drop as soon as a new rtnl interface has existed for some time. For those who need the functionality, a work-aronud is to do it by dropping in a .link file, matching on the interface name. That was my first idea (before I even considered using a .netdev unit), since the tap interface was created by vde_switch. Here's the thing: .link units cannot match on names. There is no workaround for this problem with networkd only. 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] Networkd fails to activate the device on boot
Hello Tom, I am using systemd 215-4 from Arch Linux. I have the following configuration files in /etc/systemd/network: # 01-lan.network [Match] Name=enp3s0 [Network] Address=10.23.42.4/26 Gateway=10.23.42.3 # 01-qemu.netdev [NetDev] MACAddress=1a:de:ad:be:ef:01 Name=qemu Kind=tap # 01-qemu.network [Match] Name=qemu [Network] Address=10.23.42.129/26 I have two problems with this setup: 1) The enp3s0 interface does not activate on boot. I need to restart networkd manually to make it work. 2) The qemu interface does not have the correct MAC address. It gains a seemingly random address that is inconsistent across reboots. Here is an excerpt from the journal: [2.356909] lije systemd[1]: Starting Network Service... [2.377715] lije systemd-networkd[367]: rtnl: received address for a nonexistent link, ignoring [2.377862] lije systemd-networkd[367]: rtnl: received address for a nonexistent link, ignoring [2.377960] lije systemd-networkd[367]: qemu: link configured [2.379489] lije systemd[1]: Started Network Service. [ 57.298036] lije systemd[1]: Stopping Network Service... [ 57.298776] lije systemd-networkd[367]: Received SIGTERM from PID 1 (systemd). [ 57.364169] lije systemd[1]: Starting Network Service... [ 57.451984] lije systemd-networkd[490]: lo : gained carrier [ 57.452133] lije systemd[1]: Started Network Service. [ 57.492641] lije systemd-networkd[490]: qemu: link configured [ 57.492732] lije systemd-networkd[490]: enp3s0 : link configured [ 59.074472] lije systemd-networkd[490]: enp3s0 : gained carrier Any ideas? 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] systemd-fsck-root semantics
Am 02.07.2014 14:29, schrieb Daniel Drake: If I'm reading things right, actually the default behaviour is (when no hints are supplied in kernel cmdline) : 1. systemd runs fsck on root from initramfs 2. systemd mounts root fs ro 3. switch-root onto real system 4. systemd-fsck-root runs 5. systemd-remount-fs remounts / as rw Also just noticed another interesting thing - systemd-fsck-root.service is only loaded dynamically, when /etc/fstab has a non-zero passno for /. So maybe the idea is that anyone running a regular and modern dracut/systemd setup sets passno=0 for / in fstab, with the knowledge that fsck of / is done by the initramfs. Tom and me are thought this through a couple of months ago when I started looking into using Arch's mkinitcpio with systemd. We submitted a few changes to fsck handling back then. This is the setup we want to support (this is now the default in a new Arch installation): 1) fsck in initramfs 2) initramfs mounts rw 3) no re-fsck in the system This is still supported, for legacy systems that have not been reconfigured properly: 1) no fsck in initramfs, or no initramfs 2) initramfs or kernel mount ro 3) fsck in the system 4) remount rw in the system This setup works, but is not optimal: 1) fsck in initramfs 2) initramfs mounts ro 3) re-fsck in the system 4) remount rw in the system In this case, I always recommend mounting rw right away. However, you can also configure your fstab to skip fsck - I don't see why anyone would prefer this though. For your read-only case, you have two options: * Have an fstab entry for / with passno=0 * Don't list / in fstab I prefer the last option, since there is no benefit in adding / to fstab - IMO, the correct mount options should always be given via the kernel commandline to make remounting unnecessary. In my opinion, there is no need to change anything in systemd here, since all the right configuration options are already there. 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] Delaying (SSH) key generation until the urandom pool is initialized
Am 30.04.2014 10:23, schrieb Tom Gundersen: On 04/29/2014 09:30 PM, Tom Gundersen wrote: You can easily start the sockets early, but make the daemon itself wait for the key generation to finish. Thanks. Can you provide an example? I guess the last three files here would have the right dependencies: https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/openssh (I don't want to change the daemon code.) Your service needs to be socket activateable, which the default ssh daemon is not, but the per-instance version is. These files run sshd in inetd mode. This means that for each connection, a new sshd instance is created that will handle the connection. This is usually bad, but not in openssh's case, When sshd runs as a daemon and you connect to it, it will fork a new instance and reexec itself, the same happens when instantiating it from systemd. 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] backlight: do nothing if max_brightness is 0
Am 23.04.2014 07:00, schrieb Lennart Poettering: On Thu, 27.03.14 23:41, Thomas Bächler (tho...@archlinux.org) wrote: On virtually any newer Asus mainboard, the eeepc-wmi driver is loaded. It exposes a backlight device despite the lack of any physical backlight devices. This fake backlight device has max_brightness set to 0. Since the introduction of the clamp_brightness function, systemd-backlight tries to write '1' to brightness and fails. This patch changes systemd-backlight to exit gracefully when max_brightness is 0 before performing any action. This affects both the load and save actions. Humm. To me this appears like the driver is broken. The kernel should not expose a backlight device if there isn't any backend to it? Yes. Have you filed a kernel bug? No, I'll take care of it though. I have changed git now to still print a warning in this case, as we shouldn't silently tape over broken drivers. Very good. While we should not try to work with nonsense brightness values, a warning is perfectly fine. 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] Persistent timers delay Type=idle units
Am 22.04.2014 07:07, schrieb Lennart Poettering: On Fri, 18.04.14 11:34, Thomas Bächler (tho...@archlinux.org) wrote: According to [1], when a persistent timer runs its service on boot, it delays startup. Humm? What precisely do you mean by delays bootup? Just scheduling a timer unit should have about zero effect on boot times... If it does this would be a bug. From the description that I linked in the first post, it seems that the unit it started as soon as the timer is started. I don't know if delay bootup is the right expression, but the Type=idle units, like getty, don't start until the timer's unit finished starting up. What does systemctl list-jobs print when this happens? (i.e. when the bootup is supposedly delayed?) I'd have to build a test-case for this, since I have not seen any negative effect myself yet (I can't do this until later this week). I'm CC'ing the original reporter, maybe he can give more information. 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] Persistent timers delay Type=idle units
Am 22.04.2014 10:33, schrieb Tom Gundersen: On Tue, Apr 22, 2014 at 9:37 AM, Thomas Bächler tho...@archlinux.org wrote: I'm CC'ing the original reporter, maybe he can give more information. I think you forgot to do that... Strange stuff - he is listed in CC in the mail I received, but his address is missing on-list. 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] Network Manager and systemd-networkd.service
Am 16.04.2014 06:10, schrieb Andy Johnson: Hello, systemd-devel, I saw this in the manpage of systemd-networkd.service (in the systemd git tree) systemd-networkd.service, systemd-networkd — Network manager My question is: is systemd-networkd.service a replacement for the Network Manager No. networkd is aimed at configuration file based static network setups. It is supposed to be suitable for early boot (initrd) and for automatic network setup in containers and VMs. It is unlikely to ever include support for wifi. On a desktop or server with a single LAN connection, networkd may be a good choice. On a laptop that dynamically switches between LAN, Wifi, bluetooth-based tethering and networking via pidgeons, you want to use something like NetworkManager. See Tom Gundersen's G+ posts on the topic, he explains the goal and design of networkd in great detail. 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] gummiboot can't be installed on ESP which is soft RAID1 metadata=0.9 partition
Am 14.04.2014 18:16, schrieb Lennart Poettering: On Mon, 14.04.14 18:01, Francis Moreau (francis.m...@gmail.com) wrote: Hello, gummiboot install fails when ESP is MD RAID1 device using metadata 0.9 or 1.0. I don't think using such RAID for ESP would lead to issue. Is there any reason gummiboot doesn't want to be installed on such partition ? The installer will make sure that the ESP is on GPT and carries the right type UUID. We do that for safety reasons, since that's the requirement made by UEFI, and how the bootloader is found. You cannot place the ESP on sw RAID, since the firmware might want to write to the ESP (most won't do that, but could, and the tianocore implemenation you use in qemu certainly does). While this is unsafe, the firmware doesn't write to the ESP during normal operation (i.e. bootup and efivar configuration). Tianocore does not write to the ESP either, if used properly. Newer versions will allow to store efivars in the image itself instead of the ESP. Manual installation of gummiboot onto the ESP using efibootmgr does in fact yield the desired results - until you use the EFI shell to modify files on the ESP, then you'll obviously corrupt it. 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] core: Make sure a stamp file exists for all Persistent=true timers
Am 05.04.2014 17:32, schrieb Thomas Bächler: Am 05.04.2014 11:35, schrieb Tom Gundersen: On Wed, Apr 2, 2014 at 8:18 PM, Thomas Bächler tho...@archlinux.org wrote: If a persistent timer has no stamp file yet, it behaves just like a normal timer until it runs for the first time. If the system is always shut down while the timer is supposed to run, a stamp file is never created and Peristent=true has no effect. This patch fixes this by creating a stamp file with the current time when the timer is first started. If timers are started at early boot (which sounds like a common scenario), I guess /var will not yet be writable so this will be a noop, no? Maybe it would be better to write out these files at shutdown instead (before unmounting anything)? I failed to hit reply all last time, so apologies for sending you this mail twice, Tom. Persistent=true timers have an implicit dependency on RequiresMountsFor=/var/lib/systemd/timers. $ systemctl show -p RequiresMountsFor updatedb.timer RequiresMountsFor=/var/lib/systemd/timers $ systemctl cat updatedb.timer # /usr/lib/systemd/system/updatedb.timer [Unit] Description=Daily locate database update [Timer] OnCalendar=daily AccuracySec=12h Persistent=true I don't want to be annoying, but I'd really like an ACK or NAK on that patch. 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] Document CONFIG_NET_NS as a required kernel option
Am 10.04.2014 03:35, schrieb Lennart Poettering:
Simply try:
int func(...) {
static bool network_namespace_warning = false;
...
if (!network_namespace_warning) {
network_namespace_warning = true;
log_warn(...);
}
}
Zbyszek
Hmm, so actually this is more complex than this, since the network
namespace stuff is done after we fork() before we exec() in the child
process. That means having this as static variable won't help, since you
could only set the copy, never the variable in the parent.
So, why not issue the warning while parsing the configuration, i.e.
during daemon startup or reload?
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] core: Make sure a stamp file exists for all Persistent=true timers
Am 05.04.2014 11:35, schrieb Tom Gundersen: On Wed, Apr 2, 2014 at 8:18 PM, Thomas Bächler tho...@archlinux.org wrote: If a persistent timer has no stamp file yet, it behaves just like a normal timer until it runs for the first time. If the system is always shut down while the timer is supposed to run, a stamp file is never created and Peristent=true has no effect. This patch fixes this by creating a stamp file with the current time when the timer is first started. If timers are started at early boot (which sounds like a common scenario), I guess /var will not yet be writable so this will be a noop, no? Maybe it would be better to write out these files at shutdown instead (before unmounting anything)? I failed to hit reply all last time, so apologies for sending you this mail twice, Tom. Persistent=true timers have an implicit dependency on RequiresMountsFor=/var/lib/systemd/timers. $ systemctl show -p RequiresMountsFor updatedb.timer RequiresMountsFor=/var/lib/systemd/timers $ systemctl cat updatedb.timer # /usr/lib/systemd/system/updatedb.timer [Unit] Description=Daily locate database update [Timer] OnCalendar=daily AccuracySec=12h Persistent=true 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] use systemd.debug on the kernel command line, not debug
Am 03.04.2014 11:36, schrieb David Herrmann: On Thu, Apr 3, 2014 at 11:08 AM, Tom Gundersen t...@jklm.no wrote: Or is there actually a bug going on here? My impression from reading related discussions was that systemd.log_level=debug loglevel=debug triggers some bug (so in particular debug now triggers the bug). It was not clear to me whether boot itself hangs, or if log-in becomes impossible. Either way, I'm not able to reproduce it, so if anyone has any more info on this, that would be useful. There was a bug there which triggered the assertions. However, it has been fixed in -git for quite some time, so with -git systemd will _not_ log an unreasonable amount of information. Let me quote Linus from http://www.spinics.net/lists/kernel/msg1716484.html: No, we very much expose /proc/cmdline for a reason. System services are *supposed* to parse it, because it gives a unified way for people to pass in various flags. [...] And yes, that does include quiet and debug. Parsing them and doing something sane with them is not a bug, it's a feature. The original complaint was that the systemd debug output was so excessive that the system became unusable and the debug output unreadable. If what Hermann said above is true and that problem has been fixed, then the debug output is sane now and everything is fine. In that case, there is nothing to do. (In fact, the problem was already identified and fixed before this whole discussion started.) Is there anything else I am missing here? (Adding Linus and Greg to CC to see if there actually is something that I am missing.) 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] systemd-udevd seems to kill mount.ntfs started in rules scripts?
Am 03.04.2014 17:13, schrieb Barry Scott: But as soon as the script exits the mount.ntfs process is killed off by something? systemd-udevd maybe? From man udev's section on RUN: This can only be used for very short-running foreground tasks. Running an event process for a long period of time may block all further events for this or a dependent device. Starting daemons or other long-running processes is not appropriate for udev; the forked processes, detached or not, will be unconditionally killed after the event handling has finished. Instead of using RUN, use SYSTEMD_WANTS to start a .mount or .service unit that does your job. In the remove case, use RUN+=/usr/bin/systemctl stop --no-block foo.mount or similar. (Not that I think this is a good idea at all: Your volume will be unmounted after it has been remove already - you are asking for data corruption.) 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] [PATCH] core: Make sure a stamp file exists for all Persistent=true timers
If a persistent timer has no stamp file yet, it behaves just like a normal
timer until it runs for the first time. If the system is always shut down
while the timer is supposed to run, a stamp file is never created and
Peristent=true has no effect.
This patch fixes this by creating a stamp file with the current time
when the timer is first started.
---
src/core/timer.c | 40
1 file changed, 24 insertions(+), 16 deletions(-)
diff --git a/src/core/timer.c b/src/core/timer.c
index 6c85304..b0a9023 100644
--- a/src/core/timer.c
+++ b/src/core/timer.c
@@ -111,6 +111,23 @@ static int timer_add_default_dependencies(Timer *t) {
return unit_add_two_dependencies_by_name(UNIT(t), UNIT_BEFORE,
UNIT_CONFLICTS, SPECIAL_SHUTDOWN_TARGET, NULL, true);
}
+static void update_stampfile(Timer *t, usec_t timestamp) {
+_cleanup_close_ int fd = -1;
+
+mkdir_parents_label(t-stamp_path, 0755);
+
+/* Update the file atime + mtime, if we can */
+fd = open(t-stamp_path, O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0644);
+if (fd = 0) {
+struct timespec ts[2];
+
+timespec_store(ts[0], timestamp);
+ts[1] = ts[0];
+
+futimens(fd, ts);
+}
+}
+
static int timer_setup_persistent(Timer *t) {
int r;
@@ -496,22 +513,8 @@ static void timer_enter_running(Timer *t) {
dual_timestamp_get(t-last_trigger);
-if (t-stamp_path) {
-_cleanup_close_ int fd = -1;
-
-mkdir_parents_label(t-stamp_path, 0755);
-
-/* Update the file atime + mtime, if we can */
-fd = open(t-stamp_path, O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC,
0644);
-if (fd = 0) {
-struct timespec ts[2];
-
-timespec_store(ts[0], t-last_trigger.realtime);
-ts[1] = ts[0];
-
-futimens(fd, ts);
-}
-}
+if (t-stamp_path)
+update_stampfile(t, t-last_trigger.realtime);
timer_set_state(t, TIMER_RUNNING);
return;
@@ -539,6 +542,11 @@ static int timer_start(Unit *u) {
if (stat(t-stamp_path, st) = 0)
t-last_trigger.realtime = timespec_load(st.st_atim);
+else if (errno == ENOENT)
+/* The timer has never run before,
+ * make sure a stamp file exists.
+ */
+update_stampfile(t, now(CLOCK_REALTIME));
}
t-result = TIMER_SUCCESS;
--
1.9.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] backlight: do nothing if max_brightness is 0
Am 27.03.2014 23:41, schrieb Thomas Bächler: On virtually any newer Asus mainboard, the eeepc-wmi driver is loaded. It exposes a backlight device despite the lack of any physical backlight devices. This fake backlight device has max_brightness set to 0. Since the introduction of the clamp_brightness function, systemd-backlight tries to write '1' to brightness and fails. This patch changes systemd-backlight to exit gracefully when max_brightness is 0 before performing any action. This affects both the load and save actions. Ping? 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] [ANNOUNCE] systemd 212
Am 26.03.2014 00:28, schrieb Kay Sievers: * Timer units gained a new Persistent= switch. If enabled timers configured this way will save to disk when they have been last triggered. This information is then used on next reboot to possible execute overdue timer events, that couldn't take place because the system was powered off. This enables simple anacron-like behaviour for timer units. How do these timers interact with suspending or hibernation? If I suspend the system and resume after the timer should have elapsed, the timer won't be restarted. Will it still trigger on resume? (Use-case: A system that rarely reboots and has a timer set daily at midnight. The user always suspends the system at 11 and resumes it in the morning.) Another question: The documentation says that the timer will trigger immediately when it is started. Is this accurate or is there some holdoff time? 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] systemd v212 build error
Am 28.03.2014 12:41, schrieb Tom Gundersen: Side note: we might want to revisit how old kernels we want to support. Especially for building, we may want to just require something a bit more recent (maybe 3.10 or 3.12)? The kernel version during build is not an issue. Kernel headers are never included in userspace applications during build (except for horribly broken applications). In fact, at least on Arch, the kernel headers are not even installed during the build process. What this is about is the kernel's userspace API headers which are extracted from the kernel source and then used to build the C library. Upgrading the kernel will not change those. You only change those headers when you update or rebuild your toolchain. On Arch, we currently use headers from 3.13 by the way. Basically, what you are saying is that you want to drop support for building systemd with a toolchain generated from anything older than 3.10 or 3.12. Personally, I wouldn't care, but others might disagree. 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] [PATCH] backlight: do nothing if max_brightness is 0
On virtually any newer Asus mainboard, the eeepc-wmi driver is loaded.
It exposes a backlight device despite the lack of any physical backlight
devices. This fake backlight device has max_brightness set to 0. Since
the introduction of the clamp_brightness function, systemd-backlight
tries to write '1' to brightness and fails.
This patch changes systemd-backlight to exit gracefully when
max_brightness is 0 before performing any action. This affects
both the load and save actions.
---
Sorry, this diff looks extremely weird, but I couldn't get git-diff
to produce a nicer one.
src/backlight/backlight.c | 44 ++--
1 file changed, 30 insertions(+), 14 deletions(-)
diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index abf8bcf..ce0385b 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -192,30 +192,37 @@ static bool validate_device(struct udev *udev, struct
udev_device *device) {
return true;
}
-/* Some systems turn the backlight all the way off at the lowest levels.
- * clamp_brightness clamps the saved brightness to at least 1 or 5% of
- * max_brightness. This avoids preserving an unreadably dim screen, which
- * would otherwise force the user to disable state restoration. */
-static void clamp_brightness(struct udev_device *device, char **value) {
+static unsigned get_max_brightness(struct udev_device *device) {
int r;
const char *max_brightness_str;
-unsigned brightness, max_brightness, new_brightness;
+unsigned max_brightness;
max_brightness_str = udev_device_get_sysattr_value(device,
max_brightness);
if (!max_brightness_str) {
-log_warning(Failed to read max_brightness attribute; not
checking saved brightness);
-return;
+log_warning(Failed to read max_brightness attribute);
+return 0;
}
-r = safe_atou(*value, brightness);
+r = safe_atou(max_brightness_str, max_brightness);
if (r 0) {
-log_warning(Failed to parse brightness \%s\: %s, *value,
strerror(-r));
-return;
+log_warning(Failed to parse max_brightness \%s\: %s,
max_brightness_str, strerror(-r));
+return 0;
}
-r = safe_atou(max_brightness_str, max_brightness);
+return max_brightness;
+}
+
+/* Some systems turn the backlight all the way off at the lowest levels.
+ * clamp_brightness clamps the saved brightness to at least 1 or 5% of
+ * max_brightness. This avoids preserving an unreadably dim screen, which
+ * would otherwise force the user to disable state restoration. */
+static void clamp_brightness(struct udev_device *device, char **value,
unsigned max_brightness) {
+int r;
+unsigned brightness, new_brightness;
+
+r = safe_atou(*value, brightness);
if (r 0) {
-log_warning(Failed to parse max_brightness \%s\: %s,
max_brightness_str, strerror(-r));
+log_warning(Failed to parse brightness \%s\: %s, *value,
strerror(-r));
return;
}
@@ -239,6 +246,7 @@ int main(int argc, char *argv[]) {
_cleanup_udev_device_unref_ struct udev_device *device = NULL;
_cleanup_free_ char *saved = NULL, *ss = NULL, *escaped_ss = NULL,
*escaped_sysname = NULL, *escaped_path_id = NULL;
const char *sysname, *path_id;
+unsigned max_brightness;
int r;
if (argc != 3) {
@@ -294,6 +302,14 @@ int main(int argc, char *argv[]) {
return EXIT_FAILURE;
}
+/* If max_brightness is 0, then there is no actual backlight
+ * device. This happens on desktops with Asus mainboards
+ * that load the eeepc-wmi module.
+ */
+max_brightness = get_max_brightness(device);
+if (max_brightness == 0)
+return EXIT_SUCCESS;
+
escaped_ss = cescape(ss);
if (!escaped_ss) {
log_oom();
@@ -348,7 +364,7 @@ int main(int argc, char *argv[]) {
return EXIT_FAILURE;
}
-clamp_brightness(device, value);
+clamp_brightness(device, value, max_brightness);
r = udev_device_set_sysattr_value(device, brightness, value);
if (r 0) {
--
1.9.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Fix permissions on new journal files
Am 25.03.2014 01:40, schrieb Lennart Poettering: This is just a kludge... Why is system.journal to be treated differently? It seems that the proper fix is to set the mode on the directory properly during installation. Precisely, packaging script are expected to properly chown and setfacl the directory on install. From the .spec file in Fedora: This completely ignores the problem Dave mentions in his earlier post: Volatile journals are owned by root:root. 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] [PATCH] README: Correct EFI requirements
systemd does not need or use CONFIG_EFI_VARS anywhere, this should be CONFIG_EFIVAR_FS instead. --- README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README b/README index ace13cf..b0bf5e8 100644 --- a/README +++ b/README @@ -80,7 +80,7 @@ REQUIREMENTS: CONFIG_SCHED_DEBUG For UEFI systems: - CONFIG_EFI_VARS + CONFIG_EFIVAR_FS CONFIG_EFI_PARTITION Note that kernel auditing is broken when used with systemd's -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd 211
Am 12.03.2014 01:30, schrieb Lennart Poettering: Heya! Many bugfixes, and a number of new features: http://www.freedesktop.org/software/systemd/systemd-211.tar.xz Nice. CHANGES WITH 211: [...] * systemd-gpt-auto-generator is now able to discover /srv and root partitions in addition to /home and swap partitions. It also supports LUKS-encrypted partitions now. With this in place automatic discovery of partitions to mount following the Discoverable Partitions Specification (http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec) is now a lot more complete. This allows booting without /etc/fstab and without root= on the kernel command line on appropriately prepared systems. I had no time to look into this yet, but there's something wrong. I don't have GPT partitions on this machine (so the generator shouldn't do anyting), but I get an error during boot: [4.634733] evey systemd-gpt-auto-generator[226]: Out of memory. I do have plenty of free memory available, so there is probably an incorrect log_oom() somewhere in there. 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] [ANNOUNCE] systemd 211
Am 12.03.2014 16:34, schrieb Lennart Poettering: This should then run an break where the incorrect OOM happens. Then, get me a backtracke please: bt full Sending it inline, should be readable enough. It seems like udev_device_get_parent() fails in enumerate_partitions(). The device it fails on is 254:0 (/dev/dm-0), which is a device mapper device and has no parent (no idea why it even checks that). (gdb) bt full #0 log_oom_internal (file=0x40e480 src/gpt-auto-generator/gpt-auto-generator.c, line=398, func=0x40eee0 __func__.8740 enumerate_partitions) at src/shared/log.c:737 No locals. #1 0x0040497a in enumerate_partitions (devnum=65024) at src/gpt-auto-generator/gpt-auto-generator.c:398 e = 0x0 d = 0x417010 b = 0x0 udev = 0x417250 home = 0x0 srv = 0x0 first = 0x1000 item = 0x2 parent = 0x0 node = 0x0 pttype = 0x40a0a8 split+159 I\211\006H\001\330H\211E devtype = 0x41ed error: Cannot access memory at address 0x41ed home_nr = -1 srv_nr = -1 pl = 0x1000 r = 0 k = 0 pn = 0 __func__ = enumerate_partitions #2 0x004059fb in add_mounts () at src/gpt-auto-generator/gpt-auto-generator.c:729 devno = 65024 r = 1 __func__ = add_mounts #3 0x00405b4c in main (argc=4, argv=0x7fffe4b8) at src/gpt-auto-generator/gpt-auto-generator.c:768 k = 0 r = 0 __func__ = main 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] [PATCH] units: Do not unescape instance name in systemd-backlight@.service
The instance name is never escaped in the udev rule, but unescaped in the unit. This results in the following error message on Asus boards: Failed to get backlight or LED device 'backlight:eeepc/wmi': No such file or directory --- units/systemd-backli...@.service.in | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/units/systemd-backli...@.service.in b/units/systemd-backli...@.service.in index 5caa5d5..e945d87 100644 --- a/units/systemd-backli...@.service.in +++ b/units/systemd-backli...@.service.in @@ -6,7 +6,7 @@ # (at your option) any later version. [Unit] -Description=Load/Save Screen Backlight Brightness of %I +Description=Load/Save Screen Backlight Brightness of %i Documentation=man:systemd-backlight@.service(8) DefaultDependencies=no RequiresMountsFor=/var/lib/systemd/backlight @@ -17,5 +17,5 @@ Before=sysinit.target shutdown.target [Service] Type=oneshot RemainAfterExit=yes -ExecStart=@rootlibexecdir@/systemd-backlight load %I -ExecStop=@rootlibexecdir@/systemd-backlight save %I +ExecStart=@rootlibexecdir@/systemd-backlight load %i +ExecStop=@rootlibexecdir@/systemd-backlight save %i -- 1.9.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] core: add default extra dependency option
Am 28.02.2014 10:02, schrieb WaLyong Cho: systemd is already provide a special unit. If the type of unit is service then that is 'basic.target'. Additionally default extra dependency can be listed in system.conf and then other service unit will have After= dependency implicitly. In config directory /etc/systemd/default-extra-dependencies, if a service unit is listed ignore-units or exist symlink in ignore-units.d then the service units can be launched before extra dependencies. I am confused about the motivation here. This change adds several extra configuration primitives - one in system.conf, a new directory, and a mechanism to opt out of the new configuration. This is quite a lot for something that I find marginally useful at best. I think this functionality even enables an administrator to unwillingly break his system - setting this option likely has many unforeseen consequences, depending on the installed services. Furthermore, the configuration only affects .service units, but that is not reflected in any of the option names, suggesting it is a configuration that would affect *any* unit. Why should this functionality exist for .service units, but not for others? What's the reason you want to add new dependencies to all units at the same time? 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] analyze/run: Use bus_open_transport_systemd instead of bus_open_transport.
Am 21.02.2014 11:55, schrieb Thomas Bächler: Both systemd-analyze and systemd-run only access org.freedesktop.systemd1 on the bus. This patch allows using systemd-run --user and systemd-analyze --user even if the user session's bus is not properly integrated with the systemd user unit. Ping. Any comments on this? 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] analyze/run: Use bus_open_transport_systemd instead of bus_open_transport.
Am 24.02.2014 17:10, schrieb Lennart Poettering: On Fri, 21.02.14 11:55, Thomas Bächler (tho...@archlinux.org) wrote: Both systemd-analyze and systemd-run only access org.freedesktop.systemd1 on the bus. This patch allows using systemd-run --user and systemd-analyzeefau --user even if the user session's bus is not properly integrated with the systemd user unit. I am not convinced this is really desirable. The private socket exists solely to make sure we cann communicate during really early boot and during late shutdown with it, but neither systemd-analyze nor systemd-run really appears to be tools that need to support that? I am not saying it is desirable (it is not). I am saying it may be necessary. Short reason: We don't live in a perfect world yet. Long reason (sorry, this is going to be really long): Let me first emphasize that I don't have PID1 in mind. If this was in any way necessary for the --system case, something would be quite broken. My problem is only with the user instance. I first noticed that running 'systemd-run --user ...' resulted in the message Failed start transient unit: Process org.freedesktop.systemd1 exited with status 1 (a bit cryptic, but I understand what it's about.) My thoughts about this: 1) (non-kdbus case) Until kdbus is complete and the default, it is rather hard to integrate the user instance with the actual user session. While we can now (with 209) import the environment into systemd, there is no way to import it into dbus-daemon. Thus, if we install a unit that sets up dbus-daemon for the user instance and import DBUS_SESSION_BUS_ADDRESS=/run/... into the desktop session, all dbus-activated services will lack necessary environment variables like DISPLAY, KDE_FULL_SESSION and similar. I have used such a setup for a while, and KDE loses functionality. Even if we could work around this problem, this setup does not work out of the box, since systemd does not ship the required dbus units. Therefore, systemd-run --user and systemd-analyze --user can never work out of the box. 2) (kdbus case) In the (hopefully) not so far future, we'll have kdbus. This will improve the situation considerably: a) importing the environment into systemd will work and actually help result in the proper environment being provided to the bus-activated services. b) a generator will convert all dbus service files into the required systemd units. All that remains is that one sets up the desktop to actually export the environment to systemd and to use the dbus socket provided by bus-proxyd. This isn't perfect yet (the desktop should integrate with systemd properly on its own), but it's usable. Still, this requires manual user intervention by someone knowledgable and thus, systemd-run --user and systemd-analyze --user still won't work out of the box. 3) (why not?) It doesn't hurt anyone. Both tools only ever connect to org.freedesktop.systemd1, never to anything else. Whether we connect via the normal bus or the private one does not matter, the functionality provided will be the same. Thus we fix a few rather common problems (which will disappear over time, but not tomorrow) with a simple change that does not harm, but is only undesirable for philosophical reasons. 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] Setting cgroup properties on systemd --user
I am trying to set properties on scopes or services of my user instance, for example: systemctl --user set-property --runtime foobar.scope CPUShares=150 This command returns without error, but in the journal, I get messages like this: systemd[5054]: Failed to set cpu.shares on /user.slice/user-1000.slice/user@1000.service: No such file or directory followed by a similar message for each unit that is active under my user instance. What's going on here? Is this supposed to work? 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] [arch-dev-public] systemd 209 in [testing]
Am 20.02.2014 17:33, schrieb Dave Reisner: Hi all, I'm working on packaging the systemd 209 release, and I expect to have pkgrel=1 into [testing] in a few hours, barring any unforseen problems. It's a huge release (nearly 2000 commits since 208), and I don't anticipate that this will make it into [core]. This version works fine on my desktop, but fails on my laptop. The initramfs works fine. While booting up the system, systemd hangs and this appears in the journal: systemd[1]: Assertion '(x-type == SOURCE_MONOTONIC y-type == SOURCE_MONOTONIC) || (x-type == SOURCE_REALTIME y-type == SOURCE_REALTIME)' failed at src/libsystemd/sd-event/sd-event.c:264, function latest_time_prioq_compare(). Aborting. systemd[1]: Caught ABRT, dumped core as pid 317. 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] [PATCH] sd-event: Fix systemd crash when using timer units.
There was a copy-paste error introduced in commit
c2ba3ad6604ef2e189d7e0a36d696e84d3ab
which causes the following error when using timer units:
Assertion '(x-type == SOURCE_MONOTONIC y-type == SOURCE_MONOTONIC) ||
(x-type == SOURCE_REALTIME y-type == SOURCE_REALTIME)'
failed at src/libsystemd/sd-event/sd-event.c:264, function
latest_time_prioq_compare(). Aborting.
---
I did cannot test this at the moment, but the problem looks very obvious to me.
src/libsystemd/sd-event/sd-event.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/libsystemd/sd-event/sd-event.c
b/src/libsystemd/sd-event/sd-event.c
index 25dfd17..1f039bc 100644
--- a/src/libsystemd/sd-event/sd-event.c
+++ b/src/libsystemd/sd-event/sd-event.c
@@ -771,7 +771,7 @@ _public_ int sd_event_add_realtime(sd_event *e,
sd_event_time_handler_t callback,
void *userdata) {
-return event_add_time_internal(e, ret, SOURCE_REALTIME,
e-realtime_fd, CLOCK_REALTIME, e-realtime_earliest, e-monotonic_latest,
usec, accuracy, callback, userdata);
+return event_add_time_internal(e, ret, SOURCE_REALTIME,
e-realtime_fd, CLOCK_REALTIME, e-realtime_earliest, e-realtime_latest,
usec, accuracy, callback, userdata);
}
static int event_update_signal_fd(sd_event *e) {
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] analyze/run: Use bus_open_transport_systemd instead of bus_open_transport.
Both systemd-analyze and systemd-run only access org.freedesktop.systemd1
on the bus. This patch allows using systemd-run --user and systemd-analyze
--user even if the user session's bus is not properly integrated with the
systemd user unit.
---
src/analyze/analyze.c | 2 +-
src/run/run.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/analyze/analyze.c b/src/analyze/analyze.c
index 3d2d08f..37d8beb 100644
--- a/src/analyze/analyze.c
+++ b/src/analyze/analyze.c
@@ -1274,7 +1274,7 @@ int main(int argc, char *argv[]) {
if (r = 0)
goto finish;
-r = bus_open_transport(arg_transport, arg_host, arg_user, bus);
+r = bus_open_transport_systemd(arg_transport, arg_host, arg_user,
bus);
if (r 0) {
log_error(Failed to create bus connection: %s, strerror(-r));
goto finish;
diff --git a/src/run/run.c b/src/run/run.c
index 885d881..134cb66 100644
--- a/src/run/run.c
+++ b/src/run/run.c
@@ -490,7 +490,7 @@ int main(int argc, char* argv[]) {
arg_description = description;
}
-r = bus_open_transport(arg_transport, arg_host, arg_user, bus);
+r = bus_open_transport_systemd(arg_transport, arg_host, arg_user,
bus);
if (r 0) {
log_error(Failed to create bus connection: %s, strerror(-r));
goto finish;
--
1.9.0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] install: Do not enable systemd-networkd by default
Am 21.02.2014 17:03, schrieb Tom Gundersen: What about Zbigniews idea of using something like: ConditionDirectoryNotEmpty=/etc/systemd/network/ Would that work? We'd have to look in all the possible folders, and there may (and due to 99-deafult.link, always will) be files there, so we don't really have a reasonable test. When we start shipping some default .network files it becomes even harder (e.g. the thing Lennart mentioned which will only apply for given interfaces that we create ourselves inside systemd-nspawn). We'll then always have config files, but they may not necessarily apply (and we can't know whether or not they ever will). Just a crazy idea, but I'm still throwing it out here, since I think this may make people happy: * Start networkd from udev whenever a network interface appears/changes/disappears. * Networkd quits after a timeout if it has nothing to do + A timer to a scheduled event (DHCP renew or similar) would stop it from quitting entirely. + A netlink message informing networkd of new interfaces or removal of interfaces would reset the timer. Honestly, why does networkd need to keep running after configuring a static address? It is only needed when the admin wants to bring the network down, or when some interfaces change (which would cause it to to be started again by udev and look at what has changed). This would also work with your nspawn use case: When a new veth appears, networkd is launched and sees the new veth. 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] Problems with systemd-coredump
Am 17.02.2014 21:27, schrieb Manuel Reimer: As soon as a bigger coredump (about 500 MB) is to be stored, the whole system slows down significantly. Seems like storing such big amounts of data takes pretty long and is a very CPU hungry process... I completely agree. Since the kernel ignores the maximum coredump size when core_pattern is used, a significant amount of time passes whenever a larger process crashes, with no benefit (since the dump never gets saved anywhere). This is extremely annoying if processes with sizes in the tens or hundreds of gigabytes crash, which sadly happened to me quite a few times recently. 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] Drop Before=paths/sockets/timers.target from DefaultDependencies.
Am 29.01.2014 03:49, schrieb Andrey Borzenkov: Zbyszek's argument for the patch, however, is that following the recommended WantedBy= behavior already applies the same Before= dependency, Where is *this* documented? Unless I misunderstand what you say. The documentation (and code) regarding the sometimes unexpected behaviour of DefaultDependencies is scattered in a few places - this cost me some time when I first learned how to systemd. From systemd.unit(5): If true, (the default), a few default dependencies will implicitly be created for the unit. The actual dependencies created depend on the unit type. Now, it is true that when you look at systemd.service(5) and friends, there is no mention of this implicit Before= dependency mentioned above. Even when you look at the code, you won't find it directly. Eventually, you'll find this bit in systemd.target(5): Unless DefaultDependencies= is set to false, target units will implicitly complement all configured dependencies of type Wants=, Requires=, RequiresOverridable= with dependencies of type After= if the units in question also have DefaultDependencies=true So, in order to understand DefaultDependencies, you need to read the related bits in systemd.unit(5), systemd.service(5), systemd.timer(5), systemd.socket(5), systemd.path(5), systemd.slice(5), systemd.swap(5) and systemd.target(5). The manpages systemd.mount(5) and systemd.automount(5) seem to lack any information about default dependencies. This is really annoying to learn - I'd suggest collecting all this information in one place - IMO, it belongs either into systemd.unit(5) or into its own manpage. 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] udev failing to assign consistent biosdevnames to my ethernet interfaces
Am 27.01.2014 05:18, schrieb David Anderson:
Jan 26 19:10:38 ironman kernel: e1000e :00:19.0 eth0: Intel(R)
PRO/1000 Network Connection
...
Jan 26 19:10:38 ironman kernel: e1000e :02:00.0 eth1: Intel(R)
PRO/1000 Network Connection
...
*Jan 26 19:10:38 ironman systemd-udevd[153]: error changing net
interface name eth1 to eno1: File exists*
Jan 26 19:10:38 ironman systemd[1]: Found device 82574L Gigabit Network
Connection.
*Jan 26 19:10:38 ironman systemd-udevd[149]: renamed network interface
eth0 to eno1*
FWIW, you can copy /usr/lib/udev/rules.d/80-net-name-slot.rules to
/etc/udev/rules.d/ and comment out line 10:
# NAME==, ENV{ID_NET_NAME_ONBOARD}!=, NAME=$env{ID_NET_NAME_ONBOARD}
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] Is masking an error?
Am 21.01.2014 09:33, schrieb Holger Schurig: on my systemd v208 + many patches from the Fedora 21 source RPM i get TWO error messages in my journal when I login as root: 09:27:58 systemd-logind[118]: Failed to start unit user@0.service: Unit user@0.service failed to load: No such file or directory. 09:27:58 systemd-logind[118]: Failed to start user service: Unit user@0.service failed to load: No such file or directory. Since logind explicitly creates a start job for user@0.service, this is an error, since the service does not exist. But it was my decision as an admin to disable user sessions, by doing ln -s /dev/null /etc/systemd/systemd/user@.service. In my case systemd runs in embedded devices and no one would use use user service files anyway - tightly controlled environment. In such a case, wouldn't it be better to disable logind entirely (or even trim down the systemd installation to not include it)? Since you are not interested in user sessions, you need no resource control for user sessions. You don't need suspend/hibernate/shutdown/reboot for users either. Nor do you need configuration of device ACLs. So, I'd mask systemd-logind.service and remove pam_systemd.so from the PAM configuration (I think it's set so that failure is ignored anyway, but removing it should still be safer). 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] systemd and cgroups
Am 13.01.2014 02:47, schrieb Kay Sievers: On Mon, Jan 13, 2014 at 8:07 AM, Greg KH gre...@linuxfoundation.org wrote: On Sun, Jan 12, 2014 at 11:48:56PM +0100, Dominique Michel wrote: I need that pc for production, so I rapidly installed another distribution without systemd. So this problem is solved for me, but that doesn't solve that to force any user to use a default configuration without any possibility of user setup, and without documentation that can allow an user to do that, is just a design fault. That sounds like a distro issue, please take this up with your distro developers, this isn't a systemd issue. http://www.freedesktop.org/wiki/Software/systemd/MyServiceCantGetRealtime/ Let me quote from that: By default systemd places all system services into their own control groups in the cpu hierarchy. That is not true anymore since systemd 207 IIRC (whenever the whole cgroup rework started, I might have the version number wrong). In fact, systemd only puts services into the own cpu control group once you explicitly set the CPUShares for a service. Instead of evening out CPU per process this will cause CPU to be evened out per service. This benefit has been lost with systemd 207, at least it is not the default behaviour anymore. 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] [PATCH] fstab-generator: Do not try to fsck non-devices
This fixes a regression introduced in 64e70e4 where the mount fails
when fstab is misconfigured with fs_passno 0 on a virtual file
system like tmpfs.
---
src/fstab-generator/fstab-generator.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 1227f08..709a1c3 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -255,9 +255,11 @@ static int add_mount(
Before=%s\n,
post);
-r = add_fsck(f, what, where, type, passno);
-if (r 0)
-return r;
+if(is_device_path(what)) {
+r = add_fsck(f, what, where, type, passno);
+if (r 0)
+return r;
+}
fprintf(f,
\n
--
1.8.5.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] fstab-generator: Do not try to fsck non-devices
Am 21.12.2013 12:49, schrieb Tom Gundersen:
-r = add_fsck(f, what, where, type, passno);
-if (r 0)
-return r;
+if(is_device_path(what)) {
+r = add_fsck(f, what, where, type, passno);
+if (r 0)
+return r;
+}
fprintf(f,
\n
Also, how does your patch deal with LABEL= and UUDI=?
This patch mirrors the old behaviour of the (now removed) FsckPassNo
code path.
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] login: Don't stop a running user manager from garbage-collecting the user.
Am 12.12.2013 15:38, schrieb Lennart Poettering:
On Wed, 11.12.13 19:56, Thomas Bächler (tho...@archlinux.org) wrote:
With the current logic, a user will never be garbage-collected, since its
manager will always be around. Change the logic such that a user is
garbage-collected when it has no sessions and linger is disabled.
---
src/login/logind-user.c | 12
1 file changed, 12 deletions(-)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 6ba8d98..42a7524 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -612,18 +612,6 @@ bool user_check_gc(User *u, bool drop_not_started) {
if (user_check_linger_file(u) 0)
return true;
-if (u-slice_job manager_job_is_active(u-manager, u-slice_job))
-return true;
-
-if (u-service_job manager_job_is_active(u-manager,
-u-service_job))
-return true;
Hmm, we probably should stay around as long as the jobs are still
active.
-
-if (u-slice manager_unit_is_active(u-manager, u-slice) != 0)
-return true;
-
-if (u-service manager_unit_is_active(u-manager, u-service) !=
0)
-return true;
-
THis part should indeed go, yo are right.
Can you check whether things work correctly for you if you only remove
the latter two parts, but leave the former two in? I'lll merge the patch then.
Okay, I tested a bit further: I added 'ExecStartPre=/usr/bin/sleep 10'
to user@.service and tested with both versions of the patch. My version
indeed causes problems, but the race condition I suspected does not
occur: the user manager is started and immediately stopped in case I log
out while the service is still starting up.
Sending v2 in a minute.
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] [PATCHv2] login: Don't stop a running user manager from garbage-collecting the user.
With the current logic, a user will never be garbage-collected, since its
manager will always be around. Change the logic such that a user is
garbage-collected when it has no sessions and linger is disabled.
---
src/login/logind-user.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 6ba8d98..441e086 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -618,12 +618,6 @@ bool user_check_gc(User *u, bool drop_not_started) {
if (u-service_job manager_job_is_active(u-manager,
u-service_job))
return true;
-if (u-slice manager_unit_is_active(u-manager, u-slice) != 0)
-return true;
-
-if (u-service manager_unit_is_active(u-manager, u-service) != 0)
-return true;
-
return false;
}
--
1.8.5.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] login: Don't stop a running user manager from garbage-collecting the user.
Am 12.12.2013 15:38, schrieb Lennart Poettering:
On Wed, 11.12.13 19:56, Thomas Bächler (tho...@archlinux.org) wrote:
With the current logic, a user will never be garbage-collected, since its
manager will always be around. Change the logic such that a user is
garbage-collected when it has no sessions and linger is disabled.
---
src/login/logind-user.c | 12
1 file changed, 12 deletions(-)
diff --git a/src/login/logind-user.c b/src/login/logind-user.c
index 6ba8d98..42a7524 100644
--- a/src/login/logind-user.c
+++ b/src/login/logind-user.c
@@ -612,18 +612,6 @@ bool user_check_gc(User *u, bool drop_not_started) {
if (user_check_linger_file(u) 0)
return true;
-if (u-slice_job manager_job_is_active(u-manager, u-slice_job))
-return true;
-
-if (u-service_job manager_job_is_active(u-manager,
-u-service_job))
-return true;
Hmm, we probably should stay around as long as the jobs are still
active.
-
-if (u-slice manager_unit_is_active(u-manager, u-slice) != 0)
-return true;
-
-if (u-service manager_unit_is_active(u-manager, u-service) !=
0)
-return true;
-
THis part should indeed go, yo are right.
Can you check whether things work correctly for you if you only remove
the latter two parts, but leave the former two in? I'lll merge the patch then.
That's rather hard to test. I'd have to terminate the session while the
service or slice job is still running and see what happens.
My guess is that omitting the first two checks will work most of the
time, but fail under rare circumstance: You terminate the last session
while the start job is still active, omit gc'ing the user and never add
it to the gc list again.
On the other hand I think that removing those lines is fine: Stopping
the user will queue a stob job for the service and the slice. The
corresponding start job may still be running at that time, but the
system manager should be capable of dealing with such issues (it's the
same issues that arises when running systemctl stop before a systemctl
start finished).
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] user@.service doesn't stop on logout
Am 10.12.2013 22:55, schrieb Thomas Bächler: # /run/systemd/users/1000 # This is private data. Do not parse. NAME=test STATE=closing RUNTIME=/run/user/1000 SERVICE=user@1000.service SLICE=user-1000.slice REALTIME=1386712031039381 MONOTONIC=14242584 SESSIONS=1 SEATS=seat0 ACTIVE_SESSIONS= ONLINE_SESSIONS= ACTIVE_SEATS= ONLINE_SEATS= I checked loginctl list-sessions, and there is no session 1. This test was done with systemd-git 171754a. I tested a bit more on another box with systemd 208. It seems that when I log out, my session is left in SESSIONS=. Whenever the same user logs in or out another session, the old session is cleaned up (but then, the current session stays around). 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] login: Don't stop a running user manager from garbage-collecting the user.
Am 11.12.2013 19:56, schrieb Thomas Bächler: With the current logic, a user will never be garbage-collected, since its manager will always be around. Change the logic such that a user is garbage-collected when it has no sessions and linger is disabled. This seems to fix my current problem. However, if I have two sessions and close one, both the dbus properties of the user/seat as well as the /run/systemd/users/$UID file still list the closed session until another session for the user closes or opens. This seems to be a separate problem, but still a flaw in the logic somewhere. 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] udevadm settle takes too long to finish
Am 10.12.2013 18:37, schrieb Lennart Poettering: What's the distribution you are using? Using udevadm settle for lvm is a waste of boot time and isn't even guaranteed to work (ask Lennart, Kay or Greg K-H for the full speech). It's a hackish workaround for LVM's inability to activate volumes automatically. afaik on very recent fedora lvm has been fixed to now require udevadm settle anymore, one of my favourite issues with LVM is gone now... That said I have not looked into it in detail, so I don't know if this is all good now. (I sure I won't let LVM anywhere near my systems...) The rest of my email actually has some of the details on the improved mechanisms. 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] user@.service doesn't stop on logout
Am 10.12.2013 19:19, schrieb Lennart Poettering: That service should be reference counted by the sessions of the users logging in. I should hence go away if the users successfully log out from their last session. That sounds like the behaviour I would expect. Your screenshot shows the user as closing. Usually that state is only entered if there are processes still around of the user even though the user logged out (such as screen). That's at least the theory, but there might be some bug left. Do you see any session of that user still around when you run into this issue? The screenshot actually has the full output of 'loginctl user-status $user', which includes all open sessions of the user (in this case, none). I also verified with 'ps' that all processes by that user are gone, except the (sd-pam) and systemd process, of course. 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] user@.service doesn't stop on logout
Am 10.12.2013 20:07, schrieb Lennart Poettering: The screenshot actually has the full output of 'loginctl user-status $user', which includes all open sessions of the user (in this case, none). I also verified with 'ps' that all processes by that user are gone, except the (sd-pam) and systemd process, of course. That looks like a bug then. Can you get the output of systemctl show-user for that user? Also, please provide the contents of /run/systemd/users/$UID for that user. # loginctl show-user test UID=1000 GID=1000 Name=test Timestamp=Di 2013-12-10 22:47:11 CET TimestampMonotonic=14242584 RuntimePath=/run/user/1000 Service=user@1000.service Slice=user-1000.slice State=closing IdleHint=yes IdleSinceHint=0 IdleSinceHintMonotonic=0 Linger=no # /run/systemd/users/1000 # This is private data. Do not parse. NAME=test STATE=closing RUNTIME=/run/user/1000 SERVICE=user@1000.service SLICE=user-1000.slice REALTIME=1386712031039381 MONOTONIC=14242584 SESSIONS=1 SEATS=seat0 ACTIVE_SESSIONS= ONLINE_SESSIONS= ACTIVE_SEATS= ONLINE_SEATS= I checked loginctl list-sessions, and there is no session 1. This test was done with systemd-git 171754a. 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] user@.service doesn't stop on logout
In systemd 208 and latest systemd git, every user gets a new user@.service instance when they login. However, when their last session exits, that service is not terminated. After a few weeks of uptime on one of my servers, dozens of user@.service units are running, belonging to users that logged in weeks ago and haven't been seen since. Is this really the intended behaviour? Random screenshot: https://paste.xinu.at/RZn/ 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] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
Am 20.11.2013 14:38, schrieb Tom Gundersen: Pass on the line on which a section was decleared to the parsers, so they can distinguish between multiple sections (if they chose to). Currently no parsers take advantage of this, but a follow-up patch will do that to distinguish [Address] Address=192.168.0.1/24 Label=one [Address] Address=192.168.0.2/24 Label=two from [Address] Address=192.168.0.1/24 Label=one Address=192.168.0.2/24 Label=two This is a bad idea. When we have a config file [Section] Foo=bar [Section] Foo=baz and have a corresponding .d snippet with [Section] Foo=bay what does this mean? Does it override the value of the first section, the second section or does it create a new section? 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] [RFC][PATCH] conf-parser: distinguish between multiple sections with the same name
Am 20.11.2013 15:02, schrieb Tom Gundersen: what does this mean? Does it override the value of the first section, the second section or does it create a new section? Yeah, in this case it would not make sense. However, this stuff is opt-in only, and unit files don't opt-in (currently nothing does). For the use-case I have in mind we won't allow partial overrides and probably not even drop-ins/includes. So, we'd have inconsistent config file syntax across systemd? Some section types override/extend when we write them more than once, some section types create new instances? I like the idea of assigning unique names to section instances much more. 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] Where did DefaultControllers= option go?
Am 29.10.2013 17:21, schrieb Colin Guthrie: Hi, 'Twas brillig, and Umut Tezduyar at 29/10/13 15:17 did gyre and gimble: I have noticed DefaultControllers= option is no longer in system.conf file. Has it been moved to somewhere else or are all controllers default controllers by default? See the various posts on this list and in blogs regarding the cgroups rework. In particular see the mails with the subject [HEADSUP] cgroup... See also: http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ None of this explains why systemd no longer applies certain controllers by default. Previously, systemd would attach cpu controllers to each service by default. Now, it only groups your processes in the systemd tree, but does not touch any cgroup controllers. The new default behaviour (or lack thereof) seems like a step back to me. 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] Where did DefaultControllers= option go?
Am 29.10.2013 17:52, schrieb Kay Sievers: None of this explains why systemd no longer applies certain controllers by default. Previously, systemd would attach cpu controllers to each service by default. Now, it only groups your processes in the systemd tree, but does not touch any cgroup controllers. The new default behaviour (or lack thereof) seems like a step back to me. It's a property of a unit now which cgroup controllers get attached: http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html The global mirroring across trees makes no sense in the future. The several independent trees will go away in the kernel next year, and then systemd would not know what to do with an instruction like DefaultControllers. I realized that when I set the CPUShares attribute on any unit, systemd mirrors the whole cgroup tree into the cpu,cpuacct tree. However, in the past, it was mirrored regardless of such setting. This had the benefit that CPU was equally distributed among services, not among processes. That benefit is now gone if I choose to not configure any cpu settings. 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] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
Am 01.10.2013 02:58, schrieb Lennart Poettering: Originally the intention was that root-fsck.service would run fsck for the root device, anf fsck@.service would be used for the rest. The difference is mostly one about ordering, i.e. root-fsck.service is the only one that is fine with the fs being already mounted. Now, if we have the initrd, then I figure root-fsck.service doesn't make much sense, but there's something missing I think: if we use fsck@.service for the root device, how do we then communicate to the root-fsck.service on the host that the file system has already been checked? How is that supposed to work? Harald? What is the idea here? Can we get some decision here? Right now, we don't get root fsck'ed with 'rw' on the command line, which is worse than fsck'ing twice in the 'ro' case. Colin had the great idea that we drop mask root-fsck.service in /run/systemd/system/ when we run fsck in initrd. For example, the initrd generator could add a service to the initrd that creates the symlink and a .d snippet that makes systemd-fsck@.service require it. This would work without complex changes to the systemd core and hopefully cover all cases. 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] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
Am 04.10.2013 13:52, schrieb Zbigniew Jędrzejewski-Szmek:
Colin had the great idea that we drop mask root-fsck.service in
/run/systemd/system/ when we run fsck in initrd. For example, the initrd
generator could add a service to the initrd that creates the symlink and
a .d snippet that makes systemd-fsck@.service require it. This would
work without complex changes to the systemd core and hopefully cover all
cases.
Hm, why not add ConditionKernelCommandLine=!ro instead to
systemd-root-fsck.service?
I looked into it and decided against it, since it is not the correct
test case: You can have fsck in initrd and still mount ro - then
systemd-root-fsck will still start and you will have the double-fsck again.
Actually, what you propose is the same as having systemd-root-fsck with
ConditionReadWrite=!/, which is already in place.
('rw' is the default, the lack of 'ro'
means 'rw'.)
Line 383 in src/fstab-generator/fstab-generator.c disagrees.
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 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
Am 01.10.2013 05:10, schrieb Lennart Poettering: b) is tempting. Given fsck's improved internal ordering handling, is there actually a usecase for ordering the fsck's? I can't think of any off the top of my head... I struggle coming up with one. I mean, the only I could think of is oh my, it always used to work that way, and it is documented that way, you break UNIX!, which isn't even a usecase, but just confusion. Those were exactly my thoughts. And since systemd never had a problem with breaking tradition if it was a good idea, I thought we could simply go ahead. Now, according to the fstab(5) manpage, the root fs should have passno 1 and everything else should have passno 2. We could ensure the same behaviour by having After=systemd-root-fsck.service in systemd-fsck@.service. If file system checks actually need to be manually ordered in a certain manner (which I would consider an edge case), systemd provides a much saner interface than a pass number, namely Before= and After= ordering on the fsck services using .d files. Things like that should probably just be automatically determined by the machine, and not requiring a human to invent weird passes to do the job. A boolean sounds fine to me. As Kay mentioned, /sbin/fsck is rather powerful these days. OK, sounds good to me. Anyone wants to cook up a patch that removes FsckPassNo= from the core and makes sure the fstab generator only takes the passno field in fstab as boolean to enable fsck or not? My patch 1/3 already treats passno as a boolean - if passno 0, we enable fsck, otherwise we don't. (passno 0 is treated the same as passno == 0 by the current FsckPassNo code, so I kept that.) I can cook up a patch that removes FsckPassNo= - I omitted it here since I was unsure whether people have it in unit files they wrote manually. 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] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
Am 01.10.2013 02:58, schrieb Lennart Poettering: Now, if we have the initrd, then I figure root-fsck.service doesn't make much sense, but there's something missing I think: if we use fsck@.service for the root device, how do we then communicate to the root-fsck.service on the host that the file system has already been checked? How is that supposed to work? This is how I imagine things should work: 1) initrd fsck's the device used for /sysroot. 2) initrd mounts /sysroot as rw 3) initrd fsck's and mounts /usr and friends 4) switch-root 5) the main system only fsck's and mounts whatever isn't mounted yet. This is what we now have as default in new Arch installations (including / being mounted rw in initrd). What we don't have by default yet is initrd being handled by systemd. In the systemd case, step 1) was missing and the root device was never fsck'ed, thus the patch. The beauty of this setup is that systemd implicitly does everything right, there is no need to serialize any fsck state between initrd and main system. In the setup I am aiming for as a default, neither systemd-root-fsck.service nor systemd-remount-fs.service are needed and both can go away (in fact, I always mask the latter, since that saves me a few milliseconds). The only use case I see for both using fsck in initrd and having / mounted read-only during switch-root is a read-only root file system. In that light, I don't think there is anything to fix. 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] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
Am 01.10.2013 12:15, schrieb Colin Guthrie: 'Twas brillig, and Thomas Bächler at 01/10/13 10:18 did gyre and gimble: Am 01.10.2013 02:58, schrieb Lennart Poettering: Now, if we have the initrd, then I figure root-fsck.service doesn't make much sense, but there's something missing I think: if we use fsck@.service for the root device, how do we then communicate to the root-fsck.service on the host that the file system has already been checked? How is that supposed to work? This is how I imagine things should work: 1) initrd fsck's the device used for /sysroot. 2) initrd mounts /sysroot as rw Why is it the initrd's job to do the rw mount? It should likely mount as ro pretty much always no? It's up to the booted system to remount rw if so desired (i.e. in the fstab). Why should I mount the file system ro only to mount it rw a few milliseconds later? The only reason that was ever done is that file system checks are usually impossible on rw file systems. Since we avoid those anyway with initrd setups, there is no reason left. I can pass the file system with root=, the option with rootflags= and optionally the fs type with rootfstype=. This way, I don't even need to configure my root file system in fstab (and I've started omitting it entirely from my fstabs since the line had no effect anyway). 3) initrd fsck's and mounts /usr and friends 4) switch-root 5) the main system only fsck's and mounts whatever isn't mounted yet. This is generally OK, but we have to differentiate between initrd boots and non-initrd boots too - as Lennart said, root-fsck is only really sensible if and only if no initrd is used. Yes, I think that's what we should go for: systemd-root-fsck is only for initrd-less systems. I think everyone agrees that systemd-root-fsck is not needed if you have an initrd. If that is so, I am happy. It's only meant for initrd-less boots. Perhaps, the initrd should just drop a masking symlink in /run/systemd/system for that service to ensure it's not run? I like that. Likewise the initrd could do the masking for the remount service too such that someone booting without an initrd could still get it? Maybe - I personally mask the service on all my systems (it noticably slowed down a non-SSD boot on an old machine). I don't think it should be needed on a properly configured system with initrd. Even on a non-initrd system, all it should change is the rw/ro flag, the rest can be configured properly right from the start. 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 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
Am 01.10.2013 12:30, schrieb Zbigniew Jędrzejewski-Szmek: Now, according to the fstab(5) manpage, the root fs should have passno 1 and everything else should have passno 2. We could ensure the same behaviour by having After=systemd-root-fsck.service in systemd-fsck@.service. Serializing fscks like that makes only limited sense if you're doing it from the initrd. But if the fsck is run from the ro root, then yes, I guess you want to make sure that the fs that holds the fsck binaries is OK before continuing. That's why systemd-root-fsck.service should be ordered before all systemd-fsck@.service units. This only affects the non-initrd case. In the initrd case, systemd-root-fsck should not be run anyway and the ordering I suggested has no effect. Manual ordering is a bit of a corner case, but like Jan Engelhart wrote... On an iSCSI server, export /dev/sdf1 and /dev/sdf2 as separate LUNs. The iSCSI client will import them as /dev/sda and /dev/sdb. That is a case where, if you can, you would specify FsckPassNo because the automatic detection likely stops at host boundaries. ...there might be use cases. Even if we drop support for ordering by fsck-no field in /etc/fstab, do we have a new way of configuring this through /etc/fstab? (Something like x-systemd.comment=After=systemd-fsck-var.service ?) Or is this really too much of an edge case? I don't think that the current fsck-no-related code is harmful in any way or a maintenance burden, so if it is dropped, it would be nice to cover all bases. If we are to keep the strict fs_passno as documented in fstab(5), I suggest we go with Lennart's suggestion: d) Pimp up fstab-generator to write only .d dropins that add the necessary deps between the fsck instances, but nothing else. I find the whole concept of the FsckPassNo option disturbing (including its documentation). It introduces an additional directive for something that can be solved with the existing ones, with the comment that it should only be used for certain types of services, or not at all. An option that shouldn't be used in newly written units shouldn't be used in generated ones either. 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] Patches to use -.mount without /etc/fstab
Am 01.10.2013 15:26, schrieb Karel Zak: 2. If /etc/fstab is missing, systemd must create a valid fstab (in this case /run/fstab) so that fsck runs properly. Not following on this one really... If fsck fails if it doesn't find any fstab, then this is really something to fix in util-linux I am sure. It I didn't tests it, but according to code fsck prints warning only and continue as usually. Why does it even print that warning? It's annoying and I don't see its purpose. Unless you run fsck with the -A option, it doesn't even need the fstab file. I actually got rid of /etc/fstab (for fun) and only recreated an empty one to get rid of the warning. 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] Patches to use -.mount without /etc/fstab
Am 24.09.2013 21:53, schrieb Kelly Anderson: If I'm not mistaken, the intent way back in the early stages of systemd was to eliminate /etc/fstab and use .mount files exclusively. Since it was never fully implemented I took the prerogative to make it work on my systems. I've been using the setup for quite some time and it works without problem. As Lennart said, it doesn't seem to be a goal. However, you can make a system work without just fine without fstab (I run such a system). 1. if /etc/fstab is missing, systemd must remount / based on the options in /etc/systemd/system/-.mount. Why does / need to be remounted? Simply mount / with the correct options from initrd. If you don't need initrd, a simple oneshot service with ExecStart=mount -o remount,rw / should suffice, or, as Lennart said, a reload of the -.mount unit. 2. If /etc/fstab is missing, systemd must create a valid fstab (in this case /run/fstab) so that fsck runs properly. fsck prints a warning if fstab is missing. It's annoying, so I created an empty /etc/fstab on my system. 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] Renaming network interfaces: device or resource busy
Am 30.09.2013 17:14, schrieb Colin Guthrie: Hi, Just trying to debug the problem mentioned in the subject. I'm wanting to use the new device names in stage 2 of our installer (some closing config routines write the interface name into some conf files etc), but when udev rules kick in, the device is already up and in use... is there any way to work out what is using it and preventing the rename? I would guess fuser or netstat but not quite sure what to look for. Simply running netstat only shows unix sockets, no tcp/udp ones... Any help appreciated. Any application that listens on netlink for new network interfaces may start using the interface before udev has finished processing the uevent. IMO, this needs to be fixed in the kernel and udev, so that udev can have a chance to finish its uevent processing before the interface is announced via netlink. As far as I know, no work in that direction has been done. We had such a problem when running dhcpcd without an interface argument: Depending on whether udev or dhcpcd was faster, interface renaming would succeed or fail. We are now working around this issue ([1]), but I don't particularly like that solution. [1] https://projects.archlinux.org/archiso.git/commit/?id=7d14796716939fbabb9daba6b6f5294016d63cd4 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] [PATCH] fstab-generator: When parsing the root= cmdline option, set FsckPassNo to 1
---
src/fstab-generator/fstab-generator.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 9efccb9..6cecb4e 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -449,7 +449,7 @@ static int parse_new_root_from_proc_cmdline(void) {
}
log_debug(Found entry what=%s where=/sysroot type=%s, what, type);
-r = add_mount(what, /sysroot, type, opts, 0, noauto, nofail, false,
+r = add_mount(what, /sysroot, type, opts, 1, noauto, nofail, false,
SPECIAL_INITRD_ROOT_FS_TARGET, /proc/cmdline);
return (r 0) ? r : 0;
--
1.8.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/3] Remove usage of FsckPassNo
FsckPassNo is listed as a compatibility option that shouldn't be used in new units. Keeping compatibility with fstab's old fs_passno field serves no particular purpose on a systemd system. This patch series removes all usage of FsckPassNo from all generated and shipped units: * fstab-generator now generates dependencies on systemd-fsck@.service if fs_passno is greater than zero. * gpt-auto-generator always generates a dependency in add_home instead of using FsckPassNo=2. * systemd-fsck-root.service no longer has FsckPassNo=1 This patch series does not remove the FsckPassNo option, although I think it should go away, too. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] fstab-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
---
src/fstab-generator/fstab-generator.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/src/fstab-generator/fstab-generator.c
b/src/fstab-generator/fstab-generator.c
index 6cecb4e..83aba7d 100644
--- a/src/fstab-generator/fstab-generator.c
+++ b/src/fstab-generator/fstab-generator.c
@@ -209,17 +209,26 @@ static int add_mount(
Before=%s\n,
post);
+if (passno 0) {
+_cleanup_free_ char *fsck = NULL;
+fsck = unit_name_from_path_instance(systemd-fsck, what,
.service);
+fprintf(f,
+Requires=%s\n
+After=%s\n,
+fsck,
+fsck);
+}
+
+
fprintf(f,
\n
[Mount]\n
What=%s\n
Where=%s\n
-Type=%s\n
-FsckPassNo=%i\n,
+Type=%s\n,
what,
where,
-type,
-passno);
+type);
if (!isempty(opts)
!streq(opts, defaults))
--
1.8.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] gpt-auto-generator: Generate explicit dependencies on systemd-fsck@.service instead of using FsckPassNo
---
src/gpt-auto-generator/gpt-auto-generator.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/src/gpt-auto-generator/gpt-auto-generator.c
b/src/gpt-auto-generator/gpt-auto-generator.c
index ca54925..97b4742 100644
--- a/src/gpt-auto-generator/gpt-auto-generator.c
+++ b/src/gpt-auto-generator/gpt-auto-generator.c
@@ -180,7 +180,7 @@ static int add_swap(const char *path, const char *fstype) {
}
static int add_home(const char *path, const char *fstype) {
-_cleanup_free_ char *unit = NULL, *lnk = NULL;
+_cleanup_free_ char *unit = NULL, *lnk = NULL, *fsck = NULL;
_cleanup_fclose_ FILE *f = NULL;
if (dir_is_empty(/home) = 0)
@@ -198,19 +198,21 @@ static int add_home(const char *path, const char *fstype)
{
return -errno;
}
+fsck = unit_name_from_path_instance(systemd-fsck, path, .service);
+
fprintf(f,
# Automatically generated by systemd-gpt-auto-generator\n\n
[Unit]\n
DefaultDependencies=no\n
-After= SPECIAL_LOCAL_FS_PRE_TARGET \n
+Requires=%s\n
+After= SPECIAL_LOCAL_FS_PRE_TARGET %s\n
Conflicts= SPECIAL_UMOUNT_TARGET \n
Before= SPECIAL_UMOUNT_TARGET SPECIAL_LOCAL_FS_TARGET
\n\n
[Mount]\n
What=%s\n
Where=/home\n
-Type=%s\n
-FsckPassNo=2\n,
-path, fstype);
+Type=%s\n,
+fsck, fsck, path, fstype);
fflush(f);
if (ferror(f)) {
--
1.8.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] Remove FsckPassNo from systemd-fsck-root.service
--- units/systemd-fsck-root.service.in | 1 - 1 file changed, 1 deletion(-) diff --git a/units/systemd-fsck-root.service.in b/units/systemd-fsck-root.service.in index 4388314..4162983 100644 --- a/units/systemd-fsck-root.service.in +++ b/units/systemd-fsck-root.service.in @@ -19,5 +19,4 @@ Type=oneshot RemainAfterExit=yes ExecStart=@rootlibexecdir@/systemd-fsck StandardOutput=journal+console -FsckPassNo=1 TimeoutSec=0 -- 1.8.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Inconsistencies in the systemd.mount documentation
Am 11.09.2013 17:08, schrieb Lennart Poettering: Using FsckPassNo= as a way to add that dep sucks really, because the ordering it does is stupid and fsck can do the ordering internally anyway these days... So, shouldn't systemd-fstab-generator omit that entirely, too? Instead, every mount with pass!=0 should get the correct fsck dependency. Automatically adding deps to fsck for all mounts is wrong too, since only some block-based file systems need fsck and it would suck having to carry a whitelist for thos in systemd. Fair enough. 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] [RFC] mount: improve DefaultDependencies and use in generator
Am 21.08.2013 13:53, schrieb Tom Gundersen: I'd like to move some of the default dependency logic from the fstab generator to core. This should remove some redundancy and also improve consistency between mount units and fstab entries. The first patch simply enables default dependencies in the generator, and removes some things that are then made redundant. The second patch moves the handling of device dependencies from the generator to core's default dependencies. DefaultDependencies=yes implicitly adds Before=foo.target for every target foo that wants or requires the unit. This has a negative effect on auto,x-systemd.automount mounts: Enabling DefaultDependencies will make the generated .mount unit Before=local-fs.target, which will remove the speed-up gained by delaying the mount. 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] Inconsistencies in the systemd.mount documentation
In the manpage for systemd.mount(5), the following section is included: COMPATIBILITY OPTIONS The following option is also available in the [Mount] section, but exists purely for compatibility reasons and should not be used in newly written mount files. FsckPassNo= The pass number for the file system checking service for this mount. See systemd.service(5) for more information on this setting. However, if you omit the FsckPassNo= option from a mount unit, no dependency upon the correct systemd-fsck@ instance is created. So in fact, the option has a function. I'm not sure if this is intended, but in my opinion, DefaultDependencies=yes in a .mount unit should create that dependency, not the presence of a compatibility options. Does anyone know more? 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] cryptsetup-generator: allow specifying options in /proc/cmdline
Am 19.08.2013 10:34, schrieb Harald Hoyer: Hmm, the naming luks.options is IMHO poorly chosen. options as an option name... hmm. Also crypttab can contain more encryption modes, than LUKS. If you want to reflect crypttab, why not specify something like: [rd.]crypttab=name;device;password;options So, systemd-cryptsetup-generator currently reads luks, luks.crypttab, luks.uuid and luks.key (+ the rd. variants). Now you are proposing to add a 'crypttab' option as well. This seems awfully inconsistent to me. OTOH, allowing to give more options on the command line would open the door to more encryption schemes than just LUKS (which I don't particularly care about). I just fear that syntax gets more confusing when allowing many ways to achieve the same goal. rd.luks.allow-discards=luks uuid Allow using of discards (TRIM) requests for LUKS partitions with the given UUID. Any luks- of the LUKS UUID is removed before comparing to luks uuid. The comparisons also matches, if luks uuid is only the beginning of the LUKS UUID, so you don't have to specify the full UUID. This parameter can be specified multiple times. rd.luks.allow-discards Allow using of discards (TRIM) requests on all LUKS partitions. So 1) you are not actually using systemd-cryptsetup-generator, 2) you single out this one option and don't support the rest. 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] cryptsetup-generator: allow specifying options in /proc/cmdline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 19.08.2013 11:58, schrieb Harald Hoyer: On 08/19/2013 11:21 AM, Thomas Bächler wrote: Am 19.08.2013 10:34, schrieb Harald Hoyer: Hmm, the naming luks.options is IMHO poorly chosen. options as an option name... hmm. Also crypttab can contain more encryption modes, than LUKS. If you want to reflect crypttab, why not specify something like: [rd.]crypttab=name;device;password;options So, systemd-cryptsetup-generator currently reads luks, luks.crypttab, luks.uuid and luks.key (+ the rd. variants). Now you are proposing to add a 'crypttab' option as well. This seems awfully inconsistent to me. Well, I think before adding more and more rd.luks parameters, we might want to step back and add one option, which supports all. When you phrase it that way, I must fully agree. An object oriented syntax might be: rd.luks.uuid.name=name rd.luks.uuid.options=options rd.luks.uuid.password=password This of course would have made parsing with shell functions unpractical. Now that we already have rd.luks.uuid=uuid adding parameters to uuid results in rd.luks.options=uuid=options rd.luks.name=uuid=name rd.luks.password=uuid=password Both solutions blow up the length of the kernel command line and make it really unreadable. Agreed. Your initial [rd.]crypttab=name;device;password;options proposal sounds reasonable. Is ';' a good separator for this (I think it is, just making sure I don't overlook something)? Should the [rd].luks* options be deprecated at the same time? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSEgDEAAoJEChPw0yOSxolVQgP/3hAox/FdrCKi7BMs5rsSe+r NHXnu9nOngBLRHw/DnICQ5HoMAX1HDHLUOdqeWOt4XVI0jn4RDFivzIZnSmpf6QS zi8/oltC38gBd8LyKNfklt3tF6xw5/pfrIBe6DGa6clYywUd9daIsdOXN3sh7yHK InEn3oyfPA4Eno0p5d6hKn4g03KJlsgm313V2Fxr97y6enu2yJjeemlmdOoyMeNf FcUqphobaJWiGYqePEyLJtKoaNq91h6CnLNVQJ8dIIleZeGmCwwpv8xT4A8WyjXQ cRIrDvo7bHMBIHPdFV+UPZ+Crn7OTnJBDTKFJzttnEY8AYI4vpc7kcuTD8yVHxln K/c/NGEuYjO50e26Sso12kFicTXexdXxdELijMZ2MzHpTd6hFeHwa9R5/ts3ZasS AQJLqtVOpJMT2EMnk48JLgOpkgGJiXTs8wC08DMuYP1KjOWa43/EFy1KCHoA6N8G L47meHpIw0EzRgMXtXGBcmFKDbrGZeuX/gxnhAAw17ZO1X0K5sY1Y2FWanc21kqq Zn3PK1OHGlLwiqhblo6hrv0LNRNh1oYJtbQel1DbS60v8Pq3qidsb0IVB8vUuZ8M Zgnjk7N1GgY2DiYkBVjzpvD7og74hK8pf4vvRC/WkmbOsG2VqW1grejzAoF8T1I0 P/f/Zne4C5KGYvBdHhV2 =gtpu -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: allow specifying options in /proc/cmdline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Am 19.08.2013 13:25, schrieb Thomas Bächler: Am 19.08.2013 11:58, schrieb Harald Hoyer: On 08/19/2013 11:21 AM, Thomas Bächler wrote: Am 19.08.2013 10:34, schrieb Harald Hoyer: Hmm, the naming luks.options is IMHO poorly chosen. options as an option name... hmm. Also crypttab can contain more encryption modes, than LUKS. Another remark: The option luks.crypttab already affects other schemes than luks - it is a generic option that can disable reading of crypttab altogether. Having an option 'crypttab=' even seems more confusing now. What do you think we should do? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSElZIAAoJEChPw0yOSxolzbMP/1DnmmhYtHAyq8koFZbWpsk6 JVWnZnhQrU7Y/QZJyvapWt/dnQY9MOgXzc6s49HE09A40qyLs2WYHM1dXKlx8B5N N9Q5V07xmD0WKbTNztmoIBLouUPv+NzfvF+2HoN+XwVcAuCmU9BV/HLG6V90aI+y 5Eh0pDTO1jFyL7Rhcf81MJus462POJSciLXZOTnXHDDm/42gg3McfT6x+xlcQh1T +aYsLao9Tg9iYXxi0/+LL8Z6KPELAeeaspIZllXa3tYSL6q233cPrqdkxtvCwZFc HMOY65usWNppjrzW9EM554dcoDsQ6iBII2ORPAQiMJnSJgaVUTWgmw5AJKNLAeRS X6SKf9STQtDSPpEpyyHNn4pl2wMW+olJ1VgU1s+NNgjw9ryRt04e/iD3cNHbCecI CnXFjDUbXM5aGef4OIk7hzK2CraOcFXagHzgUTF0HCxQLeNrnLwIsqtErnCAfLOL 7rNdwn2rbZfW278dT9A1LVDjNXYk9FwMaHBbQpIsuQSuhn9geU2LKOqBd9LWYzff KaPLg4O81H1Lb+JNduQKrRSN6ZCTkfSvjI/1/2Ro7hXK2hEbvX5doU94pfRJuPrn Yz50SEVNiGpWxmdoY+ADmJ1RSAHJ8gQgtRGki7AF2aE1Cj07f5uES/H/PCWbdvw6 OC1onClOzAw6OELeDHgt =a2Ge -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] arch bootstrapping
Am 19.08.2013 21:05, schrieb Zbigniew Jędrzejewski-Szmek: Now to do the --populate archlinux, you need to have an archlinux keyring in /usr/share/pacman/keyrings/. If you look at the `archlinux-keyring` package in arch, that should give you some ideas. So, I've created a simple archlinux-keyring package for Fedora. I have one question: is there an official license for the archlinux-keyring sources? It is just a collection of publicly accessible information, but it would be much easier if the license (Public Domain?) would be publicly specified. It seems there is no license in the archlinux-keyring repository, and the Arch Linux package says GPL, which may not even make sense for this stuff (the package doesn't include the scripts, only the collection of PGP keys). I CC'd Pierre - can we clarify the license on this? 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] arch bootstrapping
Am 17.08.2013 17:27, schrieb Zbigniew Jędrzejewski-Szmek: Hi, I was trying to get the arch installation example in systemd-spawn to work on Fedora. My intent is to package pacman and pacstrap for Fedora, to make it easy to play with distributions. Fedora already has alien and dpkg/apt-get, so adding pacman seems kind of nice. The packaging process is going well, but the intallation is not as easy, because of gpg key issues. It's possible that I made some error, I tried both to add SigLevel=TrustAll in (host's) /etc/pacman.conf, and to to import gpg keys with 'pacman-key --populate archlinux'. The second solution didn't seem to work, and both have downsides: - disabling checking is bad because of security issues, and it also seems to mess up the trust database inside the container, - importing the trust database in the host (assuming that I'd get it to work), would require either also packaging the keys for Fedora, or telling the user to trust keys blindly and download them from the internet... pacstrap assumes that you have a working key database on the host (which is the case for our live CD and bootstrap tarball). To work around that, you need to 1) set up a keyring in /instroot/etc/pacman.d/gnupg 2) call pacstrap with the -G option This will set up a keyring in /instroot without the need for one in the host. For 1), simply run pacman-key --gpgdir /instroot/etc/pacman.d/gnupg --init pacman-key --gpgdir /instroot/etc/pacman.d/gnupg --populate archlinux For that, you must have the keyring available in /usr/share/pacman/keyrings/. Get the keyring from https://projects.archlinux.org/archlinux-keyring.git/ - you need the archlinux.gpg, archlinux-revoked and archlinux-trusted files. The only thing that is critical for security is the archlinux-trusted file - the fingerprints in there must match the ones from https://www.archlinux.org/master-keys/. The rest of the files are just there for convenience. 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] [PATCH] cryptsetup: Retry indefinitely if tries=0 option has been set.
When running from initrd, entering a wrong passphrase usually means that
you cannot boot. Therefore, we allow trying indefinitely.
---
This is useful together with Tom's latest patch. On my system, I use
rd.luks.options=allow-discards,tries=0
so unless booting succeeds, I will be prompted for a passphrase
indefinitely.
man/crypttab.xml| 4 +++-
src/cryptsetup/cryptsetup.c | 7 +++
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/man/crypttab.xml b/man/crypttab.xml
index 15c86d3..90d8ce9 100644
--- a/man/crypttab.xml
+++ b/man/crypttab.xml
@@ -330,7 +330,9 @@
termvarnametries=/varname/term
listitemparaSpecifies the maximum number of
-times the user is queried for a
password./para/listitem
+times the user is queried for a password.
+The default is 3. If set to 0, the user is
+queried for a password
indefinitely./para/listitem
/varlistentry
varlistentry
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index ba0fdbc..22b5eea 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -41,7 +41,7 @@ static unsigned opt_key_size = 0;
static unsigned opt_keyfile_size = 0;
static unsigned opt_keyfile_offset = 0;
static char *opt_hash = NULL;
-static unsigned opt_tries = 0;
+static unsigned opt_tries = 3;
static bool opt_readonly = false;
static bool opt_verify = false;
static bool opt_discards = false;
@@ -576,7 +576,6 @@ int main(int argc, char *argv[]) {
else
until = 0;
-opt_tries = opt_tries 0 ? opt_tries : 3;
opt_key_size = (opt_key_size 0 ? opt_key_size : 256);
if (key_file) {
@@ -588,7 +587,7 @@ int main(int argc, char *argv[]) {
log_warning(Key file %s is world-readable.
This is not a good idea!, key_file);
}
-for (tries = 0; tries opt_tries; tries++) {
+for (tries = 0; opt_tries == 0 || tries opt_tries; tries++) {
_cleanup_strv_free_ char **passwords = NULL;
if (!key_file) {
@@ -616,7 +615,7 @@ int main(int argc, char *argv[]) {
log_warning(Invalid passphrase.);
}
-if (tries = opt_tries) {
+if (opt_tries != 0 tries = opt_tries) {
log_error(Too many attempts; giving up.);
r = EXIT_FAILURE;
goto finish;
--
1.8.3.4
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/3] install: don't allow to enable/disable templates
Am 08.08.2013 15:19, schrieb Michal Sekletar: Calling enable on template units doesn't make sense since it is possible to enable instances directly and users are not forced to use Alias= trickery anymore. Actually, it would make sense to do this instead: http://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg09244.html 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] Drop ConditionCapability=CAP_MKNOD from *udev* units
Am 25.07.2013 10:18, schrieb Frederic Crozat: Le mercredi 24 juillet 2013 à 18:41 -0300, Gerardo Exequiel Pozzi a écrit : Signed-off-by: Gerardo Exequiel Pozzi vmlinuz...@yahoo.com.ar --- units/systemd-udev-settle.service.in | 1 - units/systemd-udev-trigger.service.in | 1 - units/systemd-udevd-control.socket| 1 - units/systemd-udevd-kernel.socket | 1 - 4 files changed, 4 deletions(-) What do you expect to fix with this patch ? This will just break distro containers (nspawn / lxc) since it will cause udev to be started there. If these units should not be started in containers, this should be reflected with ConditionVirtualization. ConditionCapability is not related to containers at all. 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] journalctl: add --iso-dates for long timestamps
Am 17.07.2013 17:58, schrieb Zbigniew Jędrzejewski-Szmek:
So, now we have -o short, -o short-monotonic, and --iso-dates.
I'm sure we'll add a relative timestamp mode like the excellent one in
dmesg --human output in recent util-linux. So I'd say that it makes
sense to deprecate short-monotonic and add a new switch --timestamps,
--timestamps=monotonic → old short-monotonic
--timestamps=iso-date → what you're proposing
--timestamps=...
This makes the whole thing easier to grok, imo. Journalctl already has
1½ page listing of options...
The output options of journalctl have bugged me for some time now. There
are many options, but the usefulness of many of those is questionable.
At the same time, the choice of output modes lacks flexibility - this is
certainly not the last time that someone will come up with a new way to
format output and submit a patch for it to journalctl.
In my opinion, journalctl (and the journal API) should get an output
option that accepts a printf-like format string. With such a format
string, we would finally get all the flexibility with a simple and
well-understood syntax.
In addition to the standard journal fields, format strings could
reference non-standard fields using a syntax similar to udev's
'%env{FOOBAR}'. We could be able limit the length of the output similar
to what is done in printf. We could have (to get back on topic)
different format modifiers for different date formats (ISO,
human-readable, epoch, ...).
Just my 2 cents.
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] systemd-shutdown static linking
Am 11.06.2013 10:34, schrieb Colin Guthrie: Without reading the code etc., I'm running systemd with that commit (v204) and I don't get any conflicts for my -.mount unit... So it seems that code is not run for me for whatever reason. After a very quick glance at the code, it could just be that the unit already exists as it's created earlier and thus this bit of the code for -.mount is simply not run? I think this code is only called when there is no -.mount unit, which results from a missing entry for / in fstab. It is entirely possible that Ross didn't add / to his fstab by accident or on purpose. 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] disabling shared mount propagation
Am 23.04.2013 21:51, schrieb Albert Strasheim: is causing some headaches with some services of ours that use unshare to get a new mount namespace and make some private mounts which we don't want propagated. Proper solution: Directly after the unshare, run either mount(none, /, none, MS_REC | MS_SLAVE, NULL) (mount --make-rslave /) or mount(none, /, none, MS_REC | MS_PRIVATE, NULL) (mount --make-rprivate /) in the context of your service. In most cases, leaving the global mount namespace as shared and setting your service's namespace to slave gives the most desirable behaviour. 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] Socket is dying, how to automatically restart it?
Am 18.04.2013 16:44, schrieb Lennart Poettering: On Thu, 18.04.13 16:38, Thomas Bächler (tho...@archlinux.org) wrote: Am 18.04.2013 16:04, schrieb Lennart Poettering: That said, screen should probably set up a new PAM session of its own and detach from the original one. That sounds like a good idea - unfortunately, screen does not seem to have PAM session support at all, and I couldn't find the obvious place to add this inside screen (I didn't invest much time in it either). This would allow screen sessions to be tracked by logind instead of having many State=closing sessions floating around. BTW, this probably needs sokme changes in systemd too. Since right now, if you open a PAM session from a process that is already part of a PAM session logind will just return the same data as the first time. So to make this work properly, we'd to define a way how certain PAM services can explicitly ask to get a new session assigned. So that's what happens with 'su' and 'sudo' - I always wondered. The obvious solution would be to add an option to pam_systemd which would force opening a new session despite being part of an active session. That setting could then be set in /etc/pam.d/screen. 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] Socket is dying, how to automatically restart it?
Am 18.04.2013 16:04, schrieb Lennart Poettering: That said, screen should probably set up a new PAM session of its own and detach from the original one. That sounds like a good idea - unfortunately, screen does not seem to have PAM session support at all, and I couldn't find the obvious place to add this inside screen (I didn't invest much time in it either). This would allow screen sessions to be tracked by logind instead of having many State=closing sessions floating around. Has anyone worked on this? 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 v3] tools: add static-nodes tool
Am 16.04.2013 15:12, schrieb Tom Gundersen:
+static void write_human(FILE *out, char module[], char devname[], char type,
unsigned int maj, unsigned int min)
[...]
+static void write_tmpfile(FILE *out, char devname[], char type, unsigned int
maj, unsigned int min)
[...]
+static int do_static_nodes(int argc, char *argv[])
+{
+struct utsname kernel;
+char modules[PATH_MAX];
+FILE *in = NULL, *out = stdout;
+bool human_readable = 1;
This code emphasizes that there is actually only one format available
and needs to be changed again when another one is added. Why not
void (*write_output)((FILE *, char[], char[], char, unsigned int,
unsigned int) = write_human;
? Then ...
+case 'f':
+if (!streq(optarg, tmpfiles)) {
+fprintf(stderr, Unknown format: '%s'.\n,
argv[1]);
+help();
+ret = EXIT_FAILURE;
+goto finish;
+}
+human_readable = 0;
+break;
case 'f':
if (streq(optarg, tmpfiles)) {
write_output = write_tmpfiles;
}
else {
fprintf(stderr, Unknown format: '%s'.\n, argv[1]);
[...]
}
break;
And in the end:
+if (human_readable)
+write_human(out, module, devname, type, maj, min);
+else
+write_tmpfile(out, devname, type, maj, min);
write_output(out, module, devname, type, maj, min);
Maybe even add an array with output name and function pointer pairs, so
that we could get a list of available formats using --format=?. For
consistency, --format=human should also work. Just seems nicer to me, in
case someone actually plans to extend this later.
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] cryptsetup-generator: Add JobTimeoutSec=0 for all known crypt devices
Am 03.04.2013 19:02, schrieb Lennart Poettering: On Wed, 03.04.13 17:02, Harald Hoyer (har...@redhat.com) wrote: Well, this explanation is too short. You need to clarify that this only has an effect on devices listed in fstab with their device mapper path (i.e. rather than LABEL= or UUID=, which is by far more common). For the generic case there is no way around setting x-systemd.device-timeout=0 in fstab, because we wouldn't know that the fs with that label or uuid is hidden behind a certain encrypted device before we have decrypted it. This is not true. This also affects LVM on top of the cryptsetup devices, where none of the /dev/mapper devices is and can be in /etc/fstab. Well, LVM does not care about proper dependencies. They still are so naive to assume they are run at a point in time where all devices are probed. That is untrue. LVM can be enabled entirely from udev if it is so configured. Whether or not .device units exist is pretty much ignored by LVM. That's true, LVM cannot hook into systemd, 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] nfs dependency in mysqld.service (best option)?
Am 19.03.2013 23:13, schrieb Gary Artim: Thinking I should modify to add a After= for nfs.target, any one think this is the wrong approach or alternate options, I'd do something like: Sufficiently recent systemd versions have the 'RequiresMountsFor=' option to deal with this, see 'man systemd.unit' for details. In short, RequiresMountsFor=/path/to/your/databases adds the correct mount units as dependencies, so mysqld.service not not started before the /path/to/your/databases is accessible. 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] [PATCHv2 2/2] udev: Fix order of execution of the md rules
Am 11.02.2013 01:31, schrieb NeilBrown: On Sat, 9 Feb 2013 21:49:47 +0100 Thomas Bächler tho...@archlinux.org wrote: Right now, the rules that run blkid on raid arrays are executed after the assembly rules. This means incremental assembly will always fail when raid arrays are again physical components of raid arrays. I'm not at all against splitting the udev rules into two files, but your reasoning seems a bit odd and I want to be sure that I understand. We run mdadm -I based on the contents of ID_FS_TYPE, and ID_FS_TYPE is set by blkid, which is called after the mdadm -I rules. So why do they work at all? If a new device, say /dev/md0 is added by udev, before the patch, the rules would do the following: 1) go to md_inc_skip, because ID_FS_TYPE is unset, thus skip incremental assembly. 2) call blkid and set ID_FS_TYPE If ID_FS_TYPE is again linux_raid_member, then it would have been necessary to call mdadm -I for /dev/md0 here. This is probably what happens here: https://bugs.archlinux.org/task/32558 The short version is: The reporter joins three disks as a RAID0 (md2), then combines md2 with another hard drive as RAID1. With my changes, incremental assembly should work in this case, because ID_FS_TYPE is set before incremental assembly tests for it. Presumably something else is calling blkid ? That seems to be persistent-storage.rules which calls blkid on some devices, but not on others. That seems sub-optimal. It is probably reasonable that it skips sr* (which is explicit) but for us it is unfortunate that it skips md*. Yes, udev's standard rules skip md*, and I do not know why. I cannot see a good reason for persistent-storage-rules to skip 'md' devices, so I would suggest that the best way to fix the problem is the fix that rules file. Then we could remove the blkid call from the md rules which is nice as it removes duplication. CC'ing Kay here. Kay, is there a good reason to skip md* in 60-persistent-storage.rules? We could still split the md rules files, but I would rather do that because it was a good and clean thing to do, not do that because it helps work around a short-coming in some other rules files. The good reason is that the rules fulfill two different tasks: 1) Apply incremental assembly to RAID members. 2) Set properties on RAID arrays. Two tasks means two separate files, so you can easily disable or override only one of them. 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] Booting with USB flash disk installed results in wrong disk numbering
Am 05.02.2013 14:30, schrieb Baurzhan Muftakhidinov: What concerns me here is that there is no consistency on less powerful machine. There is no consistency. Period. Not on more powerful and not on less powerful machines. There never was, there never will be. In some form, this problem has existed for at least a decade, yet people still consider it a new problem because they've just now seen it for the first time. Udev has provided persistent and predictable naming schemes for hard drives for a long time (almost a decade probably). You MUST use those. 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] logind: multiseat without framebuffer graphic cards
Am 23.11.2012 18:18, schrieb Lennart Poettering: On Thu, 22.11.12 13:27, Thomas Bächler (tho...@archlinux.org) wrote: For me, the major problem is that the selection of seat master devices is hard-coded in logind (it selects devices of type graphics from udev, [1]). Step 1 would be to move that to a udev rule: Add a seatmaster tag to all graphics devices and have logind select those (this would actually remove three LOC in logind.c, and change one line). Now, an admin could give this tag to any device. This fix is very easy, non-invasive and would make logind's multi-seat support much more flexible (it also allows an admin to do very stupid things, but I don't see any reason to prevent that). seat-master sounds like a good name for this. I'd be happy to merge a patch that changes logind so that it watches for devices tagged with this, and spawns an X server the moment such a device appears. If nobody beats me to it, I'll try to create a patch for this in the next few days. The second step is to make multi-seat-x support custom configurations: If an X server is to be spawned on on a seat named seatN and /etc/X11/xorg.conf_seatN exists, then that configuration file is used and multi-seat-x doesn't generate one. (Over time, maybe multi-seat-x can be extended to support more setups automatically, but that is a very low priority for me, as figuring out the correct configuration with the proprietary nvidia driver is not straight-forward.) Can't this be done in X instead? IIRC X already has some matching thing in the configuration file format. Maybe this could be extended to allow matching by seat name? Then, people could just drop per-seat configuration as normal snippets into /etc/X11/xorg.conf.d/ and add a match line to them and that would be it? Fine with me. 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] logind: multiseat without framebuffer graphic cards
Am 21.11.2012 20:23, schrieb Lennart Poettering: Ahum, we wrote this with modern in-kernel drivers in mind, really. I understand that people want to run this stuff with the closed-source binary drivers, but due to the closed-source-ness this is really not that high on my TODO list and is not as easy to implement as it sounds. I have been looking into this topic, but lacked the time to finish the thought. For me, the major problem is that the selection of seat master devices is hard-coded in logind (it selects devices of type graphics from udev, [1]). Step 1 would be to move that to a udev rule: Add a seatmaster tag to all graphics devices and have logind select those (this would actually remove three LOC in logind.c, and change one line). Now, an admin could give this tag to any device. This fix is very easy, non-invasive and would make logind's multi-seat support much more flexible (it also allows an admin to do very stupid things, but I don't see any reason to prevent that). The second step is to make multi-seat-x support custom configurations: If an X server is to be spawned on on a seat named seatN and /etc/X11/xorg.conf_seatN exists, then that configuration file is used and multi-seat-x doesn't generate one. (Over time, maybe multi-seat-x can be extended to support more setups automatically, but that is a very low priority for me, as figuring out the correct configuration with the proprietary nvidia driver is not straight-forward.) This wouldn't work with dynamically appearing and disappearing seats, and it wouldn't be fully automatic, but that isn't my use case anyway: I have computers with two NVidia PCIe cards, and thus always have exactly two seats. I simply launch two X servers manually with the correct configuration from KDM. This setup works perfectly right now, except that logind doesn't recognize them as separate seats (there is no 'graphics' device present, so I cannot even create a second seat). The first change I outlined above would solve almost all my problems (I'd still have to cheat KDM into passing the correct XDG_SEAT, as it doesn't fully support logind yet - but I can do that without any help from systemd/logind). [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/login/logind.c#n453 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] logind: multiseat without framebuffer graphic cards
Am 21.11.2012 20:23, schrieb Lennart Poettering: I think there are other ways thinkable, where we don't have to add explicit nvidia-compatibility switches. For example, instead of explicitly watching for fb devices to show up before we consider a seat to be around, we could instead look for devices that are tagged with a special tag (tag as in udev's TAG= construct) -- we'd then tag all fb devices out-of-the-box this way, and people who want to use the nvidia binary driver can attach that tag to some kernel device the nvidia driver exposes, but I wouldn't have to care about that, and systemd upstream wouldn't need to know what people do locally. Oh, I replied before I completely read your email, so what I wrote earlier essentially says the same thing that you just said. I was meaning to send a patch that does exactly this for a while, but never got around to do it. This is exactly what I need for my custom nvidia setups to integrate into logind. I would be very happy to see this change in logind. 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] [RFC/PATCH] journal over the network
Am 19.11.2012 01:21, schrieb Zbigniew Jędrzejewski-Szmek: They are parsed and stored into a journal file. The journal file is /var/log/journal/external-*.journal by default, but this can be overridden by commandline options (--output). What about /var/log/$MACHINE_ID/, isn't it the right place for these? 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] cgroup use case for preventing a system lock up if say a browser exhausts memory
Am 13.11.2012 07:53, schrieb Kai Hendry: I'm interested in a general systemd framework example of a system process resource limited. Do you have one you can point me to? http://0pointer.de/blog/projects/resources.html 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] [PATCH] man/logind.conf.xml: Add missing 'suspend' value for Handle*Key options.
--- man/logind.conf.xml | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/man/logind.conf.xml b/man/logind.conf.xml index 3d83d2c..3e744da 100644 --- a/man/logind.conf.xml +++ b/man/logind.conf.xml @@ -211,7 +211,8 @@ literalpoweroff/literal, literalreboot/literal, literalhalt/literal, -literalkexec/literal and +literalkexec/literal, +literalsuspend/literal and literalhibernate/literal. If literalignore/literal logind will never handle these keys. Otherwise the -- 1.8.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] core/swap.c: Do not add Before=swap.target to swap units.
Am 16.10.2012 02:22, schrieb Lennart Poettering: On Sat, 06.10.12 01:11, Thomas Bächler (tho...@archlinux.org) wrote: The fstab generator adds Before=swap.target by default, and when creating a custom .swap unit, you can also add Before=swap.target to the unit. However, it is impossible to not have this ordering dependency right now. Virtually all existing setups likely use the fstab generator, so this change is unlikely to break anything. Thanks! Seems for .mount units we don't generate target deps either in the core code either, hence we should make the handling of swap unit and mount units more similar. Commited! (It feels so good to commit a patch that just deletes code! ;-)) Thank you, this speeds up my boot process for another few nanoseconds or so :) I'd like to add this for completeness: Once you add the swap unit to swap.target.wants, and have DefaultDependencies=yes, you also get Before=swap.target implicitly. I realized this very late, as it is only stated in the systemd.target manpage, but not in the description of DefaultDependencies in systemd.unit. 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 1/2] core: Refuse to run a user instance when the system hasn't been booted with systemd.
Am 07.10.2012 06:56, schrieb Kok, Auke-jan H: All my patch does is match systemd's behaviour to systemctl's behaviour. It is about being consistent. It is about not claiming that things work which actually don't work. now you're saying that systemd actually works (to a certain point, sure), but systemctl is broken? Now I'm really confused... For systemctl, I could definitely find out why it wouldn't work. I couldn't test systemd as there was no convenient way to start services due to a lack of systemctl. There was something wrong inside systemd as well, witnessed by its inability to exit with 'kill -15' or Ctrl+C. I gave up at this point, because the most basic functionality I was used to was non-functional. signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
