Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd
On 29 January 2015 at 16:19, Rauta, Alin alin.ra...@intel.com wrote: So, we have: 1. BindCarrier=list of uplink ports 2. Network.DownlinkCarrierGroup=1 in upstream interface Network.UplinkCarrierGroup=1 in downstream interface This would mean you have to create 2 new members for the Network structure. 3. If we are to add 2 members then we can also think of adding: Network.UFDGroup = 1; Network.UFDType = uplink/downlink; For the feature to be visible I would say 3, but I'm fine with any of them. Hi all, As a sysadmin, my preference would be for option 1 - that is that you do the configuration in one place: the interface you are changing the behaviour of. I'd then imagine that networkctl could do something like: # networkctl ufd downlink0 UFD is configured on this interface Config File: /etc/systemd/network/downlink0.network Interface is UP because ANY uplink is UP Uplinks: uplink0 (DOWN) uplink1 (UP) # networkctl ufd uplink1 UFD is not configured on this interface or this interface is an uplink. The problem I see with this approach is that it allows bizarre configurations to be specified which don't make sense in practice: e.g. 1 - Loop: /etc/systemd/network/downlink0.network: BindCarrier=uplink* /etc/systemd/network/uplink0.network: BindCarrier=downlink* e.g. 2 - Chain /etc/systemd/network/downlink0.network: BindCarrier=uplink* /etc/systemd/network/uplink0.network: BindCarrier=thirdlink* All this is from a user point of view, without knowing what kind of code would be needed to support it. Regards, Dan ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] root= ignored
On Thu, Jan 29, 2015 at 2:20 AM, Felix Miata mrma...@earthlink.net wrote: I wrote clone for a reason. I don't just copy files. I clone (logical, root, autonomous) *partitions*, subsequently modifying only fstab, volume label and UUID before attempting boot from it. Clone is a generic term, it doesn't require a particular process. Are you changing the volume UUID with, e.g. tune2fs -U random? files from old to new (I actually used btrfs send receive). I of course had to install a new bootloader with grub2-install, and create The process I wrote was intended to make it clear that no bootloader that may have been on a Fedora / partition was used for booting a Fedora clone as adjusted to its new location. It's a process that was relatively simple and reliable until humanly memorable cmdline root= parameters what worked formerly began being disregarded by Fedora's boot process in apparent favor of incorporating a root filesystem UUID subject to change during backup/restore process in its initrd. Like I said, I can't reproduce this behavior. The BIOS system boots fine without rebuilding the initramfs just by changing fstab and grub.cfg UUIDs to match the root volume's UUID. Therefore I see no evidence root= is ignored on Fedora. The failed UEFI boot is strictly due to the old ESP UUID not being found. The failure has nothing to do with root=. dracut -f -v --debug shows only on UEFI is there a wait for device by uuid /usr/lib/dracut/modules.d/99base/module-setup.sh@113(install): wait_for_dev /dev/disk/by-uuid/5AC5-5766 -- Chris Murphy ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Support for staged startup
Hi all, I'd like to realize a staged startup with systemd which is mainly about: - starting up a static tree up to a final service - the only job of the final service is to kick off the start of an additional sub tree of units This kind of startup could be realized simply by adding an additional one shot service which executes: systemctl start xxx.target My question now is: Is this the appropriate way for realizing this or is there any other more elegant way. My problem with this approach is that systemd executes a binary (systemctl), which communicates with systemd just to queue a new job in systemd. Sounds as if there should be a way which is a bit more direct ... Thx for any feedback. Best regards Marko Hoyer ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] crash after commit core: make setting the shutdown watchdog configuration via dbus work
hi: systemd crashes after that commit with gdb --args ./systemd Failed to create root cgroup hierarchy: Permission denied Failed to allocate manager object: Permission denied Program received signal SIGSEGV, Segmentation fault. 0x55574ec4 in main (argc=1, argv=0x7fffdac8) at src/core/main.c:1832 1832arg_shutdown_watchdog = m-shutdown_watchdog; gdb) p m $3 = (Manager *) 0x0 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] root= ignored
Chris Murphy composed on 2015-01-28 23:51 (UTC-0700): Felix Miata wrote: Chris Murphy composed on 2015-01-27 23:29 (UTC-0700): Felix Miata wrote: Lennart Poettering composed on 2015-01-28 02:03 (UTC+0100): Hmm, Fedora doesn't obey root=? That sounds like a bug. I'm not sure what it means, Fedora doesn't obey root=. Since a long time it uses root=UUID= and this has worked for me. All current distros whose bootloaders I've used include a root= in each of their bootloader stanzas. AFAIK, root=UUID= is used in Fedora's Grub2 stanzas. That's true unless LVM is being used, which happens to be the default, in which case it's root=VG/LV. I've used LVM on exactly one HD, since wiped, too many years ago to remember when or which. When Fedora is the source and clone, attempting boot of clone using default initrd produces an emergency shell, unlike openSUSE. I'm unable to reproduce this problem on a BIOS system. What you describe below looks little like the process I described. Old volume is Btrfs, new volumes is Btrfs (new volume UUID), I didn't think any mention of filesystem type would be relevant in describing my process, but all clones used as a Fedora / here have been either EXT3 or EXT4. and I just copy the I wrote clone for a reason. I don't just copy files. I clone (logical, root, autonomous) *partitions*, subsequently modifying only fstab, volume label and UUID before attempting boot from it. files from old to new (I actually used btrfs send receive). I of course had to install a new bootloader with grub2-install, and create The process I wrote was intended to make it clear that no bootloader that may have been on a Fedora / partition was used for booting a Fedora clone as adjusted to its new location. It's a process that was relatively simple and reliable until humanly memorable cmdline root= parameters what worked formerly began being disregarded by Fedora's boot process in apparent favor of incorporating a root filesystem UUID subject to change during backup/restore process in its initrd. Somehow dracut is baking in the EFI System partition UUID into the initramfs, instead of honoring the correct one that I put into fstab. As a result boot fails and will always fail until I rebuild the initramfs. So I'd definitely consider that a bug. https://bugzilla.redhat.com/show_bug.cgi?id=1187007 Noted, commented, CC'd. -- The wise are known for their understanding, and pleasant words are persuasive. Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] timesyncd: Make saving clock to disk on NTP fix optional
Hi.
Since it has bothered me that systemd-timesyncd unconditionally writes
the current clock value to disk everytime it got an NTP fix i filed a
BUG report (https://bugs.freedesktop.org/show_bug.cgi?id=86292).
Zbigniew asked me to send a patch to this mailing list. So here it
is. I also attached it to the BUG report mentioned above.
Philipp
--
Dipl.-Inform. Philipp Reinkemeier
OFFIS e.V.
Escherweg 2, D-26121 Oldenburg, Germany
Phone: +49 441 9722-400
E-Mail: philipp.reinkeme...@offis.de
PGP: 0x2DA75A6F or 0xCCB2AF14
From 8c03d37688a6163bdd0a7a6379b18f8c3c7a501b Mon Sep 17 00:00:00 2001
From: Philipp Reinkemeier philipp.reinkeme...@offis.de
Date: Wed, 28 Jan 2015 14:53:07 +0100
Subject: [PATCH] timesyncd: Make saving clock to disk on NTP fix optional
This introduces a new property SaveClockOnNtpFix in the
timesyncd.conf configuration file. It takes a boolean value.
If we get an NTP, the clock is saved to disk depending on that
value.
Previously, the clock was saved on every NTP fix. This commit
preserves this default behavior. If SaveClockOnNtpFix is disabled,
then the clock is only saved during shutdown of systemd-timesyncd.
This can be useful if one wants to keep disk accesses at a minimum
(save power, prevents disk spin-ups to improve their lifetime).
---
man/timesyncd.conf.xml | 14 ++
src/timesync/timesyncd-gperf.gperf | 7 ---
src/timesync/timesyncd-manager.c | 5 -
src/timesync/timesyncd-manager.h | 2 ++
src/timesync/timesyncd.conf.in | 1 +
5 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/man/timesyncd.conf.xml b/man/timesyncd.conf.xml
index 1a56c2c..9a93737 100644
--- a/man/timesyncd.conf.xml
+++ b/man/timesyncd.conf.xml
@@ -105,6 +105,20 @@
used instead./para/listitem
/varlistentry
+varlistentry
+termvarnameSaveClockOnNtpFix=/varname/term
+listitemparaTakes a boolean value. If enabled
+(the default), then everytime an NTP fix is acquired,
+the new clock value is written to disk (the file
+filename/var/lib/systemd/clock/filename is touched).
+The date of that file is used upon startup of
+commandsystemd-timesyncd/command to initialize
+the system clock (useful for systems that lack an RTC).
+If not enabled, then the clock value is only written
+to disk upon shutdown of
+commandsystemd-timesyncd/command./para/listitem
+/varlistentry
+
/variablelist
/refsect1
diff --git a/src/timesync/timesyncd-gperf.gperf b/src/timesync/timesyncd-gperf.gperf
index 29a2cfe..03dc828 100644
--- a/src/timesync/timesyncd-gperf.gperf
+++ b/src/timesync/timesyncd-gperf.gperf
@@ -14,6 +14,7 @@ struct ConfigPerfItem;
%struct-type
%includes
%%
-Time.NTP, config_parse_servers, SERVER_SYSTEM, 0
-Time.Servers, config_parse_servers, SERVER_SYSTEM, 0
-Time.FallbackNTP, config_parse_servers, SERVER_FALLBACK, 0
+Time.NTP, config_parse_servers, SERVER_SYSTEM, 0
+Time.Servers, config_parse_servers, SERVER_SYSTEM, 0
+Time.FallbackNTP, config_parse_servers, SERVER_FALLBACK, 0
+Time.SaveClockOnNtpFix, config_parse_bool,0, offsetof(Manager, save_clock_on_ntp_fix)
diff --git a/src/timesync/timesyncd-manager.c b/src/timesync/timesyncd-manager.c
index bc35662..cf05a20 100644
--- a/src/timesync/timesyncd-manager.c
+++ b/src/timesync/timesyncd-manager.c
@@ -378,7 +378,8 @@ static int manager_adjust_clock(Manager *m, double offset, int leap_sec) {
if (r 0)
return r;
-touch(/var/lib/systemd/clock);
+if (m-save_clock_on_ntp_fix)
+touch(/var/lib/systemd/clock);
m-drift_ppm = tmx.freq / 65536;
@@ -1118,6 +1119,8 @@ int manager_new(Manager **ret) {
RATELIMIT_INIT(m-ratelimit, RATELIMIT_INTERVAL_USEC, RATELIMIT_BURST);
+m-save_clock_on_ntp_fix = true;
+
r = manager_parse_server_string(m, SERVER_FALLBACK, NTP_SERVERS);
if (r 0)
return r;
diff --git a/src/timesync/timesyncd-manager.h b/src/timesync/timesyncd-manager.h
index c7efdc5..4cc1a31 100644
--- a/src/timesync/timesyncd-manager.h
+++ b/src/timesync/timesyncd-manager.h
@@ -40,6 +40,8 @@ struct Manager {
LIST_HEAD(ServerName, link_servers);
LIST_HEAD(ServerName, fallback_servers);
+bool save_clock_on_ntp_fix;
+
RateLimit ratelimit;
bool exhausted_servers;
diff --git a/src/timesync/timesyncd.conf.in b/src/timesync/timesyncd.conf.in
index fc3c6c4..0e5d5fc 100644
--- a/src/timesync/timesyncd.conf.in
+++
Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd
Hi Lennart, I'll do some testing today with BindCarrier= and check if it covers all usecases. Regarding the networkctl update to show the UFD groups in a user friendly fashion, what about that ? Let's take a simple example. If I have a configuration file like below: #cat sw0p10.network [Match] Name=sw0p10 [Network] BindCarrier=sw0p49 sw0p51 sw0p5 sw0p7 In the background, networkd will create monitor an UFD group with ID, let's say 1. Then networkctl would give following output to the user: # networkctl ufd ● UFD Group: 1 # and # networkctl ufd 1 ● UFD Group: 1 State: configured Uplinks: → 12: sw0p10 Downlinks: → 51: sw0p49 → 53: sw0p51 → 7: sw0p5 → 9: sw0p7 # Of course networkd ufd -a would also work. How does it sound ? Best Regards, Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Wednesday, January 28, 2015 6:59 PM To: Rauta, Alin Cc: Andrei Borzenkov; Tom Gundersen; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd On Wed, 28.01.15 17:18, Rauta, Alin (alin.ra...@intel.com) wrote: Hi Lennart, Tom, We should also be able to add virtual devices to UFD groups, like Andrei mentioned in his email. In this case, do you think BindCarrier= and Tag= in .network files would still work ? Again, my latest proposal does away with the Tag= concept entirely. I am not sure what a virtual device is supposed to be. If it has a linux network interface, then it has a name and all I am saying is that with a simple Concept like BindCarrier= taking a list of globs of interface names I think that you can cover what you need. If we think about LAG (link aggregation) and if I am right, it's mapped to the kernel as a virtual device and contains multiple links. This way, it makes sense to have groups of links as netdevs. The only difference in case of UFD is that is not mapped to the kernel, but it's mapped inside networkd. I networkd, there are: 1) network interfaces created automatically by some kernel driver, because the hardware was discovered. To these we apply one .link file via udev, plus maybe a .network file, when we actually use it to connect to a network. 2) network interfaces that have to be created explicitly, via some kernel API. These are configured via .netdev files. From the point on they are created by networkd they are like any other network interface, i.e. exactly like the ones described in #1, i.e. on top of the .netdev file a .link file is then applied, and finally maybe a .network file. Now, all I am saying is that i think it would suffice if the .network files for the downlinks for contain BindCarrier= globs referring to their respective uplinks. And that should already suffice. TO make this work nciely all that is necessary then is that the network interfaces get pretty names, either right from the .netdev, or from the .link files. Another thing is that maybe later on we want to provide some properties for an UFD group, maybe to change to way we consider an uplink as failing. This would be easy if we have a netdev for the UFD group. Also, defining a netdev, we don't lose the identity of the feature nor we mask it. But this could also be another setting of the .network file of that is applied to the downlink. Example: in the .network file of the downlink we could have: BindCarrier=foo[1-7] BindCarrierMode=need-all Or so, which could mean: bring the downlink up only if there's a carrier on all network interfaces that match the glob foo[1-7]. The default for BindCarrierMode= would be need-any or so, which would mean, that the carrier is propagated when at least one of the network interfaces has a carrier. Wouldn't that cover your usecase? 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] Added UFD (Uplink failure detection) support to networkd
On Wed, Jan 28, 2015 at 3:40 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 28.01.15 10:13, Rauta, Alin (alin.ra...@intel.com) wrote: Lennart, on a switch I should be able to configure more than one UFD group. What precisely does this mean? WOuld those groups be orthogonal? I really would like to avoid introdcuing the tags concept for now. Would a solution where you give the uplinks appropriate names (like uplink0, uplinkXYZ, uplink_waldo and so on) suffice, when you can then refer to them in a .network file you apply to the downlinks as BindCarrier=uplink*? This has interesting corner case. Let's say you have one interface uplink0 and one interface downstream0 that has BindCarrier=uplink*. So we bind downstream0 to uplink0 on startup. Later (online) we add second interface uplink1 and downstream1 which also has BindCarrier=uplink*. But now this one is suddenly bound to *two* interfaces instead of one; so they both behave differently. Could also happen if interface fails on startup and is hotswaped or otherwise repaired replaced later. As such concept of uplink group abstracts away direct connection between down- and upstream. Each operation would then implicitly iterate over interfaces in group; when new interface is added, it provides natural place to adjust group monitoring (like set watch for it etc). Not so easy with your proposal. BindCarrier= would take a list of interface names, possibly with globs. If you want to up and down a link foo if at least one of the links bar, quux, piep, miau1, miau2 are up, you could write this as BindCarrier=bar quux piep miau*. What would introducing the tag concept give you beyond this very simple schreme described above? Lennart -- Lennart Poettering, Red Hat ___ 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] fs: switch to d_splice_alias()
On 01/29/2015 05:42 AM, Bryan Hundven wrote: During the 3.19 merge window, two commits in Linus's tree: b5ae6b15bd73e35b129408755a0804287a87e041 = merge d_materialise_unique() into d_splice_alias() = and 41d28bca2da4bd75a8915c1ccf2cacf7f4a2e531 = switch d_materialise_unique() users to d_splice_alias() = ...requires us to switch to d_splice_alias(). Signed-off-by: Bryan Hundven bryanhund...@gmail.com Thanks! That's true, and I have the same patch locally as a fix-up the kernel submission, after all, we did submit it as 3.19 material. I'll wait for 3.19 to be released, and then apply your patch. There's also another detail which uses a new API for kvec iterators. I'll add that too. Thanks, Daniel --- fs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs.c b/fs.c index 7fc5ede..33aff4b 100644 --- a/fs.c +++ b/fs.c @@ -175,7 +175,7 @@ static struct dentry *fs_dir_iop_lookup(struct inode *dir, if (IS_ERR(inode)) dnew = ERR_CAST(inode); else - dnew = d_materialise_unique(dentry, inode); + dnew = d_splice_alias(inode, dentry); kdbus_node_release(node); } ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd
Hi Andrei, Please find my answers below: How do you distinguish between groups? By interface list in BindCarrier statement? Yes, first list of BindCarriers will represent the uplinks for group ID 1; Second different list of BindCarriers wiil represent the uplinks for group ID 2. And one more thing to mention: you should not have a link that is part of 2 UFD groups. How can it be in unconfigured state? This looks redundant and confusing in this case. Either there is BindCarrier and group, or there is no BindCarrier and hence no group. It can be only in configured state. That's right. It tells the user the group is configured, because maybe someone list the groups in the system and is wondering: is this group configured ? However, I don't mind if we take the line out. Best Regards, Alin -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Thursday, January 29, 2015 12:14 PM To: Rauta, Alin Cc: Lennart Poettering; Tom Gundersen; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd On Thu, Jan 29, 2015 at 2:20 PM, Rauta, Alin alin.ra...@intel.com wrote: Hi Lennart, I'll do some testing today with BindCarrier= and check if it covers all usecases. Regarding the networkctl update to show the UFD groups in a user friendly fashion, what about that ? Let's take a simple example. If I have a configuration file like below: #cat sw0p10.network [Match] Name=sw0p10 [Network] BindCarrier=sw0p49 sw0p51 sw0p5 sw0p7 In the background, networkd will create monitor an UFD group with ID, let's say 1. Then networkctl would give following output to the user: # networkctl ufd ● UFD Group: 1 How do you distinguish between groups? By interface list in BindCarrier statement? # and # networkctl ufd 1 ● UFD Group: 1 State: configured How can it be in unconfigured state? This looks redundant and confusing in this case. Either there is BindCarrier and group, or there is no BindCarrier and hence no group. Uplinks: → 12: sw0p10 Downlinks: → 51: sw0p49 → 53: sw0p51 → 7: sw0p5 → 9: sw0p7 # Of course networkd ufd -a would also work. How does it sound ? Best Regards, Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Wednesday, January 28, 2015 6:59 PM To: Rauta, Alin Cc: Andrei Borzenkov; Tom Gundersen; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd On Wed, 28.01.15 17:18, Rauta, Alin (alin.ra...@intel.com) wrote: Hi Lennart, Tom, We should also be able to add virtual devices to UFD groups, like Andrei mentioned in his email. In this case, do you think BindCarrier= and Tag= in .network files would still work ? Again, my latest proposal does away with the Tag= concept entirely. I am not sure what a virtual device is supposed to be. If it has a linux network interface, then it has a name and all I am saying is that with a simple Concept like BindCarrier= taking a list of globs of interface names I think that you can cover what you need. If we think about LAG (link aggregation) and if I am right, it's mapped to the kernel as a virtual device and contains multiple links. This way, it makes sense to have groups of links as netdevs. The only difference in case of UFD is that is not mapped to the kernel, but it's mapped inside networkd. I networkd, there are: 1) network interfaces created automatically by some kernel driver, because the hardware was discovered. To these we apply one .link file via udev, plus maybe a .network file, when we actually use it to connect to a network. 2) network interfaces that have to be created explicitly, via some kernel API. These are configured via .netdev files. From the point on they are created by networkd they are like any other network interface, i.e. exactly like the ones described in #1, i.e. on top of the .netdev file a .link file is then applied, and finally maybe a .network file. Now, all I am saying is that i think it would suffice if the .network files for the downlinks for contain BindCarrier= globs referring to their respective uplinks. And that should already suffice. TO make this work nciely all that is necessary then is that the network interfaces get pretty names, either right from the .netdev, or from the .link files. Another thing is that maybe later on we want to provide some properties for an UFD group, maybe to change to way we consider an uplink as failing. This would be easy if we have a netdev for the UFD group. Also, defining a netdev, we don't lose the identity of the feature nor we mask it. But this could also be another setting of the .network file of that is applied to the downlink. Example: in the .network file of
Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd
On Thu, Jan 29, 2015 at 2:20 PM, Rauta, Alin alin.ra...@intel.com wrote: Hi Lennart, I'll do some testing today with BindCarrier= and check if it covers all usecases. Regarding the networkctl update to show the UFD groups in a user friendly fashion, what about that ? Let's take a simple example. If I have a configuration file like below: #cat sw0p10.network [Match] Name=sw0p10 [Network] BindCarrier=sw0p49 sw0p51 sw0p5 sw0p7 In the background, networkd will create monitor an UFD group with ID, let's say 1. Then networkctl would give following output to the user: # networkctl ufd ● UFD Group: 1 How do you distinguish between groups? By interface list in BindCarrier statement? # and # networkctl ufd 1 ● UFD Group: 1 State: configured How can it be in unconfigured state? This looks redundant and confusing in this case. Either there is BindCarrier and group, or there is no BindCarrier and hence no group. Uplinks: → 12: sw0p10 Downlinks: → 51: sw0p49 → 53: sw0p51 → 7: sw0p5 → 9: sw0p7 # Of course networkd ufd -a would also work. How does it sound ? Best Regards, Alin -Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Wednesday, January 28, 2015 6:59 PM To: Rauta, Alin Cc: Andrei Borzenkov; Tom Gundersen; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd On Wed, 28.01.15 17:18, Rauta, Alin (alin.ra...@intel.com) wrote: Hi Lennart, Tom, We should also be able to add virtual devices to UFD groups, like Andrei mentioned in his email. In this case, do you think BindCarrier= and Tag= in .network files would still work ? Again, my latest proposal does away with the Tag= concept entirely. I am not sure what a virtual device is supposed to be. If it has a linux network interface, then it has a name and all I am saying is that with a simple Concept like BindCarrier= taking a list of globs of interface names I think that you can cover what you need. If we think about LAG (link aggregation) and if I am right, it's mapped to the kernel as a virtual device and contains multiple links. This way, it makes sense to have groups of links as netdevs. The only difference in case of UFD is that is not mapped to the kernel, but it's mapped inside networkd. I networkd, there are: 1) network interfaces created automatically by some kernel driver, because the hardware was discovered. To these we apply one .link file via udev, plus maybe a .network file, when we actually use it to connect to a network. 2) network interfaces that have to be created explicitly, via some kernel API. These are configured via .netdev files. From the point on they are created by networkd they are like any other network interface, i.e. exactly like the ones described in #1, i.e. on top of the .netdev file a .link file is then applied, and finally maybe a .network file. Now, all I am saying is that i think it would suffice if the .network files for the downlinks for contain BindCarrier= globs referring to their respective uplinks. And that should already suffice. TO make this work nciely all that is necessary then is that the network interfaces get pretty names, either right from the .netdev, or from the .link files. Another thing is that maybe later on we want to provide some properties for an UFD group, maybe to change to way we consider an uplink as failing. This would be easy if we have a netdev for the UFD group. Also, defining a netdev, we don't lose the identity of the feature nor we mask it. But this could also be another setting of the .network file of that is applied to the downlink. Example: in the .network file of the downlink we could have: BindCarrier=foo[1-7] BindCarrierMode=need-all Or so, which could mean: bring the downlink up only if there's a carrier on all network interfaces that match the glob foo[1-7]. The default for BindCarrierMode= would be need-any or so, which would mean, that the carrier is propagated when at least one of the network interfaces has a carrier. Wouldn't that cover your usecase? 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 11/12] Add man page and references to it.
Le 28/01/2015 16:06, Zbigniew Jędrzejewski-Szmek a écrit : On Wed, Jan 28, 2015 at 02:24:55PM +0100, Didier Roche wrote: From 6b13d8fb248bf4176f1ad7e1d4736683462bf196 Mon Sep 17 00:00:00 2001 From: Didier Roche didro...@ubuntu.com Date: Mon, 26 Jan 2015 17:34:59 +0100 Subject: [PATCH 11/12] Add man page and references to it. --- /dev/null +++ b/man/systemd-fsckd.service.xml @@ -0,0 +1,170 @@ +?xml version=1.0? +!--*-nxml-*-- +!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd; +!-- + This file is part of systemd. + + Copyright 2015 Canonical + + 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. + + systemd is distributed in the hope that it will be useful, but + WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + Lesser General Public License for more details. + + You should have received a copy of the GNU Lesser General Public License + along with systemd; If not, see http://www.gnu.org/licenses/. +-- +refentry id=systemd-fsckd.service xmlns:xi=http://www.w3.org/2001/XInclude; Please use 2ch indentation for new man pages. Converted to 2 characters for indentation. +progress, and communicating some consolidated data +to console and plymouth (if running). It also handles +possible check cancellations./para +parafilenamesystemd-fsck-root.service/filename or +filenamesystemd-fsck@.service/filename will get the +progress from fsck and send their individual progress to +filenamesystemd-fsckd/filename, through socket activation +by filenamesystemd-fsckd.socket/filename./para I think we don't need this kind of detail in the man page. It might change anyway. Removed then! +paraProgress update, sent as a plymouth update message: + literalfsckd:lt;num_devicesgt;:lt;progressgt;:lt;stringgt;/literal + variablelist + varlistentry + termliterallt;num_devicesgt;/literal/term + listitemparathe current number of devices + being checked (int)/para/listitem + /varlistentry + varlistentry + termliterallt;progressgt;/literal/term + listitemparathe current minimum percentage of + all devices being checking (float, from 0 to 100)/para/listitem + /varlistentry + varlistentry + termliterallt;stringgt;/literal/term + listitemparaa translated message ready to be displayed + by the plymouth theme displaying the data above. It can be overriden + by themes supporting i18n./para/listitem + /varlistentry + /variablelist +/para + +paraCancel message, sent as a traditional plymouth message: + literalfsckd-cancel-msg:lt;stringgt;/literal + variablelist + varlistentry + termliterallt;stringsgt;/literal/term + listitemparaa translated string ready to be displayed + by the plymouth theme indicating that c or C can be used to cancel + current checks. It can be overriden (matching only + literalfsckd-cancel-msg/literal prefix) + by themes supporting i18n./para/listitem + /varlistentry + /variablelist +/para This is very detailed too, but it is OK, we don't really have a good place for this kind of documentation. Yeah, some API for plymouth theme authors. I didn't find a better place (or the systemd wiki?) Thanks again for the detailed rereading :) Cheers, Didier ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] What's the correct way to configure encrypted volume and mount point?
I am looking for some advice about configuring encrypted volumes with systemd that I want to open on demand (noauto). I can add entries into /etc/crypttab and /etc/fstab for the device, for example # name device password options dataUUID=deadbeef nonenoauto and # file systemdirtypeoptionsdumppass /dev/mapper/data /home/myuser/data ext4 noauto 0 0 But the device doesn't unlock when I do $ mount /home/myuser/data mount: special device /dev/mapper/keyring does not exist But it does if I use $ systemctl start home-myuser-data.mount I'm guessing that mount doesn't effect systemd and, therefore, the dependency isn't actioned. But the docs for systemd.mount state that configuring mount points through |/etc/fstab| is the preferred approach so I'm wondering if there's something I missed from my crypttab or fstab entries? Thanks. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 01/12] fsckd daemon for inter-fsckd communication
Le 28/01/2015 15:37, Zbigniew Jędrzejewski-Szmek a écrit :
On Wed, Jan 28, 2015 at 02:20:40PM +0100, Didier Roche wrote:
Hey Zbigniew,
Thanks for the quick feedbacks! Integrated your changes in the incoming
patches. Just answered to some comments here:
From d0f49b4e0994b9a1dd2738da18c5a2a6708b444f Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Mon, 26 Jan 2015 15:35:50 +0100
Subject: [PATCH 01/12] fsckd daemon for inter-fsckd communication
+fsckd_fd = socket(AF_UNIX, SOCK_STREAM | SOCK_NONBLOCK, 0);
+if (fsckd_fd 0) {
+log_warning_errno(errno, Cannot open fsckd socket, we won't report
fsck progress: %m);
+return -errno;
+}
+if (connect(fsckd_fd, sa.sa, offsetof(struct sockaddr_un, sun_path) +
strlen(sa.un.sun_path)) 0) {
+log_warning_errno(errno, Cannot connect to fsckd socket, we won't
report fsck progress: %m);
+return -errno;
+}
f = fdopen(fd, r);
if (!f) {
-safe_close(fd);
+log_warning_errno(errno, Cannot connect to fsck, we won't report
fsck progress: %m);
return -errno;
}
There's a double close now, since both f and fsckd_fd refer to the same fd.
Actually no, fd is the fd from the pipe between fsck - systemd-fsck
and fsckd_fd is the fd from the socket between systemd-fsck -
systemd-fsckd.
Or am I missing something?
\ No newline at end of file
diff --git a/src/fsckd/fsckd.c b/src/fsckd/fsckd.c
new file mode 100644
index 000..3059c68
--- /dev/null
+++ b/src/fsckd/fsckd.c
@@ -0,0 +1,295 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+}
+
+static int handle_requests(int socket_fd) {
+Clients *first = NULL;
+usec_t last_activity = 0;
+int numdevices = 0, clear = 0;
+double percent = 100;
+_cleanup_fclose_ FILE *console = NULL;
NULL not necessary (and you don't have it in similar circumstances above ;))
So, after the discussion on the mailing list and to be more future
proof, I went to recheck, but I'm afraid that I didn't find any place
where I have some _cleanup_* without initializing to NULL? Did I get it
wrong?
+log_error_errno(errno, Socket read error,
disconnecting fd %d: %m, current-fd);
+current-fd = 0;
0 is a valid file descriptor number. You must use -1. This also means that some
initialization
to -1 is missing.
The clients are always initialized when we get a valid fd (current-fd =
new_client_fd;), so no need to initiliaze to -1, I'm using now -1 though
to invalidate the fd.
+static int create_socket(void) {
Can you base this on make_socket_fd() instead?
Oh nice, didn't find it when I looked for a generic utility. Using it :)
Thanks again for this review!
Cheers,
Didier
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 01/12] fsckd daemon for inter-fsckd communication
Le 28/01/2015 21:16, Lennart Poettering a écrit :
Thanks for your feedbacks! Changes integrated, some remaining questions
though:
On Wed, 28.01.15 14:20, Didier Roche (didier.ro...@canonical.com) wrote:
+last_activity = now(CLOCK_MONOTONIC);
+
+for (;;) {
+int new_client_fd = 0;
+Clients *current;
+_cleanup_free_ char *console_message = NULL;
+double current_percent = 100;
+int current_numdevices = 0, m = 0;
+usec_t t;
+
+/* Initialize and list new clients */
+new_client_fd = accept4(socket_fd, NULL, NULL, SOCK_NONBLOCK);
+if (new_client_fd 0) {
+log_debug(new fsck client connected to fd: %d,
new_client_fd);
+current = alloca0(sizeof(Clients));
It's not OK to invoke alloca() in loops. This cannot work. Please use
normal heap memoy for this.
Oh, good to know, replaced with a regular malloc. I didn't handle the
freeing of Clients as they are destructed on program close, should I
handle this (and thus looping over and freeing the new char* - which
part of the struct)?
+current = NULL;
+}
+
+LIST_FOREACH(clients, current, first) {
+ FsckProgress fsck_data;
+ int rc = 0;
+
+if (current-fd 0)
+rc = recv(current-fd, fsck_data,
sizeof(FsckProgress), 0);
+
+if ((current-fd != 0) (rc == 0)) {
+log_debug(fsck client connected to
fd %d disconnected, current-fd);
Please print propery exit codes.
That was my bad, it's r rather then rc, so not a return code but number
of bytes read, or I missing something?
+
+/* write to console */
+fprintf(console, \r%s\r%n, console_message, m);
+fflush(console);
Hmm, what's the reason for first writing this to an alocated buffer,
and then to the console? You can write this directly to the console, no?
Once I'm adding plymouth connection in 03/12, I'm reusing the same
console_message (I can rename it if necessary).
Thanks for the review!
Cheers,
Didier
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 06/12] Support cancellation of fsck in progress
Le 28/01/2015 15:53, Zbigniew Jędrzejewski-Szmek a écrit : On Wed, Jan 28, 2015 at 02:22:54PM +0100, Didier Roche wrote: From 104cf82ba28941e907f277a713f834ceb3d909f0 Mon Sep 17 00:00:00 2001 From: Didier Roche didro...@ubuntu.com Date: Mon, 26 Jan 2015 16:40:52 +0100 Subject: [PATCH 06/12] Support cancellation of fsck in progress Grab in fsckd plymouth watch key for C or c, and propagate this cancel request to systemd-fsck which will terminate fsck. Could we bind to ^c or if this is not possible, three c's in three seconds instead? I'm worried that before you could press anything to little effect in plymouth, and now a single key will have significant consequences. I tried to have a look at libplymouth, and if I'm correct, it's not possible to listen and get events for compose keys, so no way to get something like Control+C. As Dimitri told, it's been quite some years we are doing that in ubuntu, and that's the reason why we show a message to ensure the user is aware about that key (and that's why this patch is doing). Is it good for you this way? Cheers, Didier ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 04/12] Add some plymouth functionality to connect and send, messages
Le 28/01/2015 21:22, Lennart Poettering a écrit : On Wed, 28.01.15 14:22, Didier Roche (didro...@ubuntu.com) wrote: # -- +have_plymouth=no +AC_ARG_ENABLE(plymouth, AS_HELP_STRING([--disable-plymouth], [disable plymouth integration])) +if test x$enable_plymouth != xno; then +PKG_CHECK_MODULES([PLYMOUTH], [ply-boot-client = 0.8.0], +[AC_DEFINE(HAVE_PLYMOUTH, 1, [Define if plymouth is available]) have_plymouth=yes], have_plymouth=no) +if test x$have_plymouth = xno -a x$enable_plymouth = xyes; then +AC_MSG_ERROR([*** plymouth integration requested but libraries not found]) +fi +fi +AM_CONDITIONAL(HAVE_PLYMOUTH, [test $have_plymouth = yes]) Hmm, I am bit concerned about adding this dependency. So far we managed to talk to plymouth without using its library, and I am really not sure we should start doing so now. So far the messages to send were so simply that it really wasn't worth the effort to use the full library. This is doable for the first part, similar to what src/tty-ask-password-agent/tty-ask-password-agent.c is doing (using the socket directly to send update and message to it). I'm quite unsure watch and get key events part as looking at libplymouth code, this seems quite more complex as a protocol to achieve. If you feel that needs to be done anyway, I can look deeper at this if you really feel we should reimplement libplymouth protocol rathen than having an optional dep on it. Didier ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 04/12] Add some plymouth functionality to connect and send, messages
Le 28/01/2015 15:44, Zbigniew Jędrzejewski-Szmek a écrit :
On Wed, Jan 28, 2015 at 02:22:04PM +0100, Didier Roche wrote:
From 7afe9270e3210668053089caaff8a1dd790a48f5 Mon Sep 17 00:00:00 2001
From: Didier Roche didro...@ubuntu.com
Date: Mon, 26 Jan 2015 17:07:32 +0100
Subject: [PATCH 04/12] Add some plymouth functionality to connect and send
messages
diff --git a/src/shared/plymouth.c b/src/shared/plymouth.c
index c4865dd..f7155c4 100644
--- a/src/shared/plymouth.c
+++ b/src/shared/plymouth.c
@@ -19,13 +19,96 @@
along with systemd; If not, see http://www.gnu.org/licenses/.
***/
+#ifdef HAVE_PLYMOUTH
+#include ply-boot-client.h
+#endif
+
#include stdbool.h
#include stdio.h
#include stdlib.h
#include unistd.h
+#include log.h
#include plymouth.h
+#ifdef HAVE_PLYMOUTH
+void plymouth_disconnected (void *user_data, ply_boot_client_t *client);
+void plymouth_update_failed(void *user_data, ply_boot_client_t *client);
+
+static ply_boot_client_t *plymouth_client = NULL;
+static ply_event_loop_t *plymouth_event_loop = NULL;
+#endif
+
bool plymouth_running(void) {
return access(/run/plymouth/pid, F_OK) = 0;
}
+
+#ifdef HAVE_PLYMOUTH
+bool plymouth_connect(void) {
Is there a particular reason why this cannot return a normal int code?
No reason, I changed to 0 for connected, -1 for can't connect.
Other changes done, thanks!
Cheers,
Didier
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 10/12] Add fsckd service and socket, retarget systemd-fsck
Le 28/01/2015 16:00, Zbigniew Jędrzejewski-Szmek a écrit : On Wed, Jan 28, 2015 at 02:24:32PM +0100, Didier Roche wrote: From 000f1b6ff4f5f80a2a13309590d255de6d6526ec Mon Sep 17 00:00:00 2001 From: Didier Roche didro...@ubuntu.com Date: Mon, 26 Jan 2015 17:30:00 +0100 Subject: [PATCH 10/12] Add fsckd service and socket, retarget systemd-fsck systemd-fsckd can be socket-activated by systemd-fsck process. Reflect that in the different unit files. --- Makefile.am| 3 +++ units/.gitignore | 1 + units/systemd-fsck-root.service.in | 4 +++- units/systemd-f...@.service.in | 5 +++-- units/systemd-fsckd.service.in | 16 units/systemd-fsckd.socket | 15 +++ 6 files changed, 41 insertions(+), 3 deletions(-) create mode 100644 units/systemd-fsckd.service.in create mode 100644 units/systemd-fsckd.socket diff --git a/Makefile.am b/Makefile.am index a9d61f1..1eeba4f 100644 --- a/Makefile.am +++ b/Makefile.am @@ -492,6 +492,7 @@ dist_systemunit_DATA = \ units/slices.target \ units/system.slice \ units/x-.slice \ + units/systemd-fsckd.socket \ units/systemd-initctl.socket \ units/systemd-shutdownd.socket \ units/syslog.socket \ @@ -543,6 +544,7 @@ nodist_systemunit_DATA = \ units/systemd-kexec.service \ units/systemd-fsck@.service \ units/systemd-fsck-root.service \ + units/systemd-fsckd.service \ units/systemd-machine-id-commit.service \ units/systemd-udevd.service \ units/systemd-udev-trigger.service \ @@ -596,6 +598,7 @@ EXTRA_DIST += \ units/user/systemd-exit.service.in \ units/systemd-f...@.service.in \ units/systemd-fsck-root.service.in \ + units/systemd-fsckd.service.in \ units/systemd-machine-id-commit.service.in \ units/u...@.service.m4.in \ units/debug-shell.service.in \ diff --git a/units/.gitignore b/units/.gitignore index 6fdb629..26ae965 100644 --- a/units/.gitignore +++ b/units/.gitignore @@ -28,6 +28,7 @@ /systemd-firstboot.service /systemd-fsck-root.service /systemd-fsck@.service +/systemd-fsckd.service /systemd-machine-id-commit.service /systemd-halt.service /systemd-hibernate.service diff --git a/units/systemd-fsck-root.service.in b/units/systemd-fsck-root.service.in index 6d76578..bd3bdbc 100644 --- a/units/systemd-fsck-root.service.in +++ b/units/systemd-fsck-root.service.in @@ -9,12 +9,14 @@ Description=File System Check on Root Device Documentation=man:systemd-fsck-root.service(8) DefaultDependencies=no +Wants=systemd-fsckd.socket Before=local-fs.target shutdown.target +After=systemd-fsckd.socket ConditionPathIsReadWrite=!/ [Service] Type=oneshot RemainAfterExit=yes ExecStart=@rootlibexecdir@/systemd-fsck -StandardOutput=journal+console +StandardOutput=journal Just remove the line completely to use the admin default (here and in other cases...). TimeoutSec=0 diff --git a/units/systemd-f...@.service.in b/units/systemd-f...@.service.in index 857e625..3ceb5f2 100644 --- a/units/systemd-f...@.service.in +++ b/units/systemd-f...@.service.in @@ -10,12 +10,13 @@ Description=File System Check on %f Documentation=man:systemd-fsck@.service(8) DefaultDependencies=no BindsTo=%i.device -After=%i.device systemd-fsck-root.service local-fs-pre.target +Wants=systemd-fsckd.socket +After=%i.device systemd-fsck-root.service local-fs-pre.target systemd-fsckd.socket Before=shutdown.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=@rootlibexecdir@/systemd-fsck %f -StandardOutput=journal+console +StandardOutput=journal TimeoutSec=0 diff --git a/units/systemd-fsckd.service.in b/units/systemd-fsckd.service.in new file mode 100644 index 000..27c325f --- /dev/null +++ b/units/systemd-fsckd.service.in @@ -0,0 +1,16 @@ +# 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=File System Check Daemon to report status +DefaultDependencies=no +Requires=systemd-fsckd.socket +Before=shutdown.target + +[Service] +ExecStart=@rootlibexecdir@/systemd-fsckd +StandardOutput=journal+console diff --git a/units/systemd-fsckd.socket b/units/systemd-fsckd.socket new file mode 100644 index 000..96a034a --- /dev/null +++ b/units/systemd-fsckd.socket @@ -0,0 +1,15 @@ +# 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=fsck to fsckd communication Socket
Re: [systemd-devel] [PATCH 12/12] Add mock fsck process
Le 28/01/2015 17:13, Martin Pitt a écrit :
Zbigniew Jędrzejewski-Szmek [2015-01-28 16:08 +0100]:
+#!/bin/bash
I think you can change this to /bin/sh, I don't see any bashisms.
+declare -a maxpass=(30 5 2 30 60)
I do :-) POSIX shell doesn't have arrays AFAIK, and declare -a
definitively doesn't work in e. g. dash.
+for pass in {1..5}; do
+maxprogress=${maxpass[$((pass-1))]}
That said, if using POSIX shell is a concern (probably not for this
little test dummy), this could certainly be rewritten to something
like
pass=0
for maxprogress in 30 5 2 30 60; do
pass=$((pass+1))
which isn't really more complicated and avoids arrays.
Yeah, there are some bashims. If getting POSIX shell is important for
the mock, I'm happy to do the necessary changes.
Didier
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd
What if we don't use the * for now and document BindCarrier accordingly to be a list of port names and no wildcard ? Then, if it's the case we can add such * support for BindCarrier and think about all those corner cases ? /Alin -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Thursday, January 29, 2015 12:20 PM To: Lennart Poettering Cc: Rauta, Alin; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd On Wed, Jan 28, 2015 at 3:40 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 28.01.15 10:13, Rauta, Alin (alin.ra...@intel.com) wrote: Lennart, on a switch I should be able to configure more than one UFD group. What precisely does this mean? WOuld those groups be orthogonal? I really would like to avoid introdcuing the tags concept for now. Would a solution where you give the uplinks appropriate names (like uplink0, uplinkXYZ, uplink_waldo and so on) suffice, when you can then refer to them in a .network file you apply to the downlinks as BindCarrier=uplink*? This has interesting corner case. Let's say you have one interface uplink0 and one interface downstream0 that has BindCarrier=uplink*. So we bind downstream0 to uplink0 on startup. Later (online) we add second interface uplink1 and downstream1 which also has BindCarrier=uplink*. But now this one is suddenly bound to *two* interfaces instead of one; so they both behave differently. Could also happen if interface fails on startup and is hotswaped or otherwise repaired replaced later. As such concept of uplink group abstracts away direct connection between down- and upstream. Each operation would then implicitly iterate over interfaces in group; when new interface is added, it provides natural place to adjust group monitoring (like set watch for it etc). Not so easy with your proposal. BindCarrier= would take a list of interface names, possibly with globs. If you want to up and down a link foo if at least one of the links bar, quux, piep, miau1, miau2 are up, you could write this as BindCarrier=bar quux piep miau*. What would introducing the tag concept give you beyond this very simple schreme described above? Lennart -- Lennart Poettering, Red Hat ___ 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 v2] libudev: fix symbol version for udev_queue_flush() and udev_queue_get_fd()
On Sat, Aug 30, 2014 at 11:56:30AM +0200, Kay Sievers wrote: On Sat, Aug 30, 2014 at 2:09 AM, Michael Biebl mbi...@gmail.com wrote: Updated patch which the correct version information. Applied. Hm, I think this was an unintentional ABI break. udev_queue_flush @@ LIBUDEV_183 was removed, udev_queue_flush @@ LIBUDEV_215 was added. The linker cannot know that this is the same symbol. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd
В Thu, 29 Jan 2015 15:10:16 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Thu, Jan 29, 2015 at 02:05:10PM +, Rauta, Alin wrote: What if we don't use the * for now and document BindCarrier accordingly to be a list of port names and no wildcard ? Then, if it's the case we can add such * support for BindCarrier and think about all those corner cases ? What about interpreting the wildcard dynimically instead? If eth3 goes down, look at all interfaces which have BindCarrier set, and check with glob if their BindCarrier setting matches eth3, and act accordingly. This means that every time any interface (dis)appears you must go through all existing BindCarrier statements and check whether they apply. This is really ugly. For this reasons I believe uplink group should be first class citizen also internally. And how do you set properties for it? Which of BindCarrierMode statements in different link (or are they network?) files apply if they differ? What if you need to add more properties? What about DownlinkCarrierGroup=1 in upstream interface UplinkCarrierGroup=1 in downstream interface This creates uplink group 1 and binds interfaces to it. Now you only need to care if there is another interface definition that has the same group number. But you still need ability to set group properties (although in practice every switch I have seen is using policy all - anyone can give compelling use case for using any?), so yes, we may need support configuration object for it. But the first step could be default to policy all which does not require any configuration. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for staged startup
Marko Hoyer asks:
I'd like to realize a staged startup with systemd which is mainly about:
- starting up a static tree up to a final service
- the only job of the final service is to kick off the start of an additional
sub tree of units
This kind of startup could be realized simply by adding an additional one
shot service which executes: systemctl start xxx.target
Marko, one target can already be specified as After another. If
B.target is present in one of the appropriate directories and
specifies
After=A.target
and all the services of the final sub-tree are symlinked in a
B.target.wants directory, doesn't the behavior you need result? What
is missing?Of course, some of the units linked in B.target.wants
may already be started by the time A.target completes if they are part
of a earlier target or if they are needed by an earlier unit. To
suppress that behavior, you'd have to edit the individual units.
I don't know of any use case for one unit to start another directly.
Is there one?
-- Alison
--
Alison Chaiken ali...@she-devel.com
650-279-5600
http://{she-devel.com,exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals. -- Don Norman
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Programmatically setting udev properties
Hi, I need some sort of way of assigning udev properties on the fly to a device, but I'm short of ideas how to do this sensibly. A bit more context: The libinput test suite works by setting up uinput devices for each test case, then hooking libinput contexts up to those devices. libinput itself uses some udev properties to adjust internal behaviours. That works for real hardware because the rules are written for that (and we can require a make install) but uinput devices don't have the same hierarchy and thus don't trigger those rules. Plus, requiring an install before running the test suite isn't very nice. So basically what I'd like would be a udev_device_set_property() call or something similar. We're in control of the uinput and the libinput bits, i.e. there are no race conditions to worry about. Because of uinput, the test suite runs as root. One solution would be to drop a custom test rule, reload, create the uinput device, run the test, rm the rule again. Not pretty though, I was hoping there was something nicer. Any ideas? Cheers, Peter ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] BUG: several bugs in core/main.c (v218)
On 01/29/2015 03:16 AM, Zbigniew Jędrzejewski-Szmek wrote: 2. SIGSEGV should be catched by a handler running on a separate stack (SA_ONSTACK) - otherwise it can cause segfault itself, when the first SIGSEGV which triggered the handler is caused by stack overflow. I'd take a patch for this, but in general: the crash handler is nothing that is supposed to recover your system. All it does its close all fds, fork, and coredump in the child while freezing in the parent. That makes sure that all communication with PID 1 is severed (so that clients talking to it don't hang), we get a clean coredump, but the kernel doesn't oops immediately. That's really all there is to it. So far we never ran into stack overflow issues, hence nobody was ever tempted to cover that case too, and set up a separate stack. In particular since doing this without testing it is pointless... --- Actually, when the program is a critical part of the system, than ALL sig handlers should use separate stack (what in fact makes the life easier) - that's because it's completely unpredictable, whether there's enough stack space to execute the handler - i.e. each sig handler can cause segfault when it's executed at the bottom of the stack (where top/bootom is only a matter of naming convention) IIUC, you are saying that we could trigger for example a FPE, and then exhaust all the memory in the signal handler. Nah, we can ignore this possibility. No, I'm saying, that the handler can be invoked when there's not enough space left on the main stack, so it'll do nothing besides causing sagfault. The only effect of SA_NODEFER is that sig mask is not automatically set for a signal which triggered the handler. This means nesting of signals, as the handler can be interrupted and another instance is started for a new signal context. (and sig handlers are not signal-safe with SA_NODEFER, what means that they have to be fully re-entrant) This also means, that there's completely no warranty that the handler won't be interrupted with external signal - mess. Not really. systemd is single-threaded, so a signal could come only from two places: the signal handler could cause a fault, or it could be delivered from another program. The first is unlikely, stack handlers do a tiny amount of work, and the second is OK, because killing PID 1 is only allowed for privileged processes, and if someone can send arbitrary signals to PID 1, they can cause a failure in other ways. Zbyszek Yeah, it's unlikely, but it would be safer to at least check the source of the signal. But that's not really a problem, since the handler is not even re-entrant (f.e. due to dynamic memory allocation performed trough log_ macros - log_full_errno - log_internal - journal-send.c::_printf_() - vasprintf() ) Whatever. To summarise: there are no bugs in core/main.c: 1. Ignoring return value from sigaction is not a problem, because it's almost *unlikely* to fail. In any case, kernel will do the job, so it doesn't even matter whether the handlers are installed or not - everything that can be done in the handler is to just quit anyway. 2. SIGSEGV handler (and others): it's *unlikely* to happen that the handler will be executed at the bottom of the main stack (with insufficient stack space or when the stack is already overflowed) - because stacks are huge, and in case of segfault see point 1. 3. SA_NODEFER is OK, cause it's *unlikely* that external signal gets delivered. Even if the crash() handler will crash (f.e. because it's not re-entrant), what (again) is *unlikely* to happen, see point 1. I've learned a lot, sorry to waste Your time. Regards. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Programmatically setting udev properties
On Fri, Jan 30, 2015 at 08:12:54AM +1000, Peter Hutterer wrote: Hi, I need some sort of way of assigning udev properties on the fly to a device, but I'm short of ideas how to do this sensibly. Because of uinput, the test suite runs as root. One solution would be to drop a custom test rule, reload, create the uinput device, run the test, rm the rule again. Not pretty though, I was hoping there was something nicer. Any ideas? Have you seen umockdev? https://github.com/martinpitt/umockdev/ -- Tomasz Torcz ,,(...) today's high-end is tomorrow's embedded processor.'' xmpp: zdzich...@chrome.pl -- Mitchell Blank on LKML ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] BUG: several bugs in core/main.c (v218)
On Thu, Jan 29, 2015 at 09:54:57PM +0100, tomazzi wrote: To summarise: there are no bugs in core/main.c: 1. Ignoring return value from sigaction is not a problem, because it's almost *unlikely* to fail. In any case, kernel will do the job, so it doesn't even matter whether the handlers are installed or not - everything that can be done in the handler is to just quit anyway. Actually the signal handler does sleep in an infinite loop, to not crash the system. 2. SIGSEGV handler (and others): it's *unlikely* to happen that the handler will be executed at the bottom of the main stack (with insufficient stack space or when the stack is already overflowed) - because stacks are huge, and in case of segfault see point 1. 3. SA_NODEFER is OK, cause it's *unlikely* that external signal gets delivered. Even if the crash() handler will crash (f.e. because it's not re-entrant), what (again) is *unlikely* to happen, see point 1. OK, great to hear that what we have currently should work :) Zbyszek I've learned a lot, sorry to waste Your time. Regards. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd
On Thu, Jan 29, 2015 at 06:49:08PM +0300, Andrei Borzenkov wrote: В Thu, 29 Jan 2015 15:10:16 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Thu, Jan 29, 2015 at 02:05:10PM +, Rauta, Alin wrote: What if we don't use the * for now and document BindCarrier accordingly to be a list of port names and no wildcard ? Then, if it's the case we can add such * support for BindCarrier and think about all those corner cases ? What about interpreting the wildcard dynimically instead? If eth3 goes down, look at all interfaces which have BindCarrier set, and check with glob if their BindCarrier setting matches eth3, and act accordingly. This means that every time any interface (dis)appears you must go through all existing BindCarrier statements and check whether they apply. This is really ugly. For this reasons I believe uplink group should be first class citizen also internally. Well, how many can you have? Even with a 100 interfaces, it'll be very fast. In practice you would use a glob or a set of globi, so the check will be a few calls to fnmatch. And how do you set properties for it? Which of BindCarrierMode statements in different link (or are they network?) files apply if they differ? What if you need to add more properties? What about DownlinkCarrierGroup=1 in upstream interface UplinkCarrierGroup=1 in downstream interface Index numbers are horrible in a configuration interface. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Support for staged startup
Hi Alison,
-Original Message-
From: Alison Chaiken [mailto:ali...@she-devel.com]
Sent: Thursday, January 29, 2015 8:17 PM
To: systemd-devel@lists.freedesktop.org
Cc: Hoyer, Marko (ADITG/SW2)
Subject: Re: Support for staged startup
Marko Hoyer asks:
I'd like to realize a staged startup with systemd which is mainly
about:
- starting up a static tree up to a final service
- the only job of the final service is to kick off the start of an
additional sub tree of units This kind of startup could be realized
simply by adding an additional one shot service which executes:
systemctl start xxx.target
Marko, one target can already be specified as After another. If
B.target is present in one of the appropriate directories and specifies
After=A.target
and all the services of the final sub-tree are symlinked in a
B.target.wants directory, doesn't the behavior you need result? What
is missing?Of course, some of the units linked in B.target.wants
may already be started by the time A.target completes if they are part
of a earlier target or if they are needed by an earlier unit. To
suppress that behavior, you'd have to edit the individual units.
I don't know of any use case for one unit to start another directly.
Is there one?
1.) Coming up with a small tree first reduces the loading time of the unit set
(not so much important in my case)
2.) If you wanna create some dynamics between target A and target B so that
depending on the startup situation services are already started before A or in
another round they are delayed until A is done, you probably need to disconnect
them from the static startup tree and pull them in dynamically at the desired
time.
-- Alison
--
Alison Chaiken ali...@she-devel.com
650-279-5600
http://{she-devel.com,exerciseforthereader.org}
Never underestimate the cleverness of advertisers, or mischief makers,
or criminals. -- Don Norman
Best regards
Marko Hoyer
Software Group II (ADITG/SW2)
Tel. +49 5121 49 6948
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd
В Thu, 29 Jan 2015 16:19:14 + Rauta, Alin alin.ra...@intel.com пишет: So, we have: 1. BindCarrier=list of uplink ports 2. Network.DownlinkCarrierGroup=1 in upstream interface Network.UplinkCarrierGroup=1 in downstream interface This would mean you have to create 2 new members for the Network structure. 3. If we are to add 2 members then we can also think of adding: Network.UFDGroup = 1; Network.UFDType = uplink/downlink; For the feature to be visible I would say 3, but I'm fine with any of them. I like 3 as well. Thanks, Alin -Original Message- From: Andrei Borzenkov [mailto:arvidj...@gmail.com] Sent: Thursday, January 29, 2015 3:49 PM To: Zbigniew Jędrzejewski-Szmek Cc: Rauta, Alin; Lennart Poettering; Kinsella, Ray; systemd Mailing List Subject: Re: [systemd-devel] [PATCH] Added UFD (Uplink failure detection) support to networkd В Thu, 29 Jan 2015 15:10:16 +0100 Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl пишет: On Thu, Jan 29, 2015 at 02:05:10PM +, Rauta, Alin wrote: What if we don't use the * for now and document BindCarrier accordingly to be a list of port names and no wildcard ? Then, if it's the case we can add such * support for BindCarrier and think about all those corner cases ? What about interpreting the wildcard dynimically instead? If eth3 goes down, look at all interfaces which have BindCarrier set, and check with glob if their BindCarrier setting matches eth3, and act accordingly. This means that every time any interface (dis)appears you must go through all existing BindCarrier statements and check whether they apply. This is really ugly. For this reasons I believe uplink group should be first class citizen also internally. And how do you set properties for it? Which of BindCarrierMode statements in different link (or are they network?) files apply if they differ? What if you need to add more properties? What about DownlinkCarrierGroup=1 in upstream interface UplinkCarrierGroup=1 in downstream interface This creates uplink group 1 and binds interfaces to it. Now you only need to care if there is another interface definition that has the same group number. But you still need ability to set group properties (although in practice every switch I have seen is using policy all - anyone can give compelling use case for using any?), so yes, we may need support configuration object for it. But the first step could be default to policy all which does not require any configuration. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] What's the correct way to configure encrypted volume and mount point?
On Thu, Jan 29, 2015 at 8:31 PM, John Lane syst...@jelmail.com wrote: I am looking for some advice about configuring encrypted volumes with systemd that I want to open on demand (noauto). I can add entries into /etc/crypttab and /etc/fstab for the device, for example # name device password options dataUUID=deadbeefnone noauto and # file systemdirtypeoptionsdumppass /dev/mapper/data /home/myuser/data ext4 noauto 0 0 But the device doesn't unlock when I do $ mount /home/myuser/data mount: special device /dev/mapper/keyring does not exist But it does if I use $ systemctl start home-myuser-data.mount I'm guessing that mount doesn't effect systemd and, therefore, the dependency isn't actioned. But the docs for systemd.mount state that configuring mount points through /etc/fstab is the preferred approach so I'm wondering if there's something I missed from my crypttab or fstab entries? No, you did not. systemd know about additional dependencies and tries to resolve them. Plain mount does not know anything about them. It is irrelevant where exactly this mount point is configured and decsribed. May be one day mount will forward mount request to systemd. Who knows. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd-nspawn support for loading kernel modules / custom seccomp rules
Hi all, I’m a big fan of systemd, and currently use IPA[1] running inside systemd-nspawn containers to provision and maintain systems as part of OpenStack Ironic. This includes, at times, doing things like flashing firmwares which may require a kernel module to be loaded. Currently, we’re using CoreOS 367.0.0 with 3.15.2 kernel and systemd 212. Recently, I attempted an upgrade to CoreOS 575.0.0 with kernel 3.18.2 and systemd 218 and found I could no longer load kernel modules from inside an nspawn container. This appears to be related to some seccomp filters added/enabled in systemd 215. Is it possible to have a switch added to systemd-nspawn to allow me to specify custom seccomp filters, or to disable them entirely? The only alternative to this for my use case is to not use containers at all or to preload all modules needed before launching my container. The 1st option doesn’t work well because CoreOS doesn’t ship with sufficient OS resources to run IPA inside it, and the second is not reasonable because the same IPA ramdisk is used across many nodes on a fleet, which may have different hardware and therefore different modules are required to perform things like BIOS flashing. Thanks in advance, Jay Faulkner [1] https://github.com/openstack/ironic-python-agent; relevent nspawn flags here: https://github.com/openstack/ironic-python-agent/blob/master/imagebuild/coreos/oem/cloud-config.yml#L40 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Callback of sd_bus_track: when it will be invoked
Hi all, I notice in sd_bus_track_new, a callback can be specified, but when it will be invoked? It seems it will not be triggered when a name in track is removed. -- Regards, - cee1 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
