[systemd-devel] [PATCH] label: rearrange mandatory access control(MAC) apis
move selinux label APIs to selinux-label.ch. And each security label
apis have mac_{selinux/smack}_ prefix.
---
src/core/main.c | 4 +-
src/core/namespace.c | 4 +-
src/core/selinux-setup.c | 4 +-
src/core/socket.c | 24 +--
src/hostname/hostnamed.c | 2 +-
src/locale/localed.c | 2 +-
src/login/logind-dbus.c | 2 +-
src/shared/dev-setup.c| 4 +-
src/shared/fileio-label.c | 12 +-
src/shared/label.c| 445 +-
src/shared/label.h| 26 +--
src/shared/mkdir-label.c | 26 +++
src/shared/mkdir.h| 2 +-
src/shared/selinux-util.c | 365 +-
src/shared/selinux-util.h | 14 ++
src/shared/smack-util.c | 53 -
src/shared/smack-util.h | 10 +-
src/shared/socket-label.c | 6 +-
src/sysusers/sysusers.c | 2 +-
src/test/test-udev.c | 4 +-
src/timedate/timedated.c | 2 +-
src/tmpfiles/tmpfiles.c | 32 +--
src/udev/udev-node.c | 14 +-
src/udev/udevadm.c| 4 +-
src/udev/udevd.c | 4 +-
src/update-done/update-done.c | 6 +-
26 files changed, 526 insertions(+), 547 deletions(-)
diff --git a/src/core/main.c b/src/core/main.c
index 95ab40f..9870a0c 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1307,7 +1307,7 @@ int main(int argc, char *argv[]) {
dual_timestamp_get(security_finish_timestamp);
}
-if (label_init(NULL) 0)
+if (mac_selinux_init(NULL) 0)
goto finish;
if (!skip_setup) {
@@ -1829,7 +1829,7 @@ finish:
free(arg_start_timeout_reboot_arg);
arg_start_timeout_reboot_arg = NULL;
-label_finish();
+mac_selinux_finish();
if (reexecute) {
const char **args;
diff --git a/src/core/namespace.c b/src/core/namespace.c
index fe95377..d17f41d 100644
--- a/src/core/namespace.c
+++ b/src/core/namespace.c
@@ -224,9 +224,9 @@ static int mount_dev(BindMount *m) {
goto fail;
}
-label_context_set(d, st.st_mode);
+mac_selinux_context_set(d, st.st_mode);
r = mknod(dn, st.st_mode, st.st_rdev);
-label_context_clear();
+mac_selinux_context_clear();
if (r 0) {
r = -errno;
diff --git a/src/core/selinux-setup.c b/src/core/selinux-setup.c
index b419a27..8be97fc 100644
--- a/src/core/selinux-setup.c
+++ b/src/core/selinux-setup.c
@@ -87,7 +87,7 @@ int selinux_setup(bool *loaded_policy) {
retest_selinux();
/* Transition to the new context */
-r = label_get_create_label_from_exe(SYSTEMD_BINARY_PATH,
label);
+r = mac_selinux_get_create_label_from_exe(SYSTEMD_BINARY_PATH,
label);
if (r 0 || label == NULL) {
log_open();
log_error(Failed to compute init label, ignoring.);
@@ -98,7 +98,7 @@ int selinux_setup(bool *loaded_policy) {
if (r 0)
log_error(Failed to transition into init
label '%s', ignoring., label);
-label_free(label);
+mac_selinux_free(label);
}
after_load = now(CLOCK_MONOTONIC);
diff --git a/src/core/socket.c b/src/core/socket.c
index 7ca8edb..d518421 100644
--- a/src/core/socket.c
+++ b/src/core/socket.c
@@ -919,12 +919,12 @@ static void socket_apply_socket_options(Socket *s, int
fd) {
}
if (s-smack_ip_in)
-if (smack_label_ip_in_fd(fd, s-smack_ip_in) 0)
-log_error_unit(UNIT(s)-id, smack_label_ip_in_fd:
%m);
+if (mac_smack_ip_in_fd(fd, s-smack_ip_in) 0)
+log_error_unit(UNIT(s)-id, mac_smack_ip_in_fd: %m);
if (s-smack_ip_out)
-if (smack_label_ip_out_fd(fd, s-smack_ip_out) 0)
-log_error_unit(UNIT(s)-id, smack_label_ip_out_fd:
%m);
+if (mac_smack_ip_out_fd(fd, s-smack_ip_out) 0)
+log_error_unit(UNIT(s)-id, mac_smack_ip_out_fd: %m);
}
static void socket_apply_fifo_options(Socket *s, int fd) {
@@ -937,8 +937,8 @@ static void socket_apply_fifo_options(Socket *s, int fd) {
F_SETPIPE_SZ: %m);
if (s-smack)
-if (smack_label_fd(fd, s-smack) 0)
-log_error_unit(UNIT(s)-id, smack_label_fd: %m);
+if (mac_smack_fd(fd, s-smack) 0)
+log_error_unit(UNIT(s)-id, mac_smack_fd: %m);
}
static int fifo_address_create(
@@ -956,7 +956,7 @@ static int fifo_address_create(
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.
On Wed, Aug 27, 2014 at 10:18 AM, Thomas Bächler tho...@archlinux.org wrote: +[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. Semantic of Requires is simply wrong for device - you cannot start device, you can only passively wait for it. Requisite is more appropriate to express cannot start until device is available. But I think, BindsTo is established usage for devices and is quite clear here. +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? I suppose it is leftover from the first version which was intended to support non-initrd case as well. ___ 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.
On Wednesday 27 August 2014 at 08:18:38, Thomas Bächler wrote: 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. This is just because systemd-fsck@.service does the same. Seems like it's the established usage, as Andrei says. +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? 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. (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...) 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. Just a leftover, indeed. These services do not exist in initramfs. They probably should be removed in a separate commit. +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? Thanks for review! -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Is it possible to override dependencies (without resorting to editing files in /lib)
Apologies if this isn't the appropriate mailing list to raise this question. Is there any way to override dependencies without resorting to editing files in /lib? For example, with a stock EL7.0 machine, getty.target is wanted by multi-user.target through configuration in /lib/systemd. I'd like to remove that dependency because I want getty.target to be be wanted by another target (which will be the default target and itself wants multi-user.target). Whilst there is a way to mask a unit by linking to /dev/null in /etc, there doesn't appear to be a similar way to mask a wants dependency. Thanks! Alastair Scobie -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ___ 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] [BUG] time-sync.target reached prematurely
On 26.08.2014 22:28, Lennart Poettering wrote: On Tue, 26.08.14 22:11, Lukasz Stelmach (stl...@poczta.fm) wrote: Greetings. According to systemd.special(7) all services where correct time is essential should be ordered after time-sync.target. Implicitly this means that if systemd-timesyncd is enabled services ordered after the target should also get a usable network connection because the daemon uses the network (not a GPS receiver like ntpd could do) to synchronise the clock. However, this isn't actually the case as systemd-timesyncd reports READY=1 [1] before even checking if network is online *and* querying servers. The target is reached *before* time is synced. How would you suggest to fix this? Well, I guess similar to the network.target story it isn't really clear what time-sync.target is supposed to mean... I mean, I am pretty sure we should never delay the boot by default for external conditions, such as network connectivity. hence, by default waiting for a network interface before we finish boot, and even waiting for a way to connect to an NTP server is not OK. However, timesyncd actually does something before sending READY=1: it will bump the clock to at least the time it was when the system was shutdown the last time. The idea here is that RTC-less systems at least get strictly monotonic time, even if not a correct one. Generally the logic is that we should try our best to provide as correct a time as we can, and that includes making time appear monotonic at least if we cannot do that. But at the same time waiting for the network is something that is not OK... I mean, most of the time the RTC should be good enough and NTP should just adjust the clock minimally, to fix the error the RTC might introduce... Yes that is a point. However, the current description the man page provides is a bit less accurate than the above. Then, the delay you describe does not seem as bad to me as you say. Suppose we've got two services: aiccu, systemd-logind. Their dependencies look (very) roughly like this: multi-user.target / \ aiccu.service- systemd-logind.service | \ | time-sync.target \___basic.target | | sysinit.target | / systemd-timesyncd.service This means that waiting for systemd-timesyncd to contact NTP server indeed delays reaching multi-user.target but it does not affect systemd-logind (actually it does, because systemd-timesyncd is wanted by sysinit.target but if it was a part of multi-user.target then it is not a problem (time-sync-wait.service?)) or any other services that do not depend on time-sync.target. If a service really needs correct time then I assume its authors and users are aware of the fact it won't start that instantly upon boot. You are right saying RTC provides acceptable accuracy in most cases and NTP is ther to correct slight errors. There are systems (distributed filesystems?) that need sub(micro?)second accuracy provided by PTP. Other systems may use GPS receivers which make network connectivity unnecessary. Mobiles may use GSM network to get time (I wonder if entering PIN is required). All in all, IMHO, time-sync.target should be reached after synchronising the system clock which doesn't have to mean delaying services that make the system appear to boot fast. It appears to be easier to provide a single target that modify many applications to check for STA_UNSYNC in a loop. Kind regards, -- Było mi bardzo miło. Twoje oczy lubią mnie Łukasz i to mnie zgubi (c)SNL REKLAMA: http://ars-fabrica.eu/ 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 0/3] resume: implement support for resuming from hibernation
Hi Ivan, Great job! I was wondering if a ./configure switch makes sense to disable it. Embedded devices won't be using it. Thanks On Sat, Aug 23, 2014 at 2:47 PM, Ivan Shapovalov intelfx...@gmail.com wrote: This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. It adds: - a 'systemd-resume' tool which takes path to a device node and writes its major:minor to /sys/power/state; - a corresponding 'systemd-resume@.service' templated unit; - a 'systemd-resume-generator' generator which parses the kernel command line and instantiates the unit as necessary. This functionality already exists in-kernel, but only for /dev/sdXY-style pathes. Implementing it in userspace allows to use arbitrary udev-created symlinks, e. g. persistent block device pathes (/dev/disk/by-foo/bar). Userspace parsing of resume= kernel command line parameter has been traditionally done in initramfs via shell scripts (for Arch Linux, this is resume mkinitcpio hook), so I feel that this feature has its place within systemd. Due to the nature of hibernation, the resume unit must be activated before any modifications to filesystems take place. This can happen 1) in initramfs before mounting anything, and 2) without initramfs before remounting rootfs read-write (provided that it is mounted RO initially). So, first patch orders all non-root fsck after local-fs-pre.target, which in turn allows to order the resume unit before those fsck instances. Second and third patches add the tool, the unit and the generator. There are some issues with this implementation: - legacy usr.mount is not automatically ordered after local-fs-pre.target, so systemd-resume@.service has to be manually ordered before it; - systemd-udevd.service, which is needed for creating persistent block device symlinks, is transitively ordered after systemd-remount-fs.service via at least systemd-udev-hwdb-update.service and systemd-sysusers.service. Hence, if these units are present (at least initramfs-less case), an ordering cycle happens and resume is impossible. So, I would like someone to comment on these. This is my first patch to this project, so feel free to flak me for missing something obvious :) Thanks for reviewing! Ivan Shapovalov (3): units: order systemd-fsck@.service after local-fs-pre.target. resume: add a tool to write a device node's major:minor to /sys/power/resume. resume-generator: add a generator for instantiating the resume unit. Makefile-man.am | 9 Makefile.am | 28 -- man/kernel-command-line.xml | 13 - man/systemd-resume-generator.xml| 91 + man/systemd-res...@.service.xml | 81 + src/resume-generator/Makefile | 1 + src/resume-generator/resume-generator.c | 89 src/resume/Makefile | 1 + src/resume/resume.c | 82 + units/systemd-f...@.service.in | 2 +- units/systemd-res...@.service.in| 23 + 11 files changed, 414 insertions(+), 6 deletions(-) create mode 100644 man/systemd-resume-generator.xml create mode 100644 man/systemd-res...@.service.xml create mode 12 src/resume-generator/Makefile create mode 100644 src/resume-generator/resume-generator.c create mode 12 src/resume/Makefile create mode 100644 src/resume/resume.c create mode 100644 units/systemd-res...@.service.in -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] udev: do NOT re-label smack
On 08/27/2014 04:54 AM, Lennart Poettering wrote: On Tue, 26.08.14 21:52, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 21.08.14 12:58, WaLyong Cho (walyong@samsung.com) wrote: If selinux is disabled and smack is only enabled, smack label is relable-ed by label_fix. To avoid, make only be labeled for selinux. --- src/udev/udev-node.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/src/udev/udev-node.c b/src/udev/udev-node.c index 6a9788b..00ade2c 100644 --- a/src/udev/udev-node.c +++ b/src/udev/udev-node.c @@ -314,8 +314,8 @@ static int node_permissions_apply(struct udev_device *dev, bool apply, } /* set the defaults */ -if (!selinux) -label_fix(devnode, true, false); +if (!selinux use_selinux()) +mac_selinux_fix(devnode, true, false); Shouldn't mac_selinux_fix() simply become a NOP returning ENOTSUP if selinux is disabled? Then, we can just invoke it here always, with no ill effects... Or actually, it shouldn't even return ENOTSUP, but simply 0... that's at least how the rest of the selinux code currently appears to work if selinux is off... Yes, right. And I just focused on SMACK only enabled case. In that case, the path is re-labeled again by label_fix what include also mac_smack_relabel_in_dev. Therefore the path was labeled twice. The first was labeled correctly by mac_smack_path and the second was labeled by mac_smack_relabel_in_dev. So all of /dev nodes were labeled * or _. So I made do only for selinux on there. Is there any points should be modified? if (!smack) mac_smack_path(devnode, NULL); } Lennart Lennart WaLyong ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-networkd DHCP renew
Hi! Is there a way to force a DHCPv4 release/renew with systemd-networkd? - Mads ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [Feature request] Retentiontime per unit configuration
Hallo During a task of migration of multiple servers to a systemd-based distribution I was wondering if there would be a way of setting the retentiontime of journald per unit. In some cases e.g. there are limits for special program e.g. webserver where it is not allowed to keep the logs as long as the syslog. So it would be nice to have such a feature to avoid as much as possible plain-logfiles. Kind regards, K. E. Schwerdt. smime.p7s Description: S/MIME cryptographic signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Preventing automatic seat assignments
On Tue, 2014-08-26 at 14:00 +0200, Lennart Poettering wrote: On Tue, 26.08.14 12:17, Tanu Kaskinen (tanu.kaski...@linux.intel.com) wrote: Hi, If I want to designate some sound card to be shared between seats, then I suppose that sound card shouldn't be assigned to any seats. However, currently /usr/lib/udev/rules.d/71-seat.rules unconditionally tags all sound cards with the seat tag. How should this be solved? What's the rationale here actually? PA doesn't really support sharing sound cards between multiple seats. I mean, If this is something generally useful we can see if we can support that in the default rules, but I am not seeing it? The use case is a car audio system. There are multiple seats, and each seat can have dedicated audio hardware (e.g. headphones), but there's also the speaker system that is shared by all seats. It's true that PA needs modifications too to support this. We haven't yet decided how to implement this, but probably we will run PA in system mode for the shared devices only, and user instances for the per-seat hardware. The user instances will use the tunnel module to connect to the hardware that is managed by the system instance. -- Tanu ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation
On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote: On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx...@gmail.com) wrote: This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. What about swap files with the resume_offset= parameter? Are they still being used? I don't know if somebody uses that, but for now it's missing functionality. After a cursory search, I could not find a mechanism to initiate a resume with offset from userspace. In Arch, it was never implemented even if possible. -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Socket based activation/deactivation
On Wed, Aug 27, 2014 at 3:24 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Tue, Aug 26, 2014 at 08:49:29PM -0400, Gary Mort wrote: Socket based activation for systemd is a really cool feature for my dev system. Prior to using socket based activation, on my dev system I would have 2 choices: 1) Automatically start mysql, apache, php fastcgi, memcached, mongodb and a dozen other services just in case I happen to be working with them on this particular bootup. 2) Manually start them when neededusually /after/ trying to test something and discovering the service isn't running. With socket based activation, I can start up dozens of servers on different sockets and they won't bog my system down - they only truely activate if they are actually used. However, there is still a missing item to this feature[or it's not missing and I am simply unaware of it] - there is no way to do the reverse. IE if apache is running on my server there is no way to configure things so if there are no active socket connections for 30 minutes, have it automatically shutdown and pass the socket control back. This has to be implemented in the service itself. After the service has been started systemd does not monitor the socket and simply does not know when the service can be safely stopped. In addition to the socket passed by systemd the service might have opened additional channels of communication itself, or might be doing some processing that systemd knows nothing about..., so only the service knows when it has idle and how long it has been idle. The service can close the socket and shut down. This is race free, because if a connection comes on the socket in the meantime, it will be queued by the kernel, and then when the service has shut down, systemd will start it again. Various systemd services like systemd-hostnamed do this kind of thing already. I really think this can be achieved with notify socket and the advantage would be having a system wide stop on idle value. Note: I always mixup StopWhenUnneeded=. The name makes me believe that Umut A lot of server admins don't like the idea of socket activation because it means that when they boot a server, they won't know if there is some blocker for a server to run[corrupted database files for example] until it is actually used. Of course they can configure the services to start uncondtionally by adding them to an appropriate target, so this is a really poor argument. ... So I'm curious if this feature is somewhere in socket activation I'm not aware of[it might simply be needing to write the proper systemd configuration files] or if it is something that would need to be added? It needs to be added in the daemon. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: add configure option to set name of controlled NTP service
On Tue, Aug 26, 2014 at 09:08:47AM -0700, Marcel Holtmann wrote: ConnMan is a single daemon solution doing NTP, DHCP and DNS all in one place. Any sort of callouts are costing time. And that is time that has a visible user impact. There is nothing that justifies to have a bit more nanosecond accuracy of synchronized time than making the user wait for extra milliseconds to get their network connection and time. You need the first clock update to happen milliseconds after the network is up? Seriously? I agree that's not possible with chronyd or ntpd even if they were listening to networkd, but I don't think it's a requirement on any desktop system. You might realize that a theme shows up here. If you are building a server, then by all means install ntpd or Chrony and configure it. You are the admin, you know what you are doing. If you do not know what are doing or do not care, then keep it simple. I'm not convinced. I think uninformed users should be using the best tool for the typical use case they have at hand. Trading falseticker detection, stable clock control with intermittent connections, ability to drift through when network is congested, ability to deal with broken clocks (as in some virtual machines) and monotonic time just for a super fast update seems like a bad choice to me. I'm sure timesyncd will be significantly improved over time, but currently I'd not describe it as more than appropriate for most installations. -- Miroslav Lichvar ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] systemctl: fix broken list-unit-files with --root
Lennart Poettering píše v Út 26. 08. 2014 v 20:26 +0200:
On Tue, 26.08.14 13:36, Lukas Nykryn (lnyk...@redhat.com) wrote:
Looks good! Please commit!
---
src/shared/install.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/src/shared/install.c b/src/shared/install.c
index 4b09a69..3ef995a 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -2072,6 +2072,7 @@ int unit_file_get_list(
for (;;) {
_cleanup_(unit_file_list_free_onep) UnitFileList
*f = NULL;
struct dirent *de;
+_cleanup_free_ char *path = NULL;
errno = 0;
de = readdir(d);
@@ -2121,7 +2122,11 @@ int unit_file_get_list(
goto found;
}
-r = unit_file_can_install(paths, root_dir,
f-path, true);
+path = path_make_absolute(de-d_name, *i);
+if (!path)
+return -ENOMEM;
+
+r = unit_file_can_install(paths, root_dir, path,
true);
if (r == -EINVAL || /* Invalid setting? */
r == -EBADMSG || /* Invalid format? */
r == -ENOENT /* Included file not found?
*/)
Lennart
Thanks for checking! Applied.
Lukas
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-networkd DHCP renew
On Wed, Aug 27, 2014 at 10:17 AM, Mads m...@ab3.no wrote: Is there a way to force a DHCPv4 release/renew with systemd-networkd? We don't currently allow dynamic interaction with networkd, but you can force renew the release by either restarting networkd or unplugging/replugging the cable (or switching your wifi off/on if that's what you are using). -t ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [BUG] time-sync.target reached prematurely
On Tue, Aug 26, 2014 at 10:28:54PM +0200, Lennart Poettering wrote: On Tue, 26.08.14 22:11, Lukasz Stelmach (stl...@poczta.fm) wrote: Greetings. According to systemd.special(7) all services where correct time is essential should be ordered after time-sync.target. Implicitly this means that if systemd-timesyncd is enabled services ordered after the target should also get a usable network connection because the daemon uses the network (not a GPS receiver like ntpd could do) to synchronise the clock. However, this isn't actually the case as systemd-timesyncd reports READY=1 [1] before even checking if network is online *and* querying servers. The target is reached *before* time is synced. How would you suggest to fix this? Well, I guess similar to the network.target story it isn't really clear what time-sync.target is supposed to mean... IIRC it was originally added for the ntpdate, ntp-wait and chrony-wait services. There were two meanings merged into one target. One was that the clock was set from NTP (ntpdate) and the other was that the synchronization of the clock has reached a stable state a no more jumps in the time are expected to happen (ntp-wait, chrony-wait). timesyncd setting it before NTP query doesn't fit well into that. I mean, I am pretty sure we should never delay the boot by default for external conditions, such as network connectivity. hence, by default waiting for a network interface before we finish boot, and even waiting for a way to connect to an NTP server is not OK. What services with dependency on the target do we use by default? Do they really need it? -- Miroslav Lichvar ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Is it possible to override dependencies (without resorting to editing files in /lib)
On Wed, Aug 27, 2014 at 07:51:17AM +0100, Alastair Scobie wrote: Apologies if this isn't the appropriate mailing list to raise this question. Is there any way to override dependencies without resorting to editing files in /lib? For example, with a stock EL7.0 machine, getty.target is wanted by multi-user.target through configuration in /lib/systemd. I'd like to remove that dependency because I want getty.target to be be wanted by another target (which will be the default target and itself wants multi-user.target). Whilst there is a way to mask a unit by linking to /dev/null in /etc, there doesn't appear to be a similar way to mask a wants dependency. Hi, no, there's no way to mask a specific dependency in this case. getty.target is statically enabled by a link shipped by systemd itself, and is not configurable. But units often belong to multiple targets. If you describe what effect you're trying to achieve, we might be able to describe a different way. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Socket based activation/deactivation
On Wed, Aug 27, 2014 at 11:18:11AM +0200, Umut Tezduyar Lindskog wrote: On Wed, Aug 27, 2014 at 3:24 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Tue, Aug 26, 2014 at 08:49:29PM -0400, Gary Mort wrote: Socket based activation for systemd is a really cool feature for my dev system. Prior to using socket based activation, on my dev system I would have 2 choices: 1) Automatically start mysql, apache, php fastcgi, memcached, mongodb and a dozen other services just in case I happen to be working with them on this particular bootup. 2) Manually start them when neededusually /after/ trying to test something and discovering the service isn't running. With socket based activation, I can start up dozens of servers on different sockets and they won't bog my system down - they only truely activate if they are actually used. However, there is still a missing item to this feature[or it's not missing and I am simply unaware of it] - there is no way to do the reverse. IE if apache is running on my server there is no way to configure things so if there are no active socket connections for 30 minutes, have it automatically shutdown and pass the socket control back. This has to be implemented in the service itself. After the service has been started systemd does not monitor the socket and simply does not know when the service can be safely stopped. In addition to the socket passed by systemd the service might have opened additional channels of communication itself, or might be doing some processing that systemd knows nothing about..., so only the service knows when it has idle and how long it has been idle. The service can close the socket and shut down. This is race free, because if a connection comes on the socket in the meantime, it will be queued by the kernel, and then when the service has shut down, systemd will start it again. Various systemd services like systemd-hostnamed do this kind of thing already. I really think this can be achieved with notify socket and the advantage would be having a system wide stop on idle value. You mean that the daemons would notify systemd about activity and it would keep track when to stop them? I guess possible, but I think it would be still racy, unless the notification protol was synchronous or it was possible for the service to deny the stop request sent by systemd. All in all, I don't think the complexity is worth it, since it is very simple for an event-loop based the service to do on its own. Zbyszek Note: I always mixup StopWhenUnneeded=. The name makes me believe that Umut ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] systemd-tmpfiles: Fix IGNORE_DIRECTORY_PATH age handling
If one has a config like:
d /tmp 1777 root root -
X /tmp/important_mount
All files below /tmp/important_mount will be deleted as the
/tmp/important_mount item will spuriously inherit a max age of 0
from /tmp.
/tmp has a max age of 0 but age_set is (of course) false.
Fix this by checking -age_set in the IGNORE_DIRECTORY_PATH logic.
Signed-off-by: Richard Weinberger rich...@nod.at
---
src/tmpfiles/tmpfiles.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 79fd0b7..c8d4abb 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1572,7 +1572,7 @@ static int read_config_file(const char *fn, bool
ignore_enoent) {
candidate_item = j;
}
-if (candidate_item) {
+if (candidate_item candidate_item-age_set) {
i-age = candidate_item-age;
i-age_set = true;
}
--
2.0.1
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] sd-journal: properly convert object-size on big endian
On Wed, Aug 27, 2014 at 06:58:17PM +1200, Chris Tillman wrote: Ummm, luser here, how would I know if it was BE mode? That would stand for big-endian? I reckon so, as I wouldn't know how to change it. /proc/cpuinfo didn't mention it. Yeah, big-endian. With PowerPC it is more complicated since it can be switched... I'll try building journalctl with the patch; I think for Debian I probably have to actually build systemd? In this case it is enough to do './configure make journalctl' and use journalctl without installation (./journalctl ...). On Wed, Aug 27, 2014 at 10:16:43PM +1200, Chris Tillman wrote: OK, I tried building it with the patch. I saw it go past the journal folder, so I think the patch compiled OK. But it stopped with an error at src/core/socket.c:32:0 /usr/include/powerpc-linux-gnu/sys/xattr.h:32:3: error: expected identifier before numeric constant XATTR_CREATE = 1, /* set value, fail if att already exists. */ ^ Hm, that doesn't look good. Which version are you compiling? We changed to use sys/xattr.h fairly recently, but everything is expected to work now. If you're compiling from git, than this seems to be a bug to be resolved. You could try to compile an older version of systemd, before v213-1-gd2edfae0f9, which started using sys/xattr.h. The journalctl code hasn't changed much since v208, and since you only need journalctl, it doesn't really matter much which version you compile. You could try v208-stable, from git://git.freedesktop.org/git/systemd/systemd-stable.git --branch v208-stable Then apply the patch(es) on top, and ./autogen.sh c make journalctl should be enough. The comma looks out of place, but it's in the middle of defining an enum (this is the first element). However there is a #define immediately following both the first and second elements, looks a little fishy. I tried moving those two #defines to after the enum definition (still inside the #ifndef) and rebuilding,but that didn't fix it. I still got the same error on rebuild. This header isn't even in your package is it? But I don't know how to get around it. XATTR_CREATE is probably #defined to something. Oh, I also got some warnings: in .configure unrecognized options: --disable-maintainer-mode Makefile.am:35: user target .PRECIOUS defined here ... /usr/share/automake-1.14/am/configure.am overrides Automake target '.PRECIOUS' defined here This is a known automake bug, unlikely to be fixed. src/shared/hashmap.c:188:15 unused variable auxv src/journal/sd-journal.c:2604:25: in function sd_journal_enumerate_unique warning: format '%11u' expects argument of type 'long long unsigned int' but argument 8 has type 'size_t' ... that one is in the log_debug statement you added, Zbigniew. Thanks, I fixed this here. You might get a garbled print statement, but shouldn't matter otherwise. Headed to bed now, perhaps I can try again in the morning if you all have any ideas ... Thanks for testing. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Thoughts about /etc/crypttab keyscript options
I've just been pointed to this discussion from #debian-systemd, where I dropped in to suggest that Debian packaging of systemd should probably abort installation if incompatible config like this is detected (I ended up with a non-booting test server, no harm done). I thought I'd help elaborate on a couple of use-cases. On Fri, Aug 15, 2014 at 01:30:32PM +0200, Lennart Poettering wrote: (snipped) I fear I don#t have an easy suggestion. What kind of device do you actually want to make work here? some smartcard or so? That's the vision, yes. At the moment, my keyscript unlocks a small LUKS partition on the disk and takes the key for the root fs from there. That's just a placeholder for a future more complicated setup. Not following. You place a key for a LUKS partition on another LUKS partition? What's the benefit of that? Inception? ;-) It's actually part of a two-factor-authentification for the poor. The part to know is the key to the LUKS parition, the part to have is an USB key. There are different motives for encrypted disks. For servers, you want to make the disks in your RAID opaque to anyone who picks them up as a result of theft, loss, re-use, disposal, etc. In this scenario, in-built TPM on the motherboard can keep the key secret much better than any filesystem device while still avoiding the need to manually babysit boot-up with passphrase questions - particularly handy if you have dozens of disks in the rack... Because luks-tpm doesn't allow combination with passphrases (last I checked?), this isn't good enough for laptops where you're likely to lose the whole machine (TPM and all). In order to make the disk opaque to whoever posses the laptop, we need to separate the key from the machine. Passphrases are standard but easily snooped, and perhaps inconvenient. This is where physical tokens get interesting - and diverse; there's a plethora of options out there. USB tokens (ePass, YubiKey) are easy, some have PIN pads (to mitigate lost tokens), Bluetooth tokens, SIM card applets... My favourite would be contactless smartcards, in some companies the employee ID cards are already some ISO-14443 thing for building access and Kerberos/Windows auth. They're usually capable of running a custom applet, so all the user has to do is swipe at their NFC or card-reader enabled workstation/laptop which sends some challenge text (done from the keyfile script, perhaps taken from TPM) to the SC which then hashes it with an internal secret, the result of which is used as the luks key. I've even seen some code floating around on github where each invocation of the keyfile script actually deletes the last used luks key and creates a new one, at every boot! This appeared to be an attempt at strengthening the use of a plain old usb storage device (each boot would re-write the keyfile with the next key) in lieu of a real token. Regards -- Paul ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/8] timesyncd: check if stratum is valid
---
src/timesync/timesyncd-manager.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/timesync/timesyncd-manager.c b/src/timesync/timesyncd-manager.c
index d80c72f..60f39c6 100644
--- a/src/timesync/timesyncd-manager.c
+++ b/src/timesync/timesyncd-manager.c
@@ -574,7 +574,8 @@ static int manager_receive_response(sd_event_source
*source, int fd, uint32_t re
return manager_connect(m);
}
-if (NTP_FIELD_LEAP(ntpmsg.field) == NTP_LEAP_NOTINSYNC) {
+if (NTP_FIELD_LEAP(ntpmsg.field) == NTP_LEAP_NOTINSYNC ||
+ntpmsg.stratum == 0 || ntpmsg.stratum = 16) {
log_debug(Server is not synchronized. Disconnecting.);
return manager_connect(m);
}
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 7/8] timesyncd: don't reset polling interval when reselecting server
---
src/timesync/timesyncd-manager.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/timesync/timesyncd-manager.c b/src/timesync/timesyncd-manager.c
index 9f12149..d1f77a8 100644
--- a/src/timesync/timesyncd-manager.c
+++ b/src/timesync/timesyncd-manager.c
@@ -735,7 +735,8 @@ static int manager_begin(Manager *m) {
assert_return(m-current_server_address, -EHOSTUNREACH);
m-missed_replies = NTP_MAX_MISSED_REPLIES;
-m-poll_interval_usec = NTP_POLL_INTERVAL_MIN_SEC * USEC_PER_SEC;
+if (!m-poll_interval_usec)
+m-poll_interval_usec = NTP_POLL_INTERVAL_MIN_SEC *
USEC_PER_SEC;
server_address_pretty(m-current_server_address, pretty);
log_info(Using NTP server %s (%s)., strna(pretty),
m-current_server_name-string);
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/8] timesyncd bugfixing and improvements
When I was looking at the timesyncd code I noticed few issues that I thought could be easily fixed and you might be interested in. The last two patches is an attempt to fix the problem with frequent polling. I'm not sure if this is robust enough, I feel like a minor change in the code could break it easily, a more general approach might be needed, maybe track timing of requests to each address separately. I didn't try to fix the crash in resolving as Lennart said he would look into it, in my testing I just commented out the call flushing the addresses. Also, there seems to be a problem in the function adjusting the polling interval, it doesn't consider jitter. When the jitter is large it goes for a shorter interval instead of longer, making everything worse. My suggestion would be to include the approach used in ntpd (search for CLOCK_PGATE in the sources). Miroslav Lichvar (8): timesyncd: check if stratum is valid timesyncd: fix calculation of transmit time timesyncd: get kernel timestamp in nanoseconds timesyncd: check root distance timesyncd: use longer PLL time constant timesyncd: allow two missed replies before reselecting server timesyncd: don't reset polling interval when reselecting server timesyncd: wait before reconnecting to first server src/timesync/timesyncd-manager.c | 91 +--- src/timesync/timesyncd-manager.h | 2 + 2 files changed, 69 insertions(+), 24 deletions(-) -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 8/8] timesyncd: wait before reconnecting to first server
When all servers are exhausted, wait for one poll interval before trying
to connect again to the first server in the list. Also, keep increasing
the polling interval to make sure a client not getting any valid replies
will not send requests to any server more frequently than is allowed by
the maximum polling interval.
---
src/timesync/timesyncd-manager.c | 24 +++-
src/timesync/timesyncd-manager.h | 1 +
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/src/timesync/timesyncd-manager.c b/src/timesync/timesyncd-manager.c
index d1f77a8..3fd221e 100644
--- a/src/timesync/timesyncd-manager.c
+++ b/src/timesync/timesyncd-manager.c
@@ -882,6 +882,7 @@ int manager_connect(Manager *m) {
manager_set_server_name(m,
m-current_server_name-names_next);
else {
ServerName *f;
+bool restart = true;
/* Our current server name list is exhausted,
* let's find the next one to iterate. First
@@ -898,6 +899,8 @@ int manager_connect(Manager *m) {
f = m-link_servers;
if (!f)
f = m-system_servers;
+else
+restart = false;
}
if (!f)
@@ -909,6 +912,25 @@ int manager_connect(Manager *m) {
return 0;
}
+if (restart !m-exhausted_servers
m-poll_interval_usec) {
+log_debug(Waiting after exhausting servers.);
+r = sd_event_add_time(m-event,
m-event_retry, clock_boottime_or_monotonic(),
now(clock_boottime_or_monotonic()) + m-poll_interval_usec, 0,
manager_retry_connect, m);
+if (r 0) {
+log_error(Failed to create retry
timer: %s, strerror(-r));
+return r;
+}
+
+m-exhausted_servers = true;
+
+/* Increase the polling interval */
+if (m-poll_interval_usec
NTP_POLL_INTERVAL_MAX_SEC * USEC_PER_SEC)
+m-poll_interval_usec *= 2;
+
+return 0;
+}
+
+m-exhausted_servers = false;
+
manager_set_server_name(m, f);
}
@@ -1049,7 +1071,7 @@ static int manager_network_event_handler(sd_event_source
*s, int fd, uint32_t re
online = network_is_online();
/* check if the client is currently connected */
-connected = m-server_socket = 0 || m-resolve_query;
+connected = m-server_socket = 0 || m-resolve_query ||
m-exhausted_servers;
if (connected !online) {
log_info(No network connectivity, watching for changes.);
diff --git a/src/timesync/timesyncd-manager.h b/src/timesync/timesyncd-manager.h
index 1d3cc62..c7efdc5 100644
--- a/src/timesync/timesyncd-manager.h
+++ b/src/timesync/timesyncd-manager.h
@@ -41,6 +41,7 @@ struct Manager {
LIST_HEAD(ServerName, fallback_servers);
RateLimit ratelimit;
+bool exhausted_servers;
/* network */
sd_event_source *network_event_source;
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 4/8] timesyncd: check root distance
NTPv4 servers don't reply with unsynchronized status when they lost
synchronization, they only keep increasing the root dispersion and it's
up to the client to decide at which point they no longer consider it
synchronized.
Ignore replies with root distance over 5 seconds.
---
src/timesync/timesyncd-manager.c | 16
1 file changed, 16 insertions(+)
diff --git a/src/timesync/timesyncd-manager.c b/src/timesync/timesyncd-manager.c
index 2b0580c..9b8b7d3 100644
--- a/src/timesync/timesyncd-manager.c
+++ b/src/timesync/timesyncd-manager.c
@@ -89,6 +89,9 @@
#define NTP_FIELD_MODE(f) ((f) 7)
#define NTP_FIELD(l, v, m) (((l) 6) | ((v) 3) | (m))
+/* Maximum acceptable root distance in seconds. */
+#define NTP_MAX_ROOT_DISTANCE 5.0
+
/*
* NTP timestamps are represented as a 64-bit unsigned fixed-point number,
* in seconds relative to 0h on 1 January 1900.
@@ -128,6 +131,10 @@ struct ntp_msg {
static int manager_arm_timer(Manager *m, usec_t next);
static int manager_clock_watch_setup(Manager *m);
+static double ntp_ts_short_to_d(const struct ntp_ts_short *ts) {
+return be16toh(ts-sec) + (be16toh(ts-frac) / 65536.0);
+}
+
static double ntp_ts_to_d(const struct ntp_ts *ts) {
return be32toh(ts-sec) + ((double)be32toh(ts-frac) / UINT_MAX);
}
@@ -500,6 +507,7 @@ static int manager_receive_response(sd_event_source
*source, int fd, uint32_t re
ssize_t len;
double origin, receive, trans, dest;
double delay, offset;
+double root_distance;
bool spike;
int leap_sec;
int r;
@@ -585,6 +593,12 @@ static int manager_receive_response(sd_event_source
*source, int fd, uint32_t re
return manager_connect(m);
}
+root_distance = ntp_ts_short_to_d(ntpmsg.root_delay) / 2 +
ntp_ts_short_to_d(ntpmsg.root_dispersion);
+if (root_distance NTP_MAX_ROOT_DISTANCE) {
+log_debug(Server has too large root distance.
Disconnecting.);
+return manager_connect(m);
+}
+
/* valid packet */
m-pending = false;
m-retry_interval = 0;
@@ -626,6 +640,7 @@ static int manager_receive_response(sd_event_source
*source, int fd, uint32_t re
mode : %u\n
stratum : %u\n
precision: %.6f sec (%d)\n
+root distance: %.6f sec\n
reference: %.4s\n
origin : %.3f\n
receive : %.3f\n
@@ -641,6 +656,7 @@ static int manager_receive_response(sd_event_source
*source, int fd, uint32_t re
NTP_FIELD_MODE(ntpmsg.field),
ntpmsg.stratum,
exp2(ntpmsg.precision), ntpmsg.precision,
+ root_distance,
ntpmsg.stratum == 1 ? ntpmsg.refid : n/a,
origin - OFFSET_1900_1970,
receive - OFFSET_1900_1970,
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 6/8] timesyncd: allow two missed replies before reselecting server
After receiving a reply from the server, allow two missed replies before
switching to another server to avoid unnecessary clock hopping when
packets are getting lost in the network.
---
src/timesync/timesyncd-manager.c | 27 ++-
src/timesync/timesyncd-manager.h | 1 +
2 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/src/timesync/timesyncd-manager.c b/src/timesync/timesyncd-manager.c
index bd6bc39..9f12149 100644
--- a/src/timesync/timesyncd-manager.c
+++ b/src/timesync/timesyncd-manager.c
@@ -92,6 +92,9 @@
/* Maximum acceptable root distance in seconds. */
#define NTP_MAX_ROOT_DISTANCE 5.0
+/* Maximum number of missed replies before selecting another source. */
+#define NTP_MAX_MISSED_REPLIES 2
+
/*
* NTP timestamps are represented as a 64-bit unsigned fixed-point number,
* in seconds relative to 0h on 1 January 1900.
@@ -219,15 +222,18 @@ static int manager_send_request(Manager *m) {
return r;
}
-r = sd_event_add_time(
-m-event,
-m-event_timeout,
-clock_boottime_or_monotonic(),
-now(clock_boottime_or_monotonic()) + TIMEOUT_USEC, 0,
-manager_timeout, m);
-if (r 0) {
-log_error(Failed to arm timeout timer: %s, strerror(-r));
-return r;
+m-missed_replies++;
+if (m-missed_replies NTP_MAX_MISSED_REPLIES) {
+r = sd_event_add_time(
+m-event,
+m-event_timeout,
+clock_boottime_or_monotonic(),
+now(clock_boottime_or_monotonic()) +
TIMEOUT_USEC, 0,
+manager_timeout, m);
+if (r 0) {
+log_error(Failed to arm timeout timer: %s,
strerror(-r));
+return r;
+}
}
return 0;
@@ -562,6 +568,8 @@ static int manager_receive_response(sd_event_source
*source, int fd, uint32_t re
return 0;
}
+m-missed_replies = 0;
+
/* check our time cookie (we just stored nanoseconds in the fraction
field) */
if (be32toh(ntpmsg.origin_time.sec) != m-trans_time.tv_sec +
OFFSET_1900_1970 ||
be32toh(ntpmsg.origin_time.frac) != m-trans_time.tv_nsec) {
@@ -726,6 +734,7 @@ static int manager_begin(Manager *m) {
assert_return(m-current_server_name, -EHOSTUNREACH);
assert_return(m-current_server_address, -EHOSTUNREACH);
+m-missed_replies = NTP_MAX_MISSED_REPLIES;
m-poll_interval_usec = NTP_POLL_INTERVAL_MIN_SEC * USEC_PER_SEC;
server_address_pretty(m-current_server_address, pretty);
diff --git a/src/timesync/timesyncd-manager.h b/src/timesync/timesyncd-manager.h
index 2345bf8..1d3cc62 100644
--- a/src/timesync/timesyncd-manager.h
+++ b/src/timesync/timesyncd-manager.h
@@ -52,6 +52,7 @@ struct Manager {
ServerName *current_server_name;
ServerAddress *current_server_address;
int server_socket;
+int missed_replies;
uint64_t packet_count;
sd_event_source *event_timeout;
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/8] timesyncd: get kernel timestamp in nanoseconds
---
src/timesync/timesyncd-manager.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/src/timesync/timesyncd-manager.c b/src/timesync/timesyncd-manager.c
index 3339606..2b0580c 100644
--- a/src/timesync/timesyncd-manager.c
+++ b/src/timesync/timesyncd-manager.c
@@ -136,10 +136,6 @@ static double ts_to_d(const struct timespec *ts) {
return ts-tv_sec + (1.0e-9 * ts-tv_nsec);
}
-static double tv_to_d(const struct timeval *tv) {
-return tv-tv_sec + (1.0e-6 * tv-tv_usec);
-}
-
static double square(double d) {
return d * d;
}
@@ -500,7 +496,7 @@ static int manager_receive_response(sd_event_source
*source, int fd, uint32_t re
.msg_namelen = sizeof(server_addr),
};
struct cmsghdr *cmsg;
-struct timeval *recv_time;
+struct timespec *recv_time;
ssize_t len;
double origin, receive, trans, dest;
double delay, offset;
@@ -543,8 +539,8 @@ static int manager_receive_response(sd_event_source
*source, int fd, uint32_t re
continue;
switch (cmsg-cmsg_type) {
-case SCM_TIMESTAMP:
-recv_time = (struct timeval *) CMSG_DATA(cmsg);
+case SCM_TIMESTAMPNS:
+recv_time = (struct timespec *) CMSG_DATA(cmsg);
break;
}
}
@@ -615,7 +611,7 @@ static int manager_receive_response(sd_event_source
*source, int fd, uint32_t re
origin = ts_to_d(m-trans_time) + OFFSET_1900_1970;
receive = ntp_ts_to_d(ntpmsg.recv_time);
trans = ntp_ts_to_d(ntpmsg.trans_time);
-dest = tv_to_d(recv_time) + OFFSET_1900_1970;
+dest = ts_to_d(recv_time) + OFFSET_1900_1970;
offset = ((receive - origin) + (trans - dest)) / 2;
delay = (dest - origin) - (trans - receive);
@@ -697,7 +693,7 @@ static int manager_listen_setup(Manager *m) {
if (r 0)
return -errno;
-r = setsockopt(m-server_socket, SOL_SOCKET, SO_TIMESTAMP, on,
sizeof(on));
+r = setsockopt(m-server_socket, SOL_SOCKET, SO_TIMESTAMPNS, on,
sizeof(on));
if (r 0)
return -errno;
--
1.9.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/8] timesyncd: fix calculation of transmit time
The kernel timestamp (recv_time) is made earlier than current time (now_ts), use the timestamp captured before sending packet directly. --- src/timesync/timesyncd-manager.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/timesync/timesyncd-manager.c b/src/timesync/timesyncd-manager.c index 60f39c6..3339606 100644 --- a/src/timesync/timesyncd-manager.c +++ b/src/timesync/timesyncd-manager.c @@ -500,7 +500,6 @@ static int manager_receive_response(sd_event_source *source, int fd, uint32_t re .msg_namelen = sizeof(server_addr), }; struct cmsghdr *cmsg; -struct timespec now_ts; struct timeval *recv_time; ssize_t len; double origin, receive, trans, dest; @@ -613,8 +612,7 @@ static int manager_receive_response(sd_event_source *source, int fd, uint32_t re * The round-trip delay, d, and system clock offset, t, are defined as: * d = (T4 - T1) - (T3 - T2) t = ((T2 - T1) + (T3 - T4)) / 2 */ -assert_se(clock_gettime(clock_boottime_or_monotonic(), now_ts) = 0); -origin = tv_to_d(recv_time) - (ts_to_d(now_ts) - ts_to_d(m-trans_time_mon)) + OFFSET_1900_1970; +origin = ts_to_d(m-trans_time) + OFFSET_1900_1970; receive = ntp_ts_to_d(ntpmsg.recv_time); trans = ntp_ts_to_d(ntpmsg.trans_time); dest = tv_to_d(recv_time) + OFFSET_1900_1970; -- 1.9.3 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] bootchart: only show printable processes
On 08/27/2014 03:49 AM, Lennart Poettering wrote:
On Tue, 26.08.14 18:11, Mantas Mikulėnas (graw...@gmail.com) wrote:
On Tue, Aug 26, 2014 at 5:07 PM, WaLyong Cho walyong@samsung.com wrote:
This case really shouldn't be happen. (But actually sometime that was
happen.) Eeven if happened we maybe want to see the bootchart exclude
not printable processes.
---
src/bootchart/svg.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/bootchart/svg.c b/src/bootchart/svg.c
index 135883f..9b7de33 100644
--- a/src/bootchart/svg.c
+++ b/src/bootchart/svg.c
@@ -1014,6 +1014,9 @@ static void svg_ps_bars(void) {
if (!enc_name)
continue;
+if (!utf8_is_printable(enc_name, strlen(enc_name)))
+continue;
+
/* leave some trace of what we actually filtered etc. */
svg(!-- %s [%i] ppid=%i runtime=%.03fs --\n, enc_name,
ps-pid,
ps-ppid, ps-total);
If the name is not printable, wouldn't it be better to show it in
escaped form rather than pretend it doesn't exist at all?
Yeah I agree. I'd love to merge a patch that intrdouces
utf8_escape_non_printable() or so, that works similar to
utf8_escape_invalid(), but also escapes non-printable chars, and then
make use of this here...
OK, but I'm confusing. We already have *cescape*. Is it not enough with
*cescape*?
Just silently ignore the entry doesn't sound right, the absolute minimum
should be to add a warning with log_warning()...
Lennart
WaLyong
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] timedated: add configure option to set name of controlled NTP service
Hi Miroslav, ConnMan is a single daemon solution doing NTP, DHCP and DNS all in one place. Any sort of callouts are costing time. And that is time that has a visible user impact. There is nothing that justifies to have a bit more nanosecond accuracy of synchronized time than making the user wait for extra milliseconds to get their network connection and time. You need the first clock update to happen milliseconds after the network is up? Seriously? I agree that's not possible with chronyd or ntpd even if they were listening to networkd, but I don't think it's a requirement on any desktop system. start building a media client. Then you will see that the faster you have your IP address and the faster you have your clocks synchronized, the better your user experience gets. So this is all crucial. Until we fixed DHCP, everybody was fine waiting for many seconds to get an IP address. Now you get the IP in a few 100 milliseconds. But sure, lets go back to 10 years ago where everything took forever. And lets have a boot take 10 minutes. You might realize that a theme shows up here. If you are building a server, then by all means install ntpd or Chrony and configure it. You are the admin, you know what you are doing. If you do not know what are doing or do not care, then keep it simple. I'm not convinced. I think uninformed users should be using the best tool for the typical use case they have at hand. Trading falseticker detection, stable clock control with intermittent connections, ability to drift through when network is congested, ability to deal with broken clocks (as in some virtual machines) and monotonic time just for a super fast update seems like a bad choice to me. Seriously? That is what desktop users want. Cool, can you show me the desktop users that do care about this. I am actually curious now on how you justify doing all that with the expected battery life. I'm sure timesyncd will be significantly improved over time, but currently I'd not describe it as more than appropriate for most installations. That is the beauty of open source. If enough users care it will get added to timesyncd. So people will just start sending patches. Regards Marcel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/2] units: add ConditionInitrd=
---
man/systemd.unit.xml | 13 +
src/core/condition.c | 17 +
src/core/load-fragment-gperf.gperf.m4 | 1 +
src/shared/condition-util.c | 1 +
src/shared/condition-util.h | 1 +
5 files changed, 33 insertions(+)
diff --git a/man/systemd.unit.xml b/man/systemd.unit.xml
index c8d9300..4cd5201 100644
--- a/man/systemd.unit.xml
+++ b/man/systemd.unit.xml
@@ -919,6 +919,7 @@
termvarnameConditionACPower=/varname/term
termvarnameConditionNeedsUpdate=/varname/term
termvarnameConditionFirstBoot=/varname/term
+
termvarnameConditionInitrd=/varname/term
termvarnameConditionPathExists=/varname/term
termvarnameConditionPathExistsGlob=/varname/term
termvarnameConditionPathIsDirectory=/varname/term
@@ -1132,6 +1133,18 @@
when a new system instances boots up
for the first time./para
+paravarnameConditionInitrd=/varname
+may be used to check whether the root
+filesystem is an initramfs at the time
+of activation of the unit. It takes a
+boolean argument. If set to
+varnametrue/varname, the condition
+will hold only if the system runs from
+an initramfs. Conversely, if set to
+varnamefalse/varname, the condition
+will hold only if the system runs from
+the real root./para
+
paraWith
varnameConditionPathExists=/varname
a file existence condition is
diff --git a/src/core/condition.c b/src/core/condition.c
index 353e0c9..6be3d58 100644
--- a/src/core/condition.c
+++ b/src/core/condition.c
@@ -134,6 +134,20 @@ static bool condition_test_first_boot(Condition *c) {
return ((access(/run/systemd/first-boot, F_OK) = 0) == !!r) ==
!c-negate;
}
+static bool condition_test_initrd(Condition *c) {
+int r;
+
+assert(c);
+assert(c-parameter);
+assert(c-type == CONDITION_INITRD);
+
+r = parse_boolean(c-parameter);
+if (r 0)
+return c-negate;
+
+return (in_initrd() == !!r) == !c-negate;
+}
+
static bool condition_test(Condition *c) {
assert(c);
@@ -219,6 +233,9 @@ static bool condition_test(Condition *c) {
case CONDITION_FIRST_BOOT:
return condition_test_first_boot(c);
+case CONDITION_INITRD:
+return condition_test_initrd(c);
+
case CONDITION_NULL:
return !c-negate;
diff --git a/src/core/load-fragment-gperf.gperf.m4
b/src/core/load-fragment-gperf.gperf.m4
index 24aa80d..698f81f 100644
--- a/src/core/load-fragment-gperf.gperf.m4
+++ b/src/core/load-fragment-gperf.gperf.m4
@@ -170,6 +170,7 @@ Unit.ConditionSecurity,
config_parse_unit_condition_string, CONDITION_S
Unit.ConditionCapability,config_parse_unit_condition_string,
CONDITION_CAPABILITY, 0
Unit.ConditionHost, config_parse_unit_condition_string,
CONDITION_HOST,0
Unit.ConditionACPower, config_parse_unit_condition_string,
CONDITION_AC_POWER,0
+Unit.ConditionInitrd,config_parse_unit_condition_string,
CONDITION_INITRD, 0
Unit.ConditionNull, config_parse_unit_condition_null, 0,
0
m4_dnl
Service.PIDFile, config_parse_unit_path_printf, 0,
offsetof(Service, pid_file)
diff --git a/src/shared/condition-util.c b/src/shared/condition-util.c
index ff4a8ec..e5779ce 100644
--- a/src/shared/condition-util.c
+++ b/src/shared/condition-util.c
@@ -261,6 +261,7 @@ static const char* const
condition_type_table[_CONDITION_TYPE_MAX] = {
[CONDITION_ARCHITECTURE] = ConditionArchitecture,
[CONDITION_NEEDS_UPDATE] = ConditionNeedsUpdate,
[CONDITION_FIRST_BOOT] = ConditionFirstBoot,
+[CONDITION_INITRD] = ConditionInitrd,
[CONDITION_NULL] = ConditionNull
};
diff --git a/src/shared/condition-util.h b/src/shared/condition-util.h
index 047fdbf..a78fcd9 100644
--- a/src/shared/condition-util.h
+++ b/src/shared/condition-util.h
@@ -46,6 +46,7 @@ typedef enum ConditionType {
CONDITION_ARCHITECTURE,
CONDITION_NEEDS_UPDATE,
CONDITION_FIRST_BOOT,
+CONDITION_INITRD,
CONDITION_NULL,
_CONDITION_TYPE_MAX,
[systemd-devel] [PATCH 0/2] units: add and use ConditionInitrd= instead of checking for /etc/initrd-release.
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. Ivan Shapovalov (2): units: add ConditionInitrd= units: use ConditionInitrd=true instead of ConditionPathExists=/etc/initrd-release man/systemd.unit.xml | 13 + src/core/condition.c | 17 + src/core/load-fragment-gperf.gperf.m4 | 1 + src/shared/condition-util.c| 1 + src/shared/condition-util.h| 1 + units/initrd-cleanup.service.in| 2 +- units/initrd-fs.target | 2 +- units/initrd-parse-etc.service.in | 2 +- units/initrd-root-fs.target| 2 +- units/initrd-switch-root.service.in| 2 +- units/initrd-switch-root.target| 2 +- units/initrd-udevadm-cleanup-db.service.in | 2 +- units/initrd.target| 2 +- units/systemd-hibernate-res...@.service.in | 2 +- 14 files changed, 42 insertions(+), 9 deletions(-) -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/2] units: use ConditionInitrd=true instead of ConditionPathExists=/etc/initrd-release
--- units/initrd-cleanup.service.in| 2 +- units/initrd-fs.target | 2 +- units/initrd-parse-etc.service.in | 2 +- units/initrd-root-fs.target| 2 +- units/initrd-switch-root.service.in| 2 +- units/initrd-switch-root.target| 2 +- units/initrd-udevadm-cleanup-db.service.in | 2 +- units/initrd.target| 2 +- units/systemd-hibernate-res...@.service.in | 2 +- 9 files changed, 9 insertions(+), 9 deletions(-) diff --git a/units/initrd-cleanup.service.in b/units/initrd-cleanup.service.in index b1dda16..833c59d 100644 --- a/units/initrd-cleanup.service.in +++ b/units/initrd-cleanup.service.in @@ -8,7 +8,7 @@ [Unit] Description=Cleaning Up and Shutting Down Daemons DefaultDependencies=no -ConditionPathExists=/etc/initrd-release +ConditionInitrd=true OnFailure=emergency.target OnFailureJobMode=replace-irreversibly After=initrd-root-fs.target initrd-fs.target initrd.target diff --git a/units/initrd-fs.target b/units/initrd-fs.target index 7ec838a..a02a3b4 100644 --- a/units/initrd-fs.target +++ b/units/initrd-fs.target @@ -10,7 +10,7 @@ Description=Initrd File Systems Documentation=man:systemd.special(7) OnFailure=emergency.target OnFailureJobMode=replace-irreversibly -ConditionPathExists=/etc/initrd-release +ConditionInitrd=true After=initrd-parse-etc.service DefaultDependencies=no Conflicts=shutdown.target diff --git a/units/initrd-parse-etc.service.in b/units/initrd-parse-etc.service.in index c0b2543..22fe8cc 100644 --- a/units/initrd-parse-etc.service.in +++ b/units/initrd-parse-etc.service.in @@ -12,7 +12,7 @@ Requires=initrd-root-fs.target After=initrd-root-fs.target OnFailure=emergency.target OnFailureJobMode=replace-irreversibly -ConditionPathExists=/etc/initrd-release +ConditionInitrd=true [Service] Type=oneshot diff --git a/units/initrd-root-fs.target b/units/initrd-root-fs.target index 64f0a92..cabba13 100644 --- a/units/initrd-root-fs.target +++ b/units/initrd-root-fs.target @@ -8,7 +8,7 @@ [Unit] Description=Initrd Root File System Documentation=man:systemd.special(7) -ConditionPathExists=/etc/initrd-release +ConditionInitrd=true OnFailure=emergency.target OnFailureJobMode=replace-irreversibly DefaultDependencies=no diff --git a/units/initrd-switch-root.service.in b/units/initrd-switch-root.service.in index 82893da..b4475aa 100644 --- a/units/initrd-switch-root.service.in +++ b/units/initrd-switch-root.service.in @@ -8,7 +8,7 @@ [Unit] Description=Switch Root DefaultDependencies=no -ConditionPathExists=/etc/initrd-release +ConditionInitrd=true OnFailure=emergency.target OnFailureJobMode=replace-irreversibly AllowIsolate=yes diff --git a/units/initrd-switch-root.target b/units/initrd-switch-root.target index f347687..fbee5c2 100644 --- a/units/initrd-switch-root.target +++ b/units/initrd-switch-root.target @@ -7,7 +7,7 @@ [Unit] Description=Switch Root -ConditionPathExists=/etc/initrd-release +ConditionInitrd=true DefaultDependencies=no Requires=initrd-switch-root.service Before=initrd-switch-root.service diff --git a/units/initrd-udevadm-cleanup-db.service.in b/units/initrd-udevadm-cleanup-db.service.in index 5c6654e..6b97425 100644 --- a/units/initrd-udevadm-cleanup-db.service.in +++ b/units/initrd-udevadm-cleanup-db.service.in @@ -8,7 +8,7 @@ [Unit] Description=Cleanup udevd DB DefaultDependencies=no -ConditionPathExists=/etc/initrd-release +ConditionInitrd=true Conflicts=systemd-udevd.service systemd-udevd-control.socket systemd-udevd-kernel.socket After=systemd-udevd.service systemd-udevd-control.socket systemd-udevd-kernel.socket Before=initrd-switch-root.target diff --git a/units/initrd.target b/units/initrd.target index eae7c70..81af69e 100644 --- a/units/initrd.target +++ b/units/initrd.target @@ -10,7 +10,7 @@ Description=Initrd Default Target Documentation=man:systemd.special(7) OnFailure=emergency.target OnFailureJobMode=replace-irreversibly -ConditionPathExists=/etc/initrd-release +ConditionInitrd=true Requires=basic.target Wants=initrd-root-fs.target initrd-fs.target initrd-parse-etc.service After=initrd-root-fs.target initrd-fs.target basic.target rescue.service rescue.target diff --git a/units/systemd-hibernate-res...@.service.in b/units/systemd-hibernate-res...@.service.in index 6db584d..3e8c2ef 100644 --- a/units/systemd-hibernate-res...@.service.in +++ b/units/systemd-hibernate-res...@.service.in @@ -13,7 +13,7 @@ BindsTo=%i.device Wants=local-fs-pre.target After=%i.device Before=local-fs-pre.target systemd-remount-fs.service systemd-fsck-root.service -ConditionPathExists=/etc/initrd-release +ConditionInitrd=true [Service] Type=oneshot -- 2.1.0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] units: remove unnecessary ordering dependencies in systemd-hibernate-resume@.service
They were left from an early review iteration, when hibernate-resume functionality was intended to work also outside of initramfs. Now this is not the case, and these dependencies became redundant as systemd-fsck-root.service can never be part of initramfs, and systemd-remount-fs.service makes little sense in it. --- This is per Thomas's post-commit review. units/systemd-hibernate-res...@.service.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/units/systemd-hibernate-res...@.service.in b/units/systemd-hibernate-res...@.service.in index 3e8c2ef..1a4269b 100644 --- a/units/systemd-hibernate-res...@.service.in +++ b/units/systemd-hibernate-res...@.service.in @@ -12,7 +12,7 @@ DefaultDependencies=no BindsTo=%i.device Wants=local-fs-pre.target After=%i.device -Before=local-fs-pre.target systemd-remount-fs.service systemd-fsck-root.service +Before=local-fs-pre.target ConditionInitrd=true [Service] -- 2.1.0 ___ 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.
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? We should be really careful when it comes to an inflation of conditions... Ivan Shapovalov (2): units: add ConditionInitrd= units: use ConditionInitrd=true instead of ConditionPathExists=/etc/initrd-release man/systemd.unit.xml | 13 + src/core/condition.c | 17 + src/core/load-fragment-gperf.gperf.m4 | 1 + src/shared/condition-util.c| 1 + src/shared/condition-util.h| 1 + units/initrd-cleanup.service.in| 2 +- units/initrd-fs.target | 2 +- units/initrd-parse-etc.service.in | 2 +- units/initrd-root-fs.target| 2 +- units/initrd-switch-root.service.in| 2 +- units/initrd-switch-root.target| 2 +- units/initrd-udevadm-cleanup-db.service.in | 2 +- units/initrd.target| 2 +- units/systemd-hibernate-res...@.service.in | 2 +- 14 files changed, 42 insertions(+), 9 deletions(-) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 0/2] units: add and use ConditionInitrd= instead of checking for /etc/initrd-release.
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? We should be really careful when it comes to an inflation of conditions... Let's just cc Thomas Bächler who proposed this. Personally I see only one benefit (which is described in cover letter)... -- Ivan Shapovalov / intelfx / signature.asc Description: This is a digitally signed message part. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2 v3] socket: introduce SELinuxContextFromNet option
On Wed, 27.08.14 04:45, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: +} + +bcon = context_new(mycon); +if (!bcon) +goto out; This will return 0. Should return log_oom() or ENOMEM instead? Please use ENOMEM here, don't use log_oom(). This is is more or less a library call, so it shouldn't log on its own, but leave that to the caller... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC] [PATCH 0/3] resume: implement support for resuming from hibernation
On Wed, 27.08.14 10:19, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: Hi Ivan, Great job! I was wondering if a ./configure switch makes sense to disable it. Embedded devices won't be using it. Sure! I'd be happy to merge a patch that makes this compile-time optional. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv6 0/3] hibernate-resume: implement support for resuming from hibernation
On Wed, 27.08.14 13:17, Ivan Shapovalov (intelfx...@gmail.com) wrote: On Wednesday 27 August 2014 at 03:16:10, Zbigniew Jędrzejewski-Szmek wrote: On Tue, Aug 26, 2014 at 10:21:59PM +0200, Lennart Poettering wrote: On Wed, 27.08.14 00:17, Ivan Shapovalov (intelfx...@gmail.com) wrote: This patchset allows systemd to parse resume= kernel command line parameter and initiate resume from the specified device. What about swap files with the resume_offset= parameter? Are they still being used? I don't know if somebody uses that, but for now it's missing functionality. After a cursory search, I could not find a mechanism to initiate a resume with offset from userspace. In Arch, it was never implemented even if possible. I wouldn't bother until somebody actually really runs into this. And even then I'd be careful whether we really want to support that... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv6 2/3] hibernate-resume: add a tool to write a device node's major:minor to /sys/power/resume.
On Wed, 27.08.14 08:18, Thomas Bächler (tho...@archlinux.org) wrote: +[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. Yeah, I figure Requires= might be slightly more appropriate for this, given that it fails on its own if the device ends up not being available anymore... 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. I think for most purposes we should consider the initrd mostly read-only, hence I wouldn't rely on this check, even though it might effectively make the dep unnecessary... +ConditionPathExists=/etc/initrd-release We should have and use ConditionInitrd=. I am surprised that this doesn't exist, but it really should. Why? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCHv6 2/3] hibernate-resume: add a tool to write a device node's major:minor to /sys/power/resume.
On Wed, 27.08.14 10:59, Andrei Borzenkov (arvidj...@gmail.com) wrote: On Wed, Aug 27, 2014 at 10:18 AM, Thomas Bächler tho...@archlinux.org wrote: +[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. Semantic of Requires is simply wrong for device - you cannot start device, you can only passively wait for it. Requisite is more appropriate to express cannot start until device is available. But I think, BindsTo is established usage for devices and is quite clear here. Well, starting a device means waitinf for it. Requires and Requisite really have the same effect here... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
From: Thomas Suckow thomas.suc...@pnnl.gov From: Lennart Poettering lenn...@poettering.net Note that a concept of mount at boot if it is there, otherwise don't cannot work. It worked until a week or two ago. I want it back. I'm sure you're right that in the abstract, it cannot be made to work. But that isn't the problem I'm facing. It seems that a workaround could be to not put the volume in fstab and add a unit to the startup that would mount it if present. If you wanted to mount it later, you could manually start the unit again. I'd rather adjust systemd and leave fstab stable than vice-versa. Here's an interesting fact: What systemd does (in this situation) isn't true automounting; rather it waits for the *first* time the device/volume becomes available, and then mounts it. Any later attachments of the volume do not cause mounting (until the next reboot). But at this point, I only need to investigate the issue. The documentation I've managed to find about systemd is rather abstract, there's no map between specific bits of functionality and the files that control them. My understanding is that everything systemd does is controlled by units. In this case, entries in fstab cause the creation of units based on a template. If you could point me to the template file in question, it would probably point me to all of the things I need to investigate. Thanks, Dale ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] tty-ask-password-agent: reset a signal handler for SIGTERM to the default
On Wed, 27.08.14 09:47, HATAYAMA, Daisuke (d.hatay...@jp.fujitsu.com) wrote: Sounds like the right option here... I have now added a slightly different patch (1dedb74a2e1d840b531b76b01a76979f3b57456b) that does this. Thanks! But this could still hang in very rare case becuase the reset is done in a child process after fork(). Please consider the case where the child process continue sleeping after fork() before resetting signal handlers until it receives SIGTERM. For such reason, my patch resets SIGTERM signal handler in the parent systemctl side. Hmm, there's indeed a race here. I add a commit now that will block all signals before forking, and unblocks them afterwards. The new process will hence be created with all signals blocked, and we will hence not lose them until we after we reset the signal handlers... Hope this makes sense? (Blocking the signals temporarily, instead of resetting the signal handlers has the benefit, that we signal masks are per-thread, and not per-process, like signal handlers are. The code hence stays generic enough to not break should the call ever get invoked from a threaded process...) Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 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] Suppressing automounting
On Aug 27, 2014 10:03 PM, Dale R. Worley wor...@alum.mit.edu wrote: From: Thomas Suckow thomas.suc...@pnnl.gov From: Lennart Poettering lenn...@poettering.net Note that a concept of mount at boot if it is there, otherwise don't cannot work. It worked until a week or two ago. I want it back. I'm sure you're right that in the abstract, it cannot be made to work. But that isn't the problem I'm facing. It seems that a workaround could be to not put the volume in fstab and add a unit to the startup that would mount it if present. If you wanted to mount it later, you could manually start the unit again. I'd rather adjust systemd and leave fstab stable than vice-versa. Here's an interesting fact: What systemd does (in this situation) isn't true automounting; rather it waits for the *first* time the device/volume becomes available, and then mounts it. Any later attachments of the volume do not cause mounting (until the next reboot). But at this point, I only need to investigate the issue. The documentation I've managed to find about systemd is rather abstract, there's no map between specific bits of functionality and the files that control them. My understanding is that everything systemd does is controlled by units. In this case, entries in fstab cause the creation of units based on a template. If you could point me to the template file in question, it would probably point me to all of the things I need to investigate. For fstab, the units are created by a 'generator' (systemd-fstab-generator), which writes them under /run/systemd/generator every time the configuration is reloaded. I'm not at my PC right now so I cannot check, but I /do/ remember someone mentioning that if a fstab entry has the 'auto' option, then the generator also symlinks the corresponding .mount unit under devpath.device.wants/ (e.g. dev-sda3.device.wants/mnt-backup.mount), causing the .mount unit to be triggered *every* time that device appears on the system. That is, in addition to local-fs.target triggering foo.mount and waiting for bar.device one time only (as you describe), it makes bar.device itself trigger foo.mount every time as well. -- Mantas Mikulėnas graw...@gmail.com // sent from phone ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: warn instead of killing kmod loading
On Mon, Aug 11, 2014 at 10:19 AM, Luis R. Rodriguez mcg...@suse.com wrote: On Mon, Aug 11, 2014 at 12:57 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 11.08.14 18:39, Luis R. Rodriguez (mcg...@suse.com) wrote: This looks really wrong. We shouldn't permit worker processes to be blocked indefinitely without any timeout applied. Designing a worker process system like that is simply wrong. It's one thing to allow changing the specific timeout applied, it's a very different thing to allow broken drivers to completely stall the worker process logic. OK what if we enable customizations then on the timeout by the built-in cmd type and we use a high multiplier for now for kmod ? A multiplier for kmod of 10 would set the kmod timeout to 5 minutes then, as we sweep up and clean drivers we can reduce this over time. This would also enable us to keep the default timeout for the other type of workers. Why this complexity? I mean, it sounds much simpler to simply increase the default timeout a bit, if it turns out to be too low for the current cases... True, there's two things here and one of which this v2 patch didn't address: 1) It'd be good for defaults on systemd to work on most systems based on upstream kernels today, right now folks deploying systemd would need to modify the default timeout. Are we up to bump the default up considerably? If its high, would that be unfair for classes of workers we know shouldn't take that long, or wouldn't that allow folks developing new workers to take longer? 2) We want chatty logs to allow us to keep track of drivers that need attention. Ideally right now we should strive for 30 seconds init and work on asynching most work, we want to do this in a non fatal way. Overriding the timeout won't let us to keep track of buggy drivers that need love from systemd's perspective to stay within the 30 second bound time. We can have chatty logs from the kernel but using a timeout on the driver core seems a bit overkill specially if systemd is already keeping track of driver's init time, so it'd be better if we could collect offending drivers from systemd. I could have implemented support for this in this v2 patch by simply adding another check using the default timeout. Thoughts / advice? Upstream wise on the Linux front we have come the the realization that many drivers are not to blame given that it was not init on driver paths that was taking long but instead probe. The problem is caused by how the driver core currently batches together both driver init and probe if a bus as autoprobe enabled and most buses do have this enabled. I implemented a proof of concept patch that enables splitting up init / probe by default always and runs probe asynchronously for all drivers [0]. On my system this actually decreased boot time and I only had an issue with my keyboard driver but suspect that could have been that I wasn't adding drivers onto the deferred probe queue by checking the probe return. I made some other changes to get this to compile but those would have to go in separately and be broken down cleanly [1]. Based on a follow up conversation with Greg at Linuxcon he mentioned Dmitry Torokhov has been wanting something similar since February when Wu Zhangjin fal...@meizu.com had posted another asynch probe proof of concept patch [2]. Greg has indicated that he'd now take this on himself and work on a generic asynch probe mechanism that would enable drivers to specific if they need asynch probe or not. Given all this we want to easily find drivers that need asynch probe enabled (although I'd still argue we should strive to just enable asynch probe for all drivers) and right now systemd won't let us easily find these. In light of all this does this does this patch make more sense now? If not any other recommendations? [0] http://lists.freedesktop.org/archives/systemd-devel/2014-August/022156.html [1] http://drvbp1.linux-foundation.org/~mcgrof/patches/2014/08/27/changes-init-module.patch [2] https://lkml.org/lkml/2014/8/14/11 Luis ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: warn instead of killing kmod loading
On Wed, Aug 27, 2014 at 03:51:58PM -0700, Luis R. Rodriguez wrote: On Mon, Aug 11, 2014 at 10:19 AM, Luis R. Rodriguez mcg...@suse.com wrote: On Mon, Aug 11, 2014 at 12:57 PM, Lennart Poettering lenn...@poettering.net wrote: On Mon, 11.08.14 18:39, Luis R. Rodriguez (mcg...@suse.com) wrote: This looks really wrong. We shouldn't permit worker processes to be blocked indefinitely without any timeout applied. Designing a worker process system like that is simply wrong. It's one thing to allow changing the specific timeout applied, it's a very different thing to allow broken drivers to completely stall the worker process logic. OK what if we enable customizations then on the timeout by the built-in cmd type and we use a high multiplier for now for kmod ? A multiplier for kmod of 10 would set the kmod timeout to 5 minutes then, as we sweep up and clean drivers we can reduce this over time. This would also enable us to keep the default timeout for the other type of workers. Why this complexity? I mean, it sounds much simpler to simply increase the default timeout a bit, if it turns out to be too low for the current cases... True, there's two things here and one of which this v2 patch didn't address: 1) It'd be good for defaults on systemd to work on most systems based on upstream kernels today, right now folks deploying systemd would need to modify the default timeout. Are we up to bump the default up considerably? If its high, would that be unfair for classes of workers we know shouldn't take that long, or wouldn't that allow folks developing new workers to take longer? 2) We want chatty logs to allow us to keep track of drivers that need attention. Ideally right now we should strive for 30 seconds init and work on asynching most work, we want to do this in a non fatal way. Overriding the timeout won't let us to keep track of buggy drivers that need love from systemd's perspective to stay within the 30 second bound time. We can have chatty logs from the kernel but using a timeout on the driver core seems a bit overkill specially if systemd is already keeping track of driver's init time, so it'd be better if we could collect offending drivers from systemd. I could have implemented support for this in this v2 patch by simply adding another check using the default timeout. Thoughts / advice? Upstream wise on the Linux front we have come the the realization that many drivers are not to blame given that it was not init on driver paths that was taking long but instead probe. The problem is caused by how the driver core currently batches together both driver init and probe if a bus as autoprobe enabled and most buses do have this enabled. I implemented a proof of concept patch that enables splitting up init / probe by default always and runs probe asynchronously for all drivers [0]. On my system this actually decreased boot time and I only had an issue with my keyboard driver but suspect that could have been that I wasn't adding drivers onto the deferred probe queue by checking the probe return. I made some other changes to get this to compile but those would have to go in separately and be broken down cleanly [1]. Based on a follow up conversation with Greg at Linuxcon he mentioned Dmitry Torokhov has been wanting something similar since February when Wu Zhangjin fal...@meizu.com had posted another asynch probe proof of concept patch [2]. Greg has indicated that he'd now take this on himself and work on a generic asynch probe mechanism that would enable drivers to specific if they need asynch probe or not. Hey, if you have patches already, I'll be glad to look at them :) And we can't do async for all drivers, we tried that 5+ years ago and lots of things broke, so we need to enable it on a case-by-case basis, unfortunately... thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: warn instead of killing kmod loading
On Wed, Aug 27, 2014 at 05:07:10PM -0700, Luis R. Rodriguez wrote: Hey, if you have patches already, I'll be glad to look at them :) OK well I'll spin what I have then, but I'm reviewing Wu's solution from February as well. I take it we'd want the async_schedule() approach rather that one based on kthread_create() right? Yes, that would be the best solution. And we can't do async for all drivers, we tried that 5+ years ago and lots of things broke, so we need to enable it on a case-by-case basis, unfortunately... Odd, I only had one thing that didn't come up and it was my keyboard, and I think I might know what the issue was. If enabled for all drivers would it have been easy to spot issues or was it obscure things? My system didn't blow up so I'd like to know what types of things blew up. It was all sorts of odd machines, not normal laptops and desktops from what I remember. Turns out that the link order really is needed for lots of embedded systems. We've gotten better now that we have a deferred probing, but there is still a lot of dependency information in link order that is needed on some machines. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Suppressing automounting
В Thu, 28 Aug 2014 00:31:49 +0300 Mantas Mikulėnas graw...@gmail.com пишет: On Aug 27, 2014 10:03 PM, Dale R. Worley wor...@alum.mit.edu wrote: From: Thomas Suckow thomas.suc...@pnnl.gov From: Lennart Poettering lenn...@poettering.net Note that a concept of mount at boot if it is there, otherwise don't cannot work. It worked until a week or two ago. I want it back. I'm sure you're right that in the abstract, it cannot be made to work. But that isn't the problem I'm facing. It seems that a workaround could be to not put the volume in fstab and add a unit to the startup that would mount it if present. If you wanted to mount it later, you could manually start the unit again. I'd rather adjust systemd and leave fstab stable than vice-versa. Here's an interesting fact: What systemd does (in this situation) isn't true automounting; rather it waits for the *first* time the device/volume becomes available, and then mounts it. Any later attachments of the volume do not cause mounting (until the next reboot). Well, that's how /etc/fstab always behaved, right? Anything in there is automounted just once, when system boots. Later you have to manually do it. But at this point, I only need to investigate the issue. The documentation I've managed to find about systemd is rather abstract, there's no map between specific bits of functionality and the files that control them. My understanding is that everything systemd does is controlled by units. In this case, entries in fstab cause the creation of units based on a template. If you could point me to the template file in question, it would probably point me to all of the things I need to investigate. For fstab, the units are created by a 'generator' (systemd-fstab-generator), which writes them under /run/systemd/generator every time the configuration is reloaded. I'm not at my PC right now so I cannot check, but I /do/ remember someone mentioning that if a fstab entry has the 'auto' option, then the generator also symlinks the corresponding .mount unit under devpath.device.wants/ (e.g. dev-sda3.device.wants/mnt-backup.mount), causing the .mount unit to be triggered *every* time that device appears on the system. That is, in addition to local-fs.target triggering foo.mount and waiting for bar.device one time only (as you describe), it makes bar.device itself trigger foo.mount every time as well. Hmm ... I'm not sure where this dependency comes from, but yes, it is there Requires=systemd-fsck@dev-sda1.service -.mount Wants=system.slice RequiredBy=local-fs.target systemd-sysctl.service WantedBy=dev-sda1.device Before=local-fs.target systemd-sysctl.service umount.target After=systemd-journald.socket dev-sda1.device systemd-fsck@dev-sda1.service local-fs-pre.target system.slice -.mount This looks like one of those implicit dependencies that are not documented anywhere ... ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
