Re: [systemd-devel] [PATCH] tmpfiles.c: Honor ordering within files as the docs say.
On Thu, 05.03.15 11:13, Randy Witt (randy.e.w...@linux.intel.com) wrote:
Sorry for the late review!
Previously, globs would always get processed first followed by any other
items in arbitrary order. This is contrary to the documentation which
states Otherwise, the files/directories are processed in the order they
are listed.
To fix this, remove the separate globs hashmap, and instead use only one
marking each entry as a glob or not. There should be little overhead
from doing this, considering the only time nested processing will occur
is for processing of globs which are not of type X.
Hmm, I figure the patch makes sense. Can you rebase this on current
git, please?
Also, any chance you can split this up in two patces, one that moves
this to ordered hashmaps, and the other which then merges the two
hashmaps? Should be much easier to review, then.
Signed-off-by: Randy Witt randy.e.w...@linux.intel.com
No S-o-b please, we do not use this in systemd.
src/tmpfiles/tmpfiles.c | 53
++---
1 file changed, 24 insertions(+), 29 deletions(-)
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 917bb3c..0b6d226 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -116,6 +116,7 @@ typedef struct Item {
bool force:1;
bool done:1;
+bool glob:1;
This is unnecessary, isn't it? I mean, this value is only dependent of
the line type, and we can always query that again with needs_glob(),
no need to store this away...
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] tmpfiles.c: Honor ordering within files as the docs say.
On Wed, 22.04.15 18:19, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 05.03.15 11:13, Randy Witt (randy.e.w...@linux.intel.com) wrote: Sorry for the late review! Previously, globs would always get processed first followed by any other items in arbitrary order. This is contrary to the documentation which states Otherwise, the files/directories are processed in the order they are listed. To fix this, remove the separate globs hashmap, and instead use only one marking each entry as a glob or not. There should be little overhead from doing this, considering the only time nested processing will occur is for processing of globs which are not of type X. Hmm, I figure the patch makes sense. Can you rebase this on current git, please? Also, any chance you can split this up in two patces, one that moves this to ordered hashmaps, and the other which then merges the two hashmaps? Should be much easier to review, then. So I looked into this in more detail now, and made the change to ordered hashmap now already. However, I don't think we should merge the two hashmaps. The reasons for this is actually documented in the code: lines that take globs *adjust* files or other fs objects, while lines that do not take globs *create* files or other fs objects. I think it is a good idea, to make sure that the lines that create files should be processed before the ones that adjust them, so that the adjustments are always applied to *all* files that exist in the fs after tmpfiles finished. I have updated the man page to explain this now. I hope this makes sense! Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] vconsole: rerun setup on console takeovers as well
On Tue, 24.02.15 19:23, Jan Engelhardt (jeng...@inai.de) wrote: Sorry for the late reply, When a system, which has an FB driver and fbcon loaded and active, then the font state gets lost on console takeovers, as for example issued by i915. Since fbcon remains loaded and active, the existing event handling (add/vtcon*) is not sufficient. what's the precise effect of this? I mean, iirc we already might end up calling s-v-s twice, since it is pulled in from a udev rule and during normal boot. Does this mean it is regularly pulled in thrice even? Isn#t the right fix to make the kernel keep the font settings around during the fb transition? Can you elaborate a bit on this? Kinda missing the details before I can merge this. David, Kay, any idea about this? --- This goes on top of the other patchset I sent earlier. [PATCH 1/2] vconsole: match on vtcon events, not fbcon ones src/vconsole/90-vconsole.rules.in | 4 1 file changed, 4 insertions(+) diff --git a/src/vconsole/90-vconsole.rules.in b/src/vconsole/90-vconsole.rules.in index 35b9ad5..e05ecbf 100644 --- a/src/vconsole/90-vconsole.rules.in +++ b/src/vconsole/90-vconsole.rules.in @@ -8,3 +8,7 @@ # Each vtcon keeps its own state of fonts. # ACTION==add, SUBSYSTEM==vtconsole, KERNEL==vtcon*, RUN+=@rootlibexecdir@/systemd-vconsole-setup + +# Handle the case of console takeover where the fb device is replaced. +# +ACTION==add, SUBSYSTEM==graphics, KERNEL==fb[0-9]*, RUN+=@rootlibexecdir@/systemd-vconsole-setup -- 2.1.4 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel 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] About the exit of systemd-udevd
On Tue, Apr 14, 2015 at 4:47 PM, Tom Yan tom.t...@gmail.com wrote: Under certain conditions, I discovered that commands like `udevadm control --exit` or `systemctl stop systemd-udevd` (with the sockets stopped beforehand) will kill udevd before it finish its jobs which triggered by `udevadm trigger` (I presume applying a written udev rule is one of them). Is this acceptable/expected? If so, is there any way to guarantee the jobs is done before it gets killed? It is expected, udevd will finish everything that is currently already running and do a clean shutdown, but not process any new events which might be triggered and pending. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
Hi Lennart, On Wed, Apr 22, 2015 at 1:46 PM, Lennart Poettering lenn...@poettering.net wrote: I was trying to run systemd-nspawn --ephemeral, but that failed since I had a read-only image in /var/lib/machines. Why is that not allowed? systemd-nspawn does create its own snapshot of that one after all (which can be read-write). Why does the base image have to be read-write, too? Hmm? This shouldn't fail. What's the precise error message you get? It complains about a read-only filesystem when trying to bind-mount some directories into the machine. Then I have trouble with systemd-nspawn --network-veth: The host0 interface won't come up and stays in degraded state. On the host i get the following line in the journal: systemd-networkd[509]: ve-XXX : Could not enable IP masquerading: Protocol not available I have an nftables based firewall up and running, so maybe networkd is expecting iptables to be in use? Most likely iptables is compiled as kernel module for you. The module cannot be auto-loaded currently, iptables manually loads it for you on first invocation, networkd doesn't. If you load it manually (by adding it to modules-load.d for example) things should work. I loaded the ip-tables module manually now and that does indeed fix the error message in my original mail. The machine still stays in degraded (configuring) forever though. As I said: I have a fully set up nftables-based firewall, so I expect systemd will have trouble doing anything sensible with iptables. I read iptables are a wrapper around nftables nowadays, but iptables -L does not show any of my rules, so that might be the reason for the trouble I am seeing. Do I need to reinstall my machines using an iptables firewall for this to work? Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 15:19, Tobias Hunger (tobias.hun...@gmail.com) wrote: On Wed, Apr 22, 2015 at 3:12 PM, Tobias Hunger tobias.hun...@gmail.com wrote: Hi Lennart, On Wed, Apr 22, 2015 at 1:46 PM, Lennart Poettering lenn...@poettering.net wrote: I was trying to run systemd-nspawn --ephemeral, but that failed since I had a read-only image in /var/lib/machines. Why is that not allowed? systemd-nspawn does create its own snapshot of that one after all (which can be read-write). Why does the base image have to be read-write, too? Hmm? This shouldn't fail. What's the precise error message you get? It complains about a read-only filesystem when trying to bind-mount some directories into the machine. Sorry, I forgot to attach the exact error message: Apr 22 15:13:18 server systemd-nspawn[1804]: Failed to create mount point /var/lib/machines/.#vmbdd461661453a1b8/mnt/ftp: Read-only file system Looking at the code I do not see why that subvolume should be read-only. Maybe it inherits the read-only from the one it is a snapshot off? Oh, that could be. I figure we should unset the read-only flag unless --ephemeral is combined with --read-only. 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] Journalctl Unit Completion Optmization
On Tue, 03.03.15 23:02, Justin Brown (justin.br...@fandingo.org) wrote: Hello, I've recently been using journalctl on one of my longer-lived systems, and I'm running into a slight annoyance. Most of the time I'm using `journalctl -u unit -e`. I use tab completion for the unit name, and the annoyance is the long pause journalctl takes to complete a unit. With cold cache (meaning writing 3 to /proc/sys/vm/drop_caches), this takes 23 seconds on a system using Btrfs on a SATA3 SSD. With warm cache, it still takes 3-4 seconds. Both cases are quite a bit slower than normal tab completion behavior. Is it really that bad if the files on btrfs are defragmented properly? Note that btrfs is notoriously bad at handling journald's write pattern currently, which results in heavily fragmented files. Use the filefrag tool to check how fragmented they are, and use btrfs defrag to the fix this. Before we look into other options I'd really prefer if you could check if this already fixes your issues. (Note that very recent journald will set the btrfs NOCOW flag now on the journal files, which should work around this issue.) 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] vconsole: rerun setup on console takeovers as well
Hi On Wed, Apr 22, 2015 at 6:14 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 24.02.15 19:23, Jan Engelhardt (jeng...@inai.de) wrote: Sorry for the late reply, When a system, which has an FB driver and fbcon loaded and active, then the font state gets lost on console takeovers, as for example issued by i915. Since fbcon remains loaded and active, the existing event handling (add/vtcon*) is not sufficient. what's the precise effect of this? I mean, iirc we already might end up calling s-v-s twice, since it is pulled in from a udev rule and during normal boot. Does this mean it is regularly pulled in thrice even? Isn#t the right fix to make the kernel keep the font settings around during the fb transition? Can you elaborate a bit on this? Kinda missing the details before I can merge this. David, Kay, any idea about this? The kernel should really issue a change uevent on handover. We should not guess this based on graphics device add/removal. Thanks David ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Zombie process still exists after stopping gdm.service
On Tue, 21.04.15 13:25, Daniel Drake (dr...@endlessm.com) wrote: There's a comment in unit_kill_context() which looks relevant here: /* FIXME: For now, we will not wait for the * cgroup members to die, simply because * cgroup notification is unreliable. It * doesn't work at all in containers, and * outside of containers it can be confused * easily by leaving directories in the * cgroup. */ /* wait_for_exit = true; */ This is indeed the key of the issue. As soon as we move to using the new sane behaviour kernel cgroup API we can fix this properly, and wait for the children correctly. As soon as that is not the case though we send SIGKILL immediately after the SIGTERM... I am a bit unwilling to document the precise behaviour, since the current behaviour is really just a stop-gap until we ported things over to the new kernel API and this will work as intended. 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] systemd-nspawn trouble
On Wed, 22.04.15 14:36, Michael Biebl (mbi...@gmail.com) wrote: Not everyone is using networkd or nspawn though, so loading this module for everyone is a bit excessive. Well, then blacklist the module or don't build it at all. That's the wrong way around. Nah, I disagree. We do this for a number of modules now. I mean, we We currently do this static loading for unix, ipv6 and autofs4. load tons of modules automatically, even if you don't use them. For example, my laptop always loads the bluetooth modules, even though I never used bluetooth. Those are all loaded on demand, not statically. I.e. we don't load the bluetooth module for each and every user. No, things like bluetooth are not loaded on demand, but already when you just have the hw for it. That's quite a difference. Pure on-demand loading of all modules is something that was given up on back in kernel 2.2 times already... 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] systemd-nspawn trouble
On Wed, 22.04.15 15:42, Tobias Hunger (tobias.hun...@gmail.com) wrote: PS: Is there a way to stop the VMs to get a btrfs subvolume created in /var/lib/machines? Not in nspawn, no. This could be implemented via seccomp though. I have a couple of .#vm subvolumes in /var/lib/machines now and btrfs subvolume delete does not work on those since they have a subvolume in /var/lib/machine. Apparently systemd-nspawn also stumbled over this as the directories are still there but the machines are not running. As mentioned in an earlier thread here, Chris intends to add recursive subvolume deletion to btrfs-progs. In systemd git machinectl remove recursively deletes subvolumes already. 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] systemd-nspawn trouble
2015-04-22 14:14 GMT+02:00 Lennart Poettering lennart at poettering.net: Well, I really don't want to give networkd the caps for that, sorry. It's a network facing daemon, it should not be able to load kernel modules. But it is okay for networkd to manipulate the firewall directly. Yes, networkd configures the network. That's its raison d'etre. Thanks for clearing that up. I alway's thought firewalls were a security thing, and that netfilter is mandatory access control framewark that should be, mostly, transparent to applications and services. -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift pgpbPvtZbgCoo.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 14:28, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-22 14:22 GMT+02:00 Michael Biebl mbi...@gmail.com: 2015-04-22 14:14 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Wed, 22.04.15 14:09, Michael Biebl (mbi...@gmail.com) wrote: Not everyone is using networkd or nspawn though, so loading this module for everyone is a bit excessive. Well, then blacklist the module or don't build it at all. [..] For the same reason that iptables doesn't complain loudly but loads it. To be user-friendly and just make things work? And making everyone who doesn't want this feature jump through hoops and having them blacklist the module is not user-friendly at all. Least of it, it's not really intuitive and discoverable, how this module got loaded in the first place. Well, it is not discoverable for *any* kmod really, not just this one. Except, that this is actually *more* discoverable thant normal udev-based or kernel-auto-loaded kmods, since we actually *do* log about it, in contrast to those cases. 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] systemd-nspawn trouble
2015-04-22 14:26 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Wed, 22.04.15 14:22, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-22 14:14 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Wed, 22.04.15 14:09, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-22 13:57 GMT+02:00 Lennart Poettering lenn...@poettering.net: Maybe we should simply list the iptables kernel modules in src/core/kmod-setup, and then tell people to blacklist them if they really don't want them. I have made such a change now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d3087978a8ee23107cb64aa55ca97aefe9531e2 Not everyone is using networkd or nspawn though, so loading this module for everyone is a bit excessive. Well, then blacklist the module or don't build it at all. That's the wrong way around. Nah, I disagree. We do this for a number of modules now. I mean, we We currently do this static loading for unix, ipv6 and autofs4. load tons of modules automatically, even if you don't use them. For example, my laptop always loads the bluetooth modules, even though I never used bluetooth. Those are all loaded on demand, not statically. I.e. we don't load the bluetooth module for each and every user. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
2015-04-22 15:25 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Wed, 22.04.15 14:36, Michael Biebl (mbi...@gmail.com) wrote: Not everyone is using networkd or nspawn though, so loading this module for everyone is a bit excessive. Well, then blacklist the module or don't build it at all. That's the wrong way around. Nah, I disagree. We do this for a number of modules now. I mean, we We currently do this static loading for unix, ipv6 and autofs4. load tons of modules automatically, even if you don't use them. For example, my laptop always loads the bluetooth modules, even though I never used bluetooth. Those are all loaded on demand, not statically. I.e. we don't load the bluetooth module for each and every user. No, things like bluetooth are not loaded on demand, but already when you just have the hw for it. That's quite a difference. Loading the bluetooth module when you have the hardware is something different then loading it unconditionally for everyone. You are doing the latter with iptables. And why does this have to be hard-coded in the source instead of shipping a /etc/modules-load.d snippet where it would be easily discoverable? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 15:43, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-22 15:25 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Wed, 22.04.15 14:36, Michael Biebl (mbi...@gmail.com) wrote: Not everyone is using networkd or nspawn though, so loading this module for everyone is a bit excessive. Well, then blacklist the module or don't build it at all. That's the wrong way around. Nah, I disagree. We do this for a number of modules now. I mean, we We currently do this static loading for unix, ipv6 and autofs4. load tons of modules automatically, even if you don't use them. For example, my laptop always loads the bluetooth modules, even though I never used bluetooth. Those are all loaded on demand, not statically. I.e. we don't load the bluetooth module for each and every user. No, things like bluetooth are not loaded on demand, but already when you just have the hw for it. That's quite a difference. Loading the bluetooth module when you have the hardware is something different then loading it unconditionally for everyone. You are doing the latter with iptables. I don#t see how this really was any different. I am sure a lot of people never want to use bluetooth, and I am also sure that a lot of people don#t want to use iptables (and of both of these, bluetooth is certainly the more exotic one, even). In both cases we autoload them now, with an easy way out, via blacklisting. And why does this have to be hard-coded in the source instead of shipping a /etc/modules-load.d snippet where it would be easily discoverable? Because we generally try to make the system just work, without configuration. There's also another backstory: hopefully we can merge Daniel's patches soon that add minimal per-service Firewalling to PID 1. In that case it's not only networkd+nspawn that needs this, but PID 1 too, which makes the modules-load.d path unworkable. 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] systemd-nspawn trouble
On Wed, 22.04.15 15:55, Dominick Grift (dac.overr...@gmail.com) wrote: 2015-04-22 14:14 GMT+02:00 Lennart Poettering lennart at poettering.net: Well, I really don't want to give networkd the caps for that, sorry. It's a network facing daemon, it should not be able to load kernel modules. But it is okay for networkd to manipulate the firewall directly. Yes, networkd configures the network. That's its raison d'etre. The nft manual page states that the iptable_nat module conflicts with the module that deals with nftables nat. Does that mean that the networkd IPMasquerade= functionality will not work if one blacklists iptables_nat? Well, if that's what it says, then yes. We can certainly add support for manipulating nft too, but so far the APIs fo that appeared much less convincing to me, and quite a bit more exotic. 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] systemd-nspawn trouble
On Wed, 22.04.15 15:12, Tobias Hunger (tobias.hun...@gmail.com) wrote: Then I have trouble with systemd-nspawn --network-veth: The host0 interface won't come up and stays in degraded state. On the host i get the following line in the journal: systemd-networkd[509]: ve-XXX : Could not enable IP masquerading: Protocol not available I have an nftables based firewall up and running, so maybe networkd is expecting iptables to be in use? Most likely iptables is compiled as kernel module for you. The module cannot be auto-loaded currently, iptables manually loads it for you on first invocation, networkd doesn't. If you load it manually (by adding it to modules-load.d for example) things should work. I loaded the ip-tables module manually now and that does indeed fix the error message in my original mail. The machine still stays in degraded (configuring) forever though. As I said: I have a fully set up nftables-based firewall, so I expect systemd will have trouble doing anything sensible with iptables. I read iptables are a wrapper around nftables nowadays, but iptables -L does not show any of my rules, so that might be the reason for the trouble I am seeing. Well, to my knowledge the kernel actually supports both in parallel. networkd + nspawn only do iptables. Do I need to reinstall my machines using an iptables firewall for this to work? No need. 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] systemd-nspawn trouble
PS: Is there a way to stop the VMs to get a btrfs subvolume created in /var/lib/machines? I have a couple of .#vm subvolumes in /var/lib/machines now and btrfs subvolume delete does not work on those since they have a subvolume in /var/lib/machine. Apparently systemd-nspawn also stumbled over this as the directories are still there but the machines are not running. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, Apr 22, 2015 at 4:04 PM, Lennart Poettering lenn...@poettering.net wrote: Well, if that's what it says, then yes. We can certainly add support for manipulating nft too, but so far the APIs fo that appeared much less convincing to me, and quite a bit more exotic. The user space tools for nft are much nicer than iptables, so I think they do provide a significant benefit. I would appreciate not having to go back to iptables:-) The exact command line I am running is this (straight out of systemctl cat systemd-nspawn@vm.service, *THANKS* to whoever implemented that!): ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --ephemeral \ --machine=vm \ --network-veth \ --bind=/mnt/raid0/data/ftp:/mnt/ftp /var/lib/machines is a normal read-write btrfs snapshot. vm is a read-only snapshot. It starts fine when vm is read-write. Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, Apr 22, 2015 at 3:12 PM, Tobias Hunger tobias.hun...@gmail.com wrote: Hi Lennart, On Wed, Apr 22, 2015 at 1:46 PM, Lennart Poettering lenn...@poettering.net wrote: I was trying to run systemd-nspawn --ephemeral, but that failed since I had a read-only image in /var/lib/machines. Why is that not allowed? systemd-nspawn does create its own snapshot of that one after all (which can be read-write). Why does the base image have to be read-write, too? Hmm? This shouldn't fail. What's the precise error message you get? It complains about a read-only filesystem when trying to bind-mount some directories into the machine. Sorry, I forgot to attach the exact error message: Apr 22 15:13:18 server systemd-nspawn[1804]: Failed to create mount point /var/lib/machines/.#vmbdd461661453a1b8/mnt/ftp: Read-only file system Looking at the code I do not see why that subvolume should be read-only. Maybe it inherits the read-only from the one it is a snapshot off? Best Regards, Tobias ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 15:19, Tobias Hunger (tobias.hun...@gmail.com) wrote: On Wed, Apr 22, 2015 at 3:12 PM, Tobias Hunger tobias.hun...@gmail.com wrote: Hi Lennart, On Wed, Apr 22, 2015 at 1:46 PM, Lennart Poettering lenn...@poettering.net wrote: I was trying to run systemd-nspawn --ephemeral, but that failed since I had a read-only image in /var/lib/machines. Why is that not allowed? systemd-nspawn does create its own snapshot of that one after all (which can be read-write). Why does the base image have to be read-write, too? Hmm? This shouldn't fail. What's the precise error message you get? It complains about a read-only filesystem when trying to bind-mount some directories into the machine. Sorry, I forgot to attach the exact error message: Apr 22 15:13:18 server systemd-nspawn[1804]: Failed to create mount point /var/lib/machines/.#vmbdd461661453a1b8/mnt/ftp: Read-only file system Looking at the code I do not see why that subvolume should be read-only. Maybe it inherits the read-only from the one it is a snapshot off? So, this is not inherited. THere are some trouble with setting the read only flag correctly when we do recursive snapshots, I am working on fixing that now. That only is triggered when --read-only and --ephemeral are combined though. The error you run into confuses me a bit I must say. What's the precise command line you trigger this with? Does /mnt/tmp exist? Is /mnt a mount or so, and /mnt/tmp another? 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 v2 1/2] Don't use ALSA card id in ID_ID
On Tue, 21.04.15 17:45, Adam Goode (ago...@google.com) wrote:
The ALSA id sysattr is generated by the sound subsystem and is not
a stable identifier. It is generated though some string manipulation
then made unique if there is a conflict. This means that it is
enumeration-dependent and shouldn't be used for ID_ID.
If ID_ID is supposed to be system-unique, it is not already since
for firewire it is generated from the guid and there are broken
firewire devices that have duplicate guids across devices.
This is tracked for PulseAudio at
https://bugs.freedesktop.org/show_bug.cgi?id=90129.
Please also mention that commit that this effectvily reverts, see
earlier discussion.
---
rules/78-sound-card.rules | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/rules/78-sound-card.rules b/rules/78-sound-card.rules
index 295f490..bd7a994 100644
--- a/rules/78-sound-card.rules
+++ b/rules/78-sound-card.rules
@@ -49,8 +49,8 @@ SUBSYSTEMS==firewire, GOTO=skip_pci
SUBSYSTEMS==pci, ENV{ID_BUS}=pci, ENV{ID_VENDOR_ID}=$attr{vendor},
ENV{ID_MODEL_ID}=$attr{device}
LABEL=skip_pci
-ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==?*,
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}-$env{ID_USB_INTERFACE_NUM}-$attr{id}
-ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==,
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}-$attr{id}
+ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==?*,
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}-$env{ID_USB_INTERFACE_NUM}
+ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==,
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}
IMPORT{builtin}=path_id
--
2.2.0.rc0.207.ga3a616c
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 v2 2/2] Add more firewire properties for sound, to be closer to USB and PCI
On Tue, 21.04.15 17:45, Adam Goode (ago...@google.com) wrote:
USB and PCI soundcards have a nice set of ID_* properties. It would
be handy for firewire soundcards to have the same.
As requested earlier, please document in the commit messsage that this
does not eat up ID_ID.
---
rules/78-sound-card.rules | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/rules/78-sound-card.rules b/rules/78-sound-card.rules
index bd7a994..04740e8 100644
--- a/rules/78-sound-card.rules
+++ b/rules/78-sound-card.rules
@@ -41,14 +41,17 @@ IMPORT{builtin}=hwdb
SUBSYSTEMS==usb, IMPORT{builtin}=usb_id
SUBSYSTEMS==usb, GOTO=skip_pci
-SUBSYSTEMS==firewire, ATTRS{vendor_name}==?*, ATTRS{model_name}==?*, \
- ENV{ID_BUS}=firewire, ENV{ID_VENDOR}=$attr{vendor_name},
ENV{ID_MODEL}=$attr{model_name}
-SUBSYSTEMS==firewire, ATTRS{guid}==?*, ENV{ID_ID}=firewire-$attr{guid}
+SUBSYSTEMS==firewire, ATTRS{guid}==?*, \
+ ENV{ID_BUS}=firewire, ENV{ID_SERIAL}=$attr{guid},
ENV{ID_SERIAL_SHORT}=$attr{guid}, \
+ ENV{ID_VENDOR_ID}=$attr{vendor}, ENV{ID_MODEL_ID}=$attr{model}, \
+ ENV{ID_VENDOR}=$attr{vendor_name}, ENV{ID_MODEL}=$attr{model_name}
SUBSYSTEMS==firewire, GOTO=skip_pci
SUBSYSTEMS==pci, ENV{ID_BUS}=pci, ENV{ID_VENDOR_ID}=$attr{vendor},
ENV{ID_MODEL_ID}=$attr{device}
LABEL=skip_pci
+# Define ID_ID if ID_BUS and ID_SERIAL are set. This will work for both
+# USB and firewire.
ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==?*,
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}-$env{ID_USB_INTERFACE_NUM}
ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==,
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}
--
2.2.0.rc0.207.ga3a616c
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] How to factory reset?
On Mon, 16.03.15 11:31, Tobias Hunger (tobias.hun...@gmail.com) wrote: Just a short update: I managed to get my machine image to (kind of) boot in systemd-nspawn this weekend. Kind-of as it tries to mount some drives that are obviously not there in the container. But apart from that it seems to boot fine:-) On real hardware I am not so lucky: Once I get to system-switch-root.service I get lots of output about missing nodes in dev (/dev/ttyX mostly). Note that systemd only supports /dev mounted from devtmpfs, where the nodes are created by the kernel (and not userspace), and hence cannot really be missing. If the nodes are missing this is an indication that /dev is configured in some other way... 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] How to factory reset?
On Wed, 11.03.15 20:56, Kay Sievers (k...@vrfy.org) wrote: On Wed, Mar 11, 2015 at 7:45 PM, Chris Murphy li...@colorremedies.com wrote: On Wed, Mar 11, 2015 at 11:50 AM, Kay Sievers k...@vrfy.org wrote: The all included kernels are found at /boot/EFI/Linux/*.efi Yeah until the distros stop persistently mounting the ESP, I'm not a fan at all of anything but the most minimalist approach to the ESP. Systemd by default mounts it with autofs, it will not be mounted until it is accessed, which does not happen during normal operation. We currently miss autofs timeout handling, which would umount /boot again when it is no longer used. That would make stuff pretty robust, I expect. Quick update on this: autofs expiry is now implemented and enabled for the ESP mount systemd does by default. This should shorten the time-frame of corruptions of the ESP quite a bit. 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] Service watchdog feature in state ACTIVATING ?
On Mon, 02.03.15 20:32, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-jv.com) wrote: Why would you need this? Watchdog is to prevent system being stuck somewhere. If activation fails within TimeoutStartSec=, systemd will put the service in failed to activate state anyways. Is waiting 20 seconds to detect the freeze is too much for your case? Is it not possible to lower the activation time? Yes it is too long. The process is a kind of application starter and observer processing a startup phase. It is responsible for: - observing the application internal states of upcoming applications - it kicks off the startup of applications depending on the internal state of other once - it delays the startup of late services started the normal way by systemd once the startup phase is done And yes, one could say that we are implementing a kind of second systemd started by systemd. The difference is that our starter knows about some more states than just ACTIVATING and RUNING which is not really realizable with systemd especially when more than one application is contained in one process. So the idea was to bring up a set of applications with our starter application and stay with our starter in state ACTIVATING until it is done with bringing up the set of applications. Depending on the product, bringing up our set of applications can take 10-20secs. Since the starter is a kind of sensible application, it needs to be supervised by a watchdog with a timeout far less than 20secs. Hope this gives a rough picture of our use case. So, I can see that having watchdog support during the activating phase might make sense in this case, but I am not sure this case is strong enough to add it to systemd proper, since it would complicate things for most: it's not a behaviour we can just enable for everybody, it would have to be something we'd have to add an explicit opt-in option for, since most daemons don't work like this. I mean, in most cases the start-up phase of a daemon is relatively quick, and the daemon will not enter its event loop before the start-up is complete. But it is the event loop that normally needs to process watchdog events. Anyway, I'd prefer not adding support for this now. We can revisit this if more folks are asking for this, and this turns out to be a more common setup. I hope that makes sense, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] unit: When stopping due to BindsTo=, log which unit caused it
On Tue, Apr 21, 2015 at 10:35 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Tue, Apr 21, 2015 at 03:54:35PM +0200, Alban Crequy wrote: On Sat, Feb 28, 2015 at 5:40 PM, Lennart Poettering lenn...@poettering.net wrote: On Fri, 27.02.15 17:13, Lennart Poettering (lenn...@poettering.net) wrote: On Thu, 26.02.15 16:50, Martin Pitt (martin.p...@ubuntu.com) wrote: IMHO it would be prudent to skip adding the BindsTo= if at the time of creating the .mount unit the backing .device unit doesn't actually exist. In that case it's a mount which isn't managed by systemd, and we shouldn't touch it. We mostly want this BindsTo= for mounts where the .device units *do* exist, so that when they go away we can clean up the mount (mostly for hotpluggable devices and removable media). I'll have a deeper look ASAP. I ran into this myself the other day, and Kay, Daniel and I spent a lot of time to come up with a scheme how to deal with the race... And I think we have a nice scheme now and I started implementing it. The idea is that .device units will gain a third state: currently they are either dead or plugged, and the new state will be tentative. It is entered when a device is referenced in /proc/self/mountinfo or /proc/swap, even though it has not yet shown up via udev. This new state has will not result in BindsTo= getting active. This is implemented now. Please check if this fixes this issue for you. Which commit implements this? I have an issue on nspawn container shutdown with v219 that I didn't have with v215. Systemd is trying to unmount the volumes bind mounted by nspawn and it fails because /bin/umount does not exist in my container. Systemd keeps trying to umount it in a busy loop. Reverting 06e9783e2cc12eb6514e80c7f0014295f59b (core/mount: add dependencies to dynamically mounted mounts too) fixes my issue. There was a bunch of fixes on top. See 5bd4b173605142, 628c89cc68ab96fce2d, 496068a8288084ab3. Thanks for the commits. They don't seem related to containers. I can reproduce my issue on git-master: sudo ~/git/systemd/systemd-nspawn --register=false --bind $HOME/tmp/vol -D debian-tree -b Then, in the container, make sure /bin/umount does NOT exist. Then halt the container with kill -37 1 (SIGRTMIN+3) It will loop forever on: [ OK ] Failed unmounting /home/alban/tmp/vol. Unmounting /home/alban/tmp/vol... [ OK ] Failed unmounting /home/alban/tmp/vol. Unmounting /home/alban/tmp/vol... I am not sure why it worked fine for me with the older version v215. Cheers, Alban ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 16:31, Tobias Hunger (tobias.hun...@gmail.com) wrote: On Wed, Apr 22, 2015 at 4:04 PM, Lennart Poettering lenn...@poettering.net wrote: Well, if that's what it says, then yes. We can certainly add support for manipulating nft too, but so far the APIs fo that appeared much less convincing to me, and quite a bit more exotic. The user space tools for nft are much nicer than iptables, so I think they do provide a significant benefit. I would appreciate not having to go back to iptables:-) The exact command line I am running is this (straight out of systemctl cat systemd-nspawn@vm.service, *THANKS* to whoever implemented that!): ExecStart=/usr/bin/systemd-nspawn --quiet --keep-unit --boot --ephemeral \ --machine=vm \ --network-veth \ --bind=/mnt/raid0/data/ftp:/mnt/ftp /var/lib/machines is a normal read-write btrfs snapshot. vm is a read-only snapshot. It starts fine when vm is read-write. OK, I think I fixed this now, please check: http://cgit.freedesktop.org/systemd/systemd/commit/?id=aee327b8169670986f6a48acbd5ffe1355bfcf27 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] How to factory reset?
On Fri, 13.03.15 01:16, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: On Tue, Mar 10, 2015 at 10:23:23PM +0100, Tobias Hunger wrote: On Tue, Mar 10, 2015 at 9:33 PM, Tobias Hunger tobias.hun...@gmail.com wrote: presets and machined ID are applied by PID 1, before it begins with starting any units, hence *really* early on. Note though that actually /etc/machine-id is used as flag for is /etc empty. If the file exists it is assumed that /etc is provisioned properly. If it is missing PID 1 will generate the machiend id and apply presets. An OS installer could put the machine-id into /usr just fine (and so can I) and systemd could just get it from there if available before generating a new one. It would be nice if the machine-id did not change during to a factory reset: It is used in the logs and changing it will basically make historical log data much harder to analyze. IIRC networkd also uses it to generate persistent MAC addresses for containers and such. So far this seems to be the only critical piece of information that can not get restored via tmpfiles.d. Thinking about this a bit longer: /usr does not seem like a good idea. The machine-id is supposed to be unique and usr-images are meant to be reused. Maybe provide a kernel command line option to force the machine-id if none is set yet? I think this could be an option. We currently check /var/lib/dbus/machine-id, $container_uuid, and /sys/class/dmi/id/product_uuid. I think that the first should work for your use case, since you keep /var. But we also check some commandline option, this seems useful for some use cases. I think /var/lib/dbus/machine-id is nothing to use here. It purely exists for compat with upgrades from classic dbus1 systems, where we should avoid inventing a new machine id, if the dbus one is fine. I'd be fine with adding a kernel switch to make this configurable, as Zbigniew suggested. 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] Needs help for on charging activation
On Mon, 09.03.15 23:21, WaLyong Cho (walyong@samsung.com) wrote: Hi, I want to find best solution on our case. Our product is mobile device. But I don't think that is only problem of mobile device. That also can be problem of laptop. So, please comment to me. We have some of services are always running after system is started up as default. They don't need to be running always. They are just needed only charger is plugged in. So I thought lets only active them when only charger is plugged in. [...] Is there any more good way for this? I want to find best appropriate way. We currently have no nice way to cover this I must say. I figure the way how I would implement this is by having some power daemon (upower?) activate a target or so when power comes or goes. systemd alone does not cover this right now, and i doubt it should. This should really be handled by an external daemon I think. 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] How to factory reset?
On Fri, 13.03.15 14:20, Tobias Hunger (tobias.hun...@gmail.com) wrote: Hi Zbyszek, I would expect the machine-id to be written before mount units are processed, so for that to work I would need to mount /var in the initrd, wouldn't I? Yeah, /var/lib/dbus/machine-id isn't a general purpose solution, since /var ca nbe mounted very late. (Also, as mentioned in other mail, it's compat only, please don't use it.) Currently I am trying to just write the machine-id to /etc in the initrd. This makes systemd loose the understanding that /etc is empty though, which might have some side-effects that I am not yet anticipating. Isn't systemd started from inside the initrd once the new root has been set up? Maybe I could set $container_uuid and feed the machine-id to systemd that way? I am afraid that this will lead to some other side-effects, because systemd might assume to be running inside a container. Looks like I will have to do some testing over the weekend:-) $container_uuid is only used in containers. If you set it in other conditions, we don't care. Maybe I am lucky and /sys/class/dmi/id/product_uuid is set. That is only read on kvm, since on physical hardware it is more often than not filled with rubbish, that is not useful as a real machine id. 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 v2] automount: add expire support
On Tue, Apr 21, 2015 at 08:45:30PM +0200, Lennart Poettering wrote: On Tue, 14.04.15 22:01, Michael Olbrich (m.olbr...@pengutronix.de) wrote: I added some more logging (so that automount_dispatch_expire() can never fail without this being logged) and applied it! I only gave this superficial testing though, please check if this all still works fine for you now! Looks good. My test-cases work just fine. Michael -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] networkd: introduce vti6 tunnel
On 04/21/2015 09:54 PM, Lennart Poettering wrote:
On Tue, 21.04.15 15:16, Susant Sahani (sus...@redhat.com) wrote:
+static int netdev_vti6_fill_message_create(NetDev *netdev, Link *link,
sd_rtnl_message *m) {
+Tunnel *t = VTI6(netdev);
+int r;
+
+assert(netdev);
+assert(link);
+assert(m);
+assert(t);
+assert(t-family == AF_INET6);
+
+r = sd_rtnl_message_append_u32(m, IFLA_VTI_LINK, link-ifindex);
+if (r 0) {
+log_netdev_error(netdev,
+ Could not append IFLA_IPTUN_LINK attribute:
%s,
+ strerror(-r));
+return r;
+}
I have now added log_netdev_error_errno(), which takes the error
number as parameter, and opens it up for %m. Hence please rewrite the
7 lines above as these 2:
Sure I will make the changes.
if (r 0)
return log_netdev_error_errno(netdev, r, Could not append
IFLA_IPTUN_LINK attribute: %m);
+r = sd_rtnl_message_append_in6_addr(m, IFLA_VTI_LOCAL, t-local.in6);
+if (r 0) {
+log_netdev_error(netdev,
+ Could not append IFLA_IPTUN_LOCAL attribute:
%s,
+ strerror(-r));
+return r;
+}
Similar here.
+r = sd_rtnl_message_append_in6_addr(m, IFLA_VTI_REMOTE,
t-remote.in6);
+if (r 0) {
+log_netdev_error(netdev,
+ Could not append IFLA_IPTUN_REMOTE attribute:
%s,
+ strerror(-r));
+return r;
+}
Similar here.
static void vti_init(NetDev *n) {
-Tunnel *t = VTI(n);
+Tunnel *t;
assert(n);
+
+if (n-kind == NETDEV_KIND_VTI)
+t = VTI(n);
Spurious space.
Lennart
Susant
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] udev: Fix ping timeout when settle timeout is 0
Hi
On Mon, Apr 20, 2015 at 6:58 PM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Sun, Apr 19, 2015 at 1:49 AM, Nir Soffer nir...@gmail.com wrote:
When running udevadm settle --timeout=0, the ping always times out, and
udevadm will return 0 without checking the queue state.
Since zero timeout is considered as unlimited timeout, we use now
unlimited ping timeout.
---
src/udev/udevadm-settle.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/udev/udevadm-settle.c b/src/udev/udevadm-settle.c
index 2c84ada..424 100644
--- a/src/udev/udevadm-settle.c
+++ b/src/udev/udevadm-settle.c
@@ -107,7 +107,9 @@ static int adm_settle(struct udev *udev, int argc, char
*argv[]) {
uctrl = udev_ctrl_new(udev);
if (uctrl != NULL) {
-if (udev_ctrl_send_ping(uctrl, timeout) 0) {
+int ping_timeout = timeout 0 ? (int)timeout : -1;
+
+if (udev_ctrl_send_ping(uctrl, ping_timeout) 0) {
log_debug(no connection to daemon);
udev_ctrl_unref(uctrl);
return EXIT_SUCCESS;
This looks much more reasonable to me. I'd prefer some sanity-timeout,
though. 1s or 5s or something like this. Kay?
Applied.
Thanks
David
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] install a fedora container
On Wed, Apr 22, 2015 at 7:39 PM, Lennart Poettering lenn...@poettering.net wrote: On Wed, 22.04.15 19:26, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: I am little confused how to install Fedora on a container on my Archlinux box. Here is my setup : a whole ssd for Fedora server. Btrfs with 3 subvolumes for snapshots: /etc, /var, and /rootvol. No nested subvolumes. This ssd will then be mounted on /var/lib/container/MyContainer. Shall i install first Fedora server on the SSD then mount it in /var/lib/container and boot with systemd-nspawn ? Or is there another solution? The usualy way how I installed a Fedora container so far, was via yum --installroot. But that of course only works if you have yum around, which might be unavailable on ArchLinux. Yes yum package is available in Arch. Another option is to use the upstream cloud image. Recent systemd-nspawn versions can boot that directly if you stick that in /var/lib/machines and uncompress it. The image is here: http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/21/Cloud/Images/x86_64/Fedora-Cloud-Base-20141203-21.x86_64.raw.xz I wanted to install 22 server beta. Will see if I can find a link. Thank you for tips. In systemd git you can use machinectl pull-raw directly on this URL which will do this all automatically for you. Lennart -- Lennart Poettering, Red Hat -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] install a fedora container
I am little confused how to install Fedora on a container on my Archlinux box. Here is my setup : a whole ssd for Fedora server. Btrfs with 3 subvolumes for snapshots: /etc, /var, and /rootvol. No nested subvolumes. This ssd will then be mounted on /var/lib/container/MyContainer. Shall i install first Fedora server on the SSD then mount it in /var/lib/container and boot with systemd-nspawn ? Or is there another solution? Thank you. -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] install a fedora container
On Wed, Apr 22, 2015 at 7:26 PM, arnaud gaboury arnaud.gabo...@gmail.com wrote: I am little confused how to install Fedora on a container on my Archlinux box. Here is my setup : a whole ssd for Fedora server. Btrfs with 3 subvolumes for snapshots: /etc, /var, and /rootvol. No nested subvolumes. This ssd will then be mounted on /var/lib/container/MyContainer. Shall i install first Fedora server on the SSD then mount it in /var/lib/container and boot with systemd-nspawn ? Or is there another solution? EDIT : I already downloaded the iso file. Thank you. -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] option to ignore ENOMEDIUM in blkid
On Wed, 18.02.15 23:51, Hans Scholze (hans.scho...@gmail.com) wrote:
# probe filesystem metadata of disks
-KERNEL!=sr*, IMPORT{builtin}=blkid
+KERNEL!=sr*, IMPORT{builtin}=blkid --ignore-enomedium
Adding a new switch for this sounds overly complicated. We should
really ignore this error in any case, and just print a debug level
message about this case, which people can see if they turn debug
logging on.
Now, as it turns out I actually commited such a change a week back
with 8d8ce9e2cd066e90c17e2d1eb1882defabb1fa63 in order to fix fdobz
89885.
I figure this should resolve the issue,
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] Improve log notice when unprivileged users run journalctl executable
On Tue, 24.02.15 23:42, Gautier Pelloux-Prayer (gaut...@damsy.net) wrote: Hi, Currently, when user runs journalctl without extra privileges, output will be: No journal files were found. Hmm, this would be a bug. The whole logic of collecting error codes in j-errors exists exclusively to show more useful error messages in this case. Are you saying this does not work correctly for you? 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] install a fedora container
On Wed, 22.04.15 19:26, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: I am little confused how to install Fedora on a container on my Archlinux box. Here is my setup : a whole ssd for Fedora server. Btrfs with 3 subvolumes for snapshots: /etc, /var, and /rootvol. No nested subvolumes. This ssd will then be mounted on /var/lib/container/MyContainer. Shall i install first Fedora server on the SSD then mount it in /var/lib/container and boot with systemd-nspawn ? Or is there another solution? The usualy way how I installed a Fedora container so far, was via yum --installroot. But that of course only works if you have yum around, which might be unavailable on ArchLinux. Another option is to use the upstream cloud image. Recent systemd-nspawn versions can boot that directly if you stick that in /var/lib/machines and uncompress it. The image is here: http://ftp.halifax.rwth-aachen.de/fedora/linux/releases/21/Cloud/Images/x86_64/Fedora-Cloud-Base-20141203-21.x86_64.raw.xz In systemd git you can use machinectl pull-raw directly on this URL which will do this all automatically for you. 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] Setting up network interfaces for containers with --private-network
Lennart Poettering lenn...@poettering.net writes: On Tue, 21.04.15 15:22, Spencer Baugh (sba...@catern.com) wrote: Also, trivial static IP configuration is seldom sufficient, you at least need to also provide DNS configuration, and if you don't use DHCP or something similar then you need to configure that inside the container anyway. But if you do that you might as well configure the static IP addresses in it too, so what is gained by doing this from a networkd outside of the cotnainer? Or am I misunderstanding the role of networkd? It seems like if I am writing a service that represents the network interface and namespace for this container, I am doing something that networkd should ultimately do. Sure, absolutely. But our idea so far was that networkd should run inside the container to configure the container's network, and on the host to configure the host's network, but not to cross this boundary and have the host networkd configure the container's network. Hmm, yes, but I think the problem is the configuration done at interface-creation-time. It seems to me that that configuration currently does not fit naturally in either the host networkd or the container networkd. Well, again, I doubt that configuration exclusivel at interface-creation-time will be useful for more than the most trivial cases, already because as mentioned it would not cover DNS server configuration and thelike. Sure, I'm in agreement, but there are things that can only be configured at interface-creation-time. As a trivial example, the type of the interface. And it looks like for ipvlan you can only choose L2 or L3 mode at creation-time. Additionally, it seems to me that the MAC address, at least, is something that you might want to configure only at creation-time and not change later. The earlier two examples are necessary, the third example, the MAC address, is just nice-to-have. But since there are things that actually really must be configured at creation-time, it seems that eventually it will be necessary to figure out a best practice or mechanism for such configuration. And that method might as well also allow the nice-to-have of configuring the MAC address at creation time. If you really want fixed IP addresses, I think this could work: We add configurability for the DHCP server address range in networkd, including taking ranges that contain a single IP address. You could then assign fixed addresses to your containers simply by dropping a .network snippet for them, that only contains a single dhcp range IP address for it. THat should work, no? This would be a nice feature and would work for many use cases. My problem with this solution is that I'm using IPv6. With IPv6, I can set up stateless autoconfiguration to assign IPs to interfaces. In that case the IP is directly determined by the MAC address, so it is not possible (AFAIK?) to specify a range of IPs of length 1 to force that single IP to be assigned to a specific interface. I would somewhat prefer to be using this feature of IPv6, rather than using DHCPv6; and anyway, networkd doesn't support DHCPv6 right now, right? So this doesn't necessarily work for me. The mapping from MAC address to IPv6 address is just a matter of encoding the MAC address in the last 64 bits of the IPv6 address. So if I know the MAC address of the container, and maybe listen a little on the network interface to see what routing prefix is being advertised, I know the IPv6 address that the container will get. Maybe something (networkd, networkctl, machined, machinectl?) could reveal this information? Just an idea. The stateless autoconfiguration of IPv6 seems pretty similar to systemd's own aims, it would be nice if they worked well together. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service watchdog feature in state ACTIVATING ?
-Original Message- From: Lennart Poettering [mailto:lenn...@poettering.net] Sent: Wednesday, April 22, 2015 6:00 PM To: Hoyer, Marko (ADITG/SW2) Cc: Umut Tezduyar Lindskog; systemd-devel@lists.freedesktop.org Subject: Re: [systemd-devel] Service watchdog feature in state ACTIVATING ? On Mon, 02.03.15 20:32, Hoyer, Marko (ADITG/SW2) (mho...@de.adit- jv.com) wrote: Why would you need this? Watchdog is to prevent system being stuck somewhere. If activation fails within TimeoutStartSec=, systemd will put the service in failed to activate state anyways. Is waiting 20 seconds to detect the freeze is too much for your case? Is it not possible to lower the activation time? Yes it is too long. The process is a kind of application starter and observer processing a startup phase. It is responsible for: - observing the application internal states of upcoming applications - it kicks off the startup of applications depending on the internal state of other once - it delays the startup of late services started the normal way by systemd once the startup phase is done And yes, one could say that we are implementing a kind of second systemd started by systemd. The difference is that our starter knows about some more states than just ACTIVATING and RUNING which is not really realizable with systemd especially when more than one application is contained in one process. So the idea was to bring up a set of applications with our starter application and stay with our starter in state ACTIVATING until it is done with bringing up the set of applications. Depending on the product, bringing up our set of applications can take 10-20secs. Since the starter is a kind of sensible application, it needs to be supervised by a watchdog with a timeout far less than 20secs. Hope this gives a rough picture of our use case. So, I can see that having watchdog support during the activating phase might make sense in this case, but I am not sure this case is strong enough to add it to systemd proper, since it would complicate things for most: it's not a behaviour we can just enable for everybody, it would have to be something we'd have to add an explicit opt-in option for, since most daemons don't work like this. Thx for getting back to this again. An a bit more light weight variant could be adding a second watchdog timeout parameter meant for the activation phase only. This timeout value could be 0 (infinite) by default. This way, the feature is probably invisible for all who are not explicitly setting it. Anyway, I'd prefer not adding support for this now. We can revisit this if more folks are asking for this, and this turns out to be a more common setup. Sounds good. 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] Setting up network interfaces for containers with --private-network
On Wed, 22.04.15 13:41, Spencer Baugh (sba...@catern.com) wrote: Lennart Poettering lenn...@poettering.net writes: On Tue, 21.04.15 15:22, Spencer Baugh (sba...@catern.com) wrote: Also, trivial static IP configuration is seldom sufficient, you at least need to also provide DNS configuration, and if you don't use DHCP or something similar then you need to configure that inside the container anyway. But if you do that you might as well configure the static IP addresses in it too, so what is gained by doing this from a networkd outside of the cotnainer? Or am I misunderstanding the role of networkd? It seems like if I am writing a service that represents the network interface and namespace for this container, I am doing something that networkd should ultimately do. Sure, absolutely. But our idea so far was that networkd should run inside the container to configure the container's network, and on the host to configure the host's network, but not to cross this boundary and have the host networkd configure the container's network. Hmm, yes, but I think the problem is the configuration done at interface-creation-time. It seems to me that that configuration currently does not fit naturally in either the host networkd or the container networkd. Well, again, I doubt that configuration exclusivel at interface-creation-time will be useful for more than the most trivial cases, already because as mentioned it would not cover DNS server configuration and thelike. Sure, I'm in agreement, but there are things that can only be configured at interface-creation-time. As a trivial example, the type of the interface. And it looks like for ipvlan you can only choose L2 or L3 mode at creation-time. Additionally, it seems to me that the MAC address, at least, is something that you might want to configure only at creation-time and not change later. networkd considers the MAC address that can be changed for the network you connect to, and can hence change dynamically depending on the network you pick. Hmm, there's indeed a gap here though: as .link files are applied by udev, not by networkd, and udev is not available in containers, .link files are currently not applied at all in containers. It might be an option to do this within networkd instead of udev when it is run in a container. Of course, this will then only cover the props that can be changed with .link files, not the ones that have to be specified at link creation time. For those, things are nasty. I mean, for things like ipvlan which relate to an interface outside of the container, this means we need to create them outside of the container, and thus they need to be configured initially outside of the container. So far we handled all this inside .netdev files, that are processed by networkd. We have limited support for creating these devices also with nspawn (i.e. the --network-veth, --network-macvlan and --network-ipvlan switches), but I'd be really careful with turning them into more than just basic switches, I'd really leave more complex cases with networkd. Now, I am not really sure how would could hook this up... After all as you say it will not be sufficient to create the netdevs once before nspawn uses them, they need to be created before each time before nspawn uses them. As soon as networkd gains a bus interface maybe an option could be to hook up nspawn's --network-interface= with it: if the specified interface doesn't exist, nspawn could synchronously ask networkd to create it. With that in place you could then configure .netdev files outside of the container, and neatly pass them on into the container, without races. Would that fix your issue? If you really want fixed IP addresses, I think this could work: We add configurability for the DHCP server address range in networkd, including taking ranges that contain a single IP address. You could then assign fixed addresses to your containers simply by dropping a .network snippet for them, that only contains a single dhcp range IP address for it. THat should work, no? This would be a nice feature and would work for many use cases. My problem with this solution is that I'm using IPv6. With IPv6, I can set up stateless autoconfiguration to assign IPs to interfaces. In that case the IP is directly determined by the MAC address, so it is not possible (AFAIK?) to specify a range of IPs of length 1 to force that single IP to be assigned to a specific interface. I would somewhat prefer to be using this feature of IPv6, rather than using DHCPv6; and anyway, networkd doesn't support DHCPv6 right now, right? So this doesn't necessarily work for me. True. It's certainly our plan to support it eventually. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org
Re: [systemd-devel] Improve log notice when unprivileged users run journalctl executable
On Wed, 22.04.15 20:07, Gautier Pelloux-Prayer (gaut...@damsy.net) wrote: Actually I posted twich my email (my bad), the real discussion is here: http://lists.freedesktop.org/archives/systemd-devel/2015-March/029119.html Zbigniew Jędrzejewski-Szmek patched it and it should be OK now. Oh indeed, and I even replied to that other thread already, Thanks, 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 3/3] zsh-completion: add missing completions for systemd-nspawn
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1429726059-5463-4-git-send-email-lorusak%40gmail.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] zsh-completion: add missing completions for machinectl
---
shell-completion/zsh/_machinectl | 84 +---
1 file changed, 70 insertions(+), 14 deletions(-)
diff --git a/shell-completion/zsh/_machinectl b/shell-completion/zsh/_machinectl
index c666b7e..2b1b7ed 100644
--- a/shell-completion/zsh/_machinectl
+++ b/shell-completion/zsh/_machinectl
@@ -1,5 +1,20 @@
#compdef machinectl
+__get_available_machines () {
+ls -1 /var/lib/container | {while read -r a b; do echo $a; done;}
+}
+
+_available_machines() {
+local -a _machines
+_machines=(${(fo)$(__get_available_machines)})
+typeset -U _machines
+if [[ -n $_machines ]]; then
+_describe 'machines' _machines
+else
+ _message 'no machines'
+fi
+}
+
(( $+functions[_machinectl_command] )) || _machinectl_command()
{
local -a _machinectl_cmds
@@ -7,23 +22,55 @@
list:List currently running VMs/containers
status:Show VM/container status
show:Show properties of one or more VMs/containers
+start:Start container as a service
login:Get a login prompt on a VM/container
+enable:Enable automatic container start at boot
+disable:Disable automatic container start at boot
poweroff:Power off one or more VMs/containers
reboot:Reboot one or more VMs/containers
terminate:Terminate one or more VMs/containers
kill:Send signal to process or a VM/container
+copy-to:Copy files from the host to a container
+copy-from:Copy files from a container to the host
+bind:Bind mount a path from the host into a container
+
+list-images:Show available container and VM images
+image-status:Show image details
+show-image:Show properties of image
+clone:Clone an image
+rename:Rename an image
+read-only:Mark or unmark image read-only
+remove:Remove an image
+
+pull-tar:Download a TAR container image
+pull-raw:Download a RAW container or VM image
+pull-dkr:Download a DKR container image
+list-transfers:Show list of downloads in progress
+cancel-transfer:Cancel a download
)
+
if (( CURRENT == 1 )); then
_describe -t commands 'machinectl command' _machinectl_cmds || compadd $@
else
local curcontext=$curcontext
cmd=${${_machinectl_cmds[(r)$words[1]:*]%%:*}}
if (( $#cmd )); then
- case $cmd in
-list) msg=no options ;;
-*)
- _sd_machines
- esac
+ if (( CURRENT == 2 )); then
+case $cmd in
+ list*|cancel-transfer|pull-tar|pull-raw|pull-dkr)
+msg=no options ;;
+ start)
+_available_machines ;;
+ *)
+_sd_machines
+esac
+ else
+case $cmd in
+ copy-to|copy-from|bind)
+_files ;;
+ *) msg=no options
+esac
+ fi
else
_message no more options
fi
@@ -33,13 +80,22 @@
_arguments \
{-h,--help}'[Prints a short help text and exits.]' \
'--version[Prints a short version string and exits.]' \
- \*{-p+,--property=}'[Limit output to specified property.]:property:(Name Id
Timestamp TimestampMonotonic Service Scope Leader Class State RootDirectory)' \
- {-a,--all}'[Show all proerties]' \
- (-l,--full)'[Do not ellipsize cgroup members]' \
- '--no-pager[Do not pipe output into a pager]' \
- '--no-ask-password[Do not ask for system passwords]' \
- '--kill-who=[Who to send signal to]:killwho:(leader all)' \
- {-s+,--signal=}'[Which signal to send]:signal:_signals' \
- {-H+,--host=}'[Operate on remote host]:userathost:_sd_hosts_or_user_at_host'
\
- {-P,--privileged}'[Acquire privileges before execution]' \
+ '--no-pager[Do not pipe output into a pager.]' \
+ '--no-legend[Do not show the headers and footers.]' \
+ '--no-ask-password[Do not ask for system passwords.]' \
+ {-H+,--host=}'[Operate on remote
host.]:userathost:_sd_hosts_or_user_at_host' \
+ {-M+,--machine=}'[Operate on local container.]:machine:_sd_machines' \
+ {-p+,--property=}'[Limit output to specified property.]:property:(Name Id
Timestamp TimestampMonotonic Service Scope Leader Class State RootDirectory)' \
+ {-a,--all}'[Show all proerties.]' \
+ {-q,--quiet}'[Suppress output.]' \
+ {-l,--full}'[Do not ellipsize cgroup members.]' \
+ '--kill-who=[Who to send signal to.]:killwho:(leader all)' \
+ {-s+,--signal=}'[Which signal to send.]:signal:_signals' \
+ '--read-only[Create read-only bind mount.]' \
+ '--mkdir[Create directory before bind mounting, if missing.]' \
+ {-n+,--lines=}'[Number of journal entries to show.]:integer' \
+ {-o+,--output=}'[Change journal output mode.]:output modes:_sd_outputmodes' \
+ '--verify=[Verification mode for downloaded images.]:verify:(no checksum
signature)' \
+ '--force[Download image even if already exists.]' \
+ '--dkr-index-url=[Specify the index URL to use for DKR image downloads.]' \
'*::machinectl command:_machinectl_command'
--
2.3.5
___
systemd-devel mailing list
[systemd-devel] [PATCH 3/3] zsh-completion: add missing completions for systemd-nspawn
---
shell-completion/zsh/_systemd-nspawn | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
diff --git a/shell-completion/zsh/_systemd-nspawn
b/shell-completion/zsh/_systemd-nspawn
index ceedb2c..42cdbcd 100644
--- a/shell-completion/zsh/_systemd-nspawn
+++ b/shell-completion/zsh/_systemd-nspawn
@@ -11,34 +11,37 @@ _nspawn-caps(){
}
_arguments \
-{-h,--help}'[Show this help]' \
+{-h,--help}'[Show this help.]' \
+'--version[Print a short version string and exit.]' \
+{--quiet,-q}'[Turns off any status output by the tool itself.]' \
{--directory=,-D+}'[Directory to use as file system root for the namespace
container. If omitted the current directory will be
used.]:directories:_directories' \
+'--template=[Initialize root directory from template directory, if
missing.]:template:_directories' \
+{--ephemeral,-x}'[Run container with snapshot of root directory, and
remove it after exit.]' \
{--image=,-i+}'[Disk image to mount the root directory for the container
from.]' \
{--boot=,-b+}'[Automatically search for an init binary and invoke it
instead of a shell or a user supplied program.]' \
{--user=,-u+}'[Run the command under specified user, create home directory
and cd into it.]' \
{--machine=,-M+}'[Sets the machine name for this container.]' \
'--uuid=[Set the specified uuid for the container.]' \
-'--slice=[Make the container part of the specified slice, instead of the
default machine.slice.]' \
-'--private-network[Turn off networking in the container. This makes all
network interfaces unavailable in the container, with the exception of the
loopback device.]' \
+{--slice=,-S+}'[Make the container part of the specified slice, instead of
the default machine.slice.]' \
'--private-network[Disconnect networking of the container from the host.]'
\
'--network-interface=[Assign the specified network interface to the
container.]' \
'--network-macvlan=[Create a macvlan interface of the specified Ethernet
network interface and add it to the container.]' \
-'--network-veth[Create a virtual Ethernet link (veth) between host and
container.]' \
+'--network-ipvlan=[Create a ipvlan network interface based on an existing
network interface to the container.]' \
+{--network-veth,-n}'[Create a virtual Ethernet link (veth) between host
and container.]' \
'--network-bridge=[Adds the host side of the Ethernet link created with
--network-veth to the specified bridge.]' \
+{--port=,-p+}'[Expose a container IP port on the host.]' \
{--selinux-context=,-Z+}'[Sets the SELinux security context to be used to
label processes in the container.]' \
{--selinux-apifs-context=,-L+}'[Sets the SELinux security context to be
used to label files in the virtual API file systems in the container.]' \
'--capability=[List one or more additional capabilities to grant the
container.]:capabilities:_nspawn-caps' \
-'--drop-capability=[Specify one or more additional capabilities to drop
for the container]' \
---link-journal=[Control whether the container's journal shall be made
visible to the host system.]:options:(no, host, guest, auto) \
+'--drop-capability=[Specify one or more additional capabilities to drop
for the containerm]:capabilities:_nspawn-caps' \
+--link-journal=[Control whether the container's journal shall be made
visible to the host system.]:options:(no host guest auto) \
'-j[Equivalent to --link-journal=guest.]' \
'--read-only[Mount the root file system read only for the container.]' \
'--bind=[Bind mount a file or directory from the host into the
container.]' \
'--bind-ro=[Bind mount a file or directory from the host into the
container (read-only).]' \
+'--tmpfs=[Mount an empty tmpfs to the specified directory.]' \
'--setenv=[Specifies an environment variable assignment to pass to the
init process in the container, in the format NAME=VALUE.]' \
'--share-system[Allows the container to share certain system facilities
with the host.]' \
'--register=[Controls whether the container is registered with
systemd-machined(8).]' \
'--keep-unit[Instead of creating a transient scope unit to run the
container in, simply register the service or scope unit systemd-nspawn has been
invoked in with systemd-machined(8).]' \
-'--personality=[Control the architecture (personality) reported by
uname(2) in the container.]' \
-{--quiet,-q}'[Turns off any status output by the tool itself.]' \
-{--help,-h}'[Print a short help text and exit.]' \
-'--version[Print a short version string and exit.]'
+'--volatile=[Run the system in volatile mode.]:volatile:(no yes state)'
--
2.3.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] zsh-completion: update -M completion for systemd-analyze
---
shell-completion/zsh/_systemd-analyze | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/shell-completion/zsh/_systemd-analyze
b/shell-completion/zsh/_systemd-analyze
index 2c0e543..efafddc 100644
--- a/shell-completion/zsh/_systemd-analyze
+++ b/shell-completion/zsh/_systemd-analyze
@@ -54,5 +54,5 @@ _arguments \
'--from-pattern=[When generating a dependency graph, filter only
origins]:GLOB' \
'--to-pattern=[When generating a dependency graph, filter only
destinations]:GLOB' \
{-H+,--host=}'[Operate on remote
host]:userathost:_sd_hosts_or_user_at_host' \
-{-M+,--machine=}'[Operate on local container]:machine' \
+{-M+,--machine=}'[Operate on local container]:machine:_sd_machines' \
'*::systemd-analyze commands:_systemd_analyze_command'
--
2.3.5
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/3] update zsh completions for systemd-analyze, systemd-nspawn, and machinectl
This is my first time submitting on a mailing list, so go easy on me. Lukas Rusak (3): zsh-completion: add missing completions for machinectl zsh-completion: update -M completion for systemd-analyze zsh-completion: add missing completions for systemd-nspawn shell-completion/zsh/_machinectl | 84 +-- shell-completion/zsh/_systemd-analyze | 2 +- shell-completion/zsh/_systemd-nspawn | 23 +- 3 files changed, 84 insertions(+), 25 deletions(-) -- 2.3.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Service watchdog feature in state ACTIVATING ?
On Wed, 22.04.15 17:59, Hoyer, Marko (ADITG/SW2) (mho...@de.adit-jv.com) wrote: So, I can see that having watchdog support during the activating phase might make sense in this case, but I am not sure this case is strong enough to add it to systemd proper, since it would complicate things for most: it's not a behaviour we can just enable for everybody, it would have to be something we'd have to add an explicit opt-in option for, since most daemons don't work like this. Thx for getting back to this again. An a bit more light weight variant could be adding a second watchdog timeout parameter meant for the activation phase only. This timeout value could be 0 (infinite) by default. This way, the feature is probably invisible for all who are not explicitly setting it. Well, if it's a boolean or a timeout that is configured, I'd prefer not to add either option unless this turns out to be a frequently requested feature... I am just careful with adding even more settings so easily... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] zsh-completion: add missing completions for machinectl
On Wed, 22.04.15 11:07, Lukas Rusak (loru...@gmail.com) wrote:
---
shell-completion/zsh/_machinectl | 84
+---
1 file changed, 70 insertions(+), 14 deletions(-)
diff --git a/shell-completion/zsh/_machinectl
b/shell-completion/zsh/_machinectl
index c666b7e..2b1b7ed 100644
--- a/shell-completion/zsh/_machinectl
+++ b/shell-completion/zsh/_machinectl
@@ -1,5 +1,20 @@
#compdef machinectl
+__get_available_machines () {
+ls -1 /var/lib/container | {while read -r a b; do echo $a; done;}
+}
Hmm, the right way to list running containers is with machinectl
list. The right way to list container images is with machinectl
list-images.
Just listing /var/lib/container is not right, because the we tent to
prefer /var/lib/machines now, and because we support raw images in
those dirs, which carry the .raw suffix which should be removed when
used as machine name.
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 v2] Add support for transient presets, applied on every boot.
On Sat, 21.02.15 02:38, Dimitri John Ledkov (dimitri.j.led...@intel.com) wrote:
Sorry for the late review!
Can you please add a commit description to this, explaining the
precise rationale for this?
---
src/core/main.c | 27 +++
src/core/unit.c | 2 +-
src/shared/install.c | 25 -
src/shared/install.h | 2 +-
4 files changed, 49 insertions(+), 7 deletions(-)
diff --git a/src/core/main.c b/src/core/main.c
index 08f46f5..2656779 100644
--- a/src/core/main.c
+++ b/src/core/main.c
@@ -1207,6 +1207,23 @@ static int write_container_id(void) {
return write_string_file(/run/systemd/container, c);
}
+static int transient_presets(void) {
+struct stat st;
+
+if (lstat(/usr/lib/systemd/system-preset-transient, st) == 0)
+return !!S_ISDIR(st.st_mode);
Please use is_dir() for this, it's slightly nicer to read.
+#ifdef HAVE_SPLIT_USR
+if (lstat(/lib/systemd/system-preset-transient, st) == 0)
+return !!S_ISDIR(st.st_mode);
+#endif
+
+if (lstat(/etc/systemd/system-preset-transient, st) == 0)
+return !!S_ISDIR(st.st_mode);
+
+return 0;
+}
Also, the function should probably return a proper bool instead of
an int. We use C99 bool heavily.
That said, maybe we shouldn't have this function at all, see below.
+
int main(int argc, char *argv[]) {
Manager *m = NULL;
int r, retval = EXIT_FAILURE;
@@ -1619,6 +1636,16 @@ int main(int argc, char *argv[]) {
if (arg_running_as == SYSTEMD_SYSTEM) {
bump_rlimit_nofile(saved_rlimit_nofile);
+// NB! transient presets must be applied before
normal
We try to stick to /* comments */ instead of // comments
+if (transient_presets()) {
+r = unit_file_preset_all(UNIT_FILE_SYSTEM, true,
NULL, UNIT_FILE_PRESET_ENABLE_ONLY, false, NULL, 0);
+if (r 0)
+log_warning_errno(r, Failed to populate
transient preset unit settings, ignoring: %m);
+else
+log_info(Populated transient preset unit
settings.);
+}
Hmm, do we actually need the explicit check with transient_presets()
at all? I mean, it replicates the search path logic, and
unit_file_preset_all() should notice on its own that there are no
preset files in those dirs...
diff --git a/src/shared/install.c b/src/shared/install.c
index 65f1c24..7372e56 100644
--- a/src/shared/install.c
+++ b/src/shared/install.c
@@ -1873,7 +1873,7 @@ UnitFileState unit_file_get_state(
return r 0 ? r : state;
}
-int unit_file_query_preset(UnitFileScope scope, const char
-*root_dir, const char *name) {
+int unit_file_query_preset(UnitFileScope scope, bool runtime, const
-char *root_dir, const char *name) {
Hmm, runtime, or transient? Pick one!
Lennart
--
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] tree-wide: Introduce a dup_cloexec inline helper
- Nicer easier to remember than fcntl(fd, F_DUPFD_CLOEXEC, 3)
- Update CODING_STYLE
- Use it tree-wide
---
CODING_STYLE | 6 +++---
src/import/curl-util.c | 2 +-
src/import/importd.c | 4 ++--
src/journal/cat.c| 2 +-
src/libsystemd-terminal/grdev-drm.c | 4 ++--
src/libsystemd-terminal/idev-evdev.c | 4 ++--
src/libsystemd/sd-bus/bus-message.c | 6 +++---
src/login/inhibit.c | 2 +-
src/login/pam_systemd.c | 2 +-
src/run/run.c| 2 +-
src/shared/copy.c| 2 +-
src/shared/fdset.c | 2 +-
src/shared/install.c | 2 +-
src/shared/util.h| 5 +
14 files changed, 25 insertions(+), 20 deletions(-)
diff --git a/CODING_STYLE b/CODING_STYLE
index a295ca7..19891ce 100644
--- a/CODING_STYLE
+++ b/CODING_STYLE
@@ -233,12 +233,12 @@
fork()ed off a child process, please use _exit() instead of exit(),
so that the exit handlers are not run.
-- Please never use dup(). Use fcntl(fd, F_DUPFD_CLOEXEC, 3)
- instead. For two reason: first, you want O_CLOEXEC set on the new fd
+- Please never use dup(). Use the dup_cloexec() helper instead.
+ For two reasons: first, you want O_CLOEXEC set on the new fd
(see above). Second, dup() will happily duplicate your fd as 0, 1,
2, i.e. stdin, stdout, stderr, should those fds be closed. Given the
special semantics of those fds, it's probably a good idea to avoid
- them. F_DUPFD_CLOEXEC with 3 as parameter avoids them.
+ them.
- When you define a destructor or unref() call for an object, please
accept a NULL object and simply treat this as NOP. This is similar
diff --git a/src/import/curl-util.c b/src/import/curl-util.c
index d390cfb..dfa5acc 100644
--- a/src/import/curl-util.c
+++ b/src/import/curl-util.c
@@ -131,7 +131,7 @@ static int curl_glue_socket_callback(CURLM *curl,
curl_socket_t s, int action, v
* anymore. Hence, duplicate the fds here, and keep a
* copy for epoll which we control after use. */
-fd = fcntl(s, F_DUPFD_CLOEXEC, 3);
+fd = dup_cloexec(s);
if (fd 0)
return -1;
diff --git a/src/import/importd.c b/src/import/importd.c
index d4da4b2..416a43c 100644
--- a/src/import/importd.c
+++ b/src/import/importd.c
@@ -765,7 +765,7 @@ static int method_import_tar_or_raw(sd_bus *bus,
sd_bus_message *msg, void *user
if (!t-local)
return -ENOMEM;
-t-stdin_fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
+t-stdin_fd = dup_cloexec(fd);
if (t-stdin_fd 0)
return -errno;
@@ -826,7 +826,7 @@ static int method_export_tar_or_raw(sd_bus *bus,
sd_bus_message *msg, void *user
if (!t-local)
return -ENOMEM;
-t-stdout_fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
+t-stdout_fd = dup_cloexec(fd);
if (t-stdout_fd 0)
return -errno;
diff --git a/src/journal/cat.c b/src/journal/cat.c
index 2e236f0..9e26e7c 100644
--- a/src/journal/cat.c
+++ b/src/journal/cat.c
@@ -138,7 +138,7 @@ int main(int argc, char *argv[]) {
goto finish;
}
-saved_stderr = fcntl(STDERR_FILENO, F_DUPFD_CLOEXEC, 3);
+saved_stderr = dup_cloexec(STDERR_FILENO);
if (dup3(fd, STDOUT_FILENO, 0) 0 ||
dup3(fd, STDERR_FILENO, 0) 0) {
diff --git a/src/libsystemd-terminal/grdev-drm.c
b/src/libsystemd-terminal/grdev-drm.c
index 066a4d8..deb7e94 100644
--- a/src/libsystemd-terminal/grdev-drm.c
+++ b/src/libsystemd-terminal/grdev-drm.c
@@ -2782,7 +2782,7 @@ static int managed_card_resume_device_fn(sd_bus *bus,
* TakeDevice(). However, lets be safe and use this FD in case
* we really don't have one. There is no harm in doing this
* and our code works fine this way. */
-fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
+fd = dup_cloexec(fd);
if (fd 0) {
log_debug_errno(errno, grdrm: %s/%s: cannot duplicate
fd: %m,
session-name, cm-card.base.name);
@@ -2874,7 +2874,7 @@ static int managed_card_take_device_fn(sd_bus *bus,
return 0;
}
-fd = fcntl(fd, F_DUPFD_CLOEXEC, 3);
+fd = dup_cloexec(fd);
if (fd 0) {
log_debug_errno(errno, grdrm: %s/%s: cannot duplicate fd: %m,
session-name, cm-card.base.name);
diff --git a/src/libsystemd-terminal/idev-evdev.c
b/src/libsystemd-terminal/idev-evdev.c
index 91ae507..c49ba90 100644
--- a/src/libsystemd-terminal/idev-evdev.c
+++ b/src/libsystemd-terminal/idev-evdev.c
@@ -559,7 +559,7 @@ static int managed_evdev_take_device_fn(sd_bus *bus,
if (paused)
return 0;
-fd = fcntl(fd,
Re: [systemd-devel] Setting up network interfaces for containers with --private-network
Lennart Poettering lenn...@poettering.net writes: On Wed, 22.04.15 13:41, Spencer Baugh (sba...@catern.com) wrote: Lennart Poettering lenn...@poettering.net writes: Well, again, I doubt that configuration exclusivel at interface-creation-time will be useful for more than the most trivial cases, already because as mentioned it would not cover DNS server configuration and thelike. Sure, I'm in agreement, but there are things that can only be configured at interface-creation-time. As a trivial example, the type of the interface. And it looks like for ipvlan you can only choose L2 or L3 mode at creation-time. Additionally, it seems to me that the MAC address, at least, is something that you might want to configure only at creation-time and not change later. networkd considers the MAC address that can be changed for the network you connect to, and can hence change dynamically depending on the network you pick. Hmm, there's indeed a gap here though: as .link files are applied by udev, not by networkd, and udev is not available in containers, .link files are currently not applied at all in containers. It might be an option to do this within networkd instead of udev when it is run in a container. Of course, this will then only cover the props that can be changed with .link files, not the ones that have to be specified at link creation time. For those, things are nasty. I mean, for things like ipvlan which relate to an interface outside of the container, this means we need to create them outside of the container, and thus they need to be configured initially outside of the container. So far we handled all this inside .netdev files, that are processed by networkd. We have limited support for creating these devices also with nspawn (i.e. the --network-veth, --network-macvlan and --network-ipvlan switches), but I'd be really careful with turning them into more than just basic switches, I'd really leave more complex cases with networkd. Now, I am not really sure how would could hook this up... After all as you say it will not be sufficient to create the netdevs once before nspawn uses them, they need to be created before each time before nspawn uses them. As soon as networkd gains a bus interface maybe an option could be to hook up nspawn's --network-interface= with it: if the specified interface doesn't exist, nspawn could synchronously ask networkd to create it. With that in place you could then configure .netdev files outside of the container, and neatly pass them on into the container, without races. Would that fix your issue? Yes, that sounds like it would work. This would destroy and recreate the interface on reboot, which is fine for my use case. There might at some point be a desire by someone else to have the interface not be destroyed on reboot. At that point it would just require teaching networkd something about network namespaces, which shouldn't be hard. I don't want that myself, of course. As a stopgap measure until the feature you described is ready, I'll use the .service with PrivateNetwork= and JoinsNamespaceOf= suggestion you made earlier. If you really want fixed IP addresses, I think this could work: We add configurability for the DHCP server address range in networkd, including taking ranges that contain a single IP address. You could then assign fixed addresses to your containers simply by dropping a .network snippet for them, that only contains a single dhcp range IP address for it. THat should work, no? This would be a nice feature and would work for many use cases. My problem with this solution is that I'm using IPv6. With IPv6, I can set up stateless autoconfiguration to assign IPs to interfaces. In that case the IP is directly determined by the MAC address, so it is not possible (AFAIK?) to specify a range of IPs of length 1 to force that single IP to be assigned to a specific interface. I would somewhat prefer to be using this feature of IPv6, rather than using DHCPv6; and anyway, networkd doesn't support DHCPv6 right now, right? So this doesn't necessarily work for me. True. It's certainly our plan to support it eventually. That's in reference to just DHCPv6, right? What about stateless autoconfiguration, out of curiosity? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] zsh-completion: add missing completions for machinectl
Ah, completely missed images. So perhaps something like this would be
better?
machinectl --full --no-legend --no-pager list-images | awk '{print $1}'
as this lists
fedora
fedora-rawhide
instead of
fedora.raw
fedora-rawhide
However this will break if one has spaces in the container name. I would
delimit awk by a tab, but it seems list-images doesn't delimit by tabs. So
I'm not sure what the best solution would be as something like this, ls -1
/var/lib/container | sed 's|\.raw||g' seems kind of silly.
(Apologies for sending twice. I missed the CC)
On Wed, Apr 22, 2015 at 11:20 AM, Lennart Poettering lenn...@poettering.net
wrote:
On Wed, 22.04.15 11:07, Lukas Rusak (loru...@gmail.com) wrote:
---
shell-completion/zsh/_machinectl | 84
+---
1 file changed, 70 insertions(+), 14 deletions(-)
diff --git a/shell-completion/zsh/_machinectl
b/shell-completion/zsh/_machinectl
index c666b7e..2b1b7ed 100644
--- a/shell-completion/zsh/_machinectl
+++ b/shell-completion/zsh/_machinectl
@@ -1,5 +1,20 @@
#compdef machinectl
+__get_available_machines () {
+ls -1 /var/lib/container | {while read -r a b; do echo $a; done;}
+}
Hmm, the right way to list running containers is with machinectl
list. The right way to list container images is with machinectl
list-images.
Just listing /var/lib/container is not right, because the we tent to
prefer /var/lib/machines now, and because we support raw images in
those dirs, which carry the .raw suffix which should be removed when
used as machine name.
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] tree-wide: Introduce a dup_cloexec inline helper
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1429730951-13156-1-git-send-email-crrodriguez%40opensuse.org -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] machinectl login machine fails systemd 219
On Wed, 2015-04-22 at 22:25 +0200, Lennart Poettering wrote: On Fri, 17.04.15 18:40, Keller, Jacob E (jacob.e.kel...@intel.com) wrote: On Wed, 2015-04-15 at 00:07 +0200, Stefan Tatschner wrote: On Di, 2015-04-14 at 21:56 +, Keller, Jacob E wrote: Failed to get machine PTY: Message did not receive a reply (timeout by message bus) I get a notification on the machine itself that it started container getty and then stopped it. It worked earlier so I am not sure what changed. No one on google seems to have this specific error. There is a patch which fixes this problem: http://lists.freedesktop.org/archives/systemd-devel/2015 -February/028603.html git log --grep tells me that is has been already commited as f2273101c21bc59a390379e182e53cd4f07a7e71: http://cgit.freedesktop.org/systemd/systemd/commit/?id=f2273101c21bc59a 390379e182e53cd4f07a7e71 Stay tuned, Stefan I still seem to have this issue with this. I am currently working on compiling upstream git of systemd so I can try running machined from there. Will let you know results. Are you sure you updated both the client machinectl and the machined daemon and restarted it? This works fine here with current git... Lennart I probably didn't update both client and daemon. I'll double check that :) Regards, Jake ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote: Sorry for the late review. What's the precise background of this? Can you elaborate? Is there some feature request for this? What does this actually do? Is the specified key file read from the specified device? The order of keyfile:device sounds weird, no? Shouldn't it be the other way round? Is this specific to Dracut so far? Is this widely used, and something that we really want. First version of the patch that allows rd.luks.key to be specified almost the same way as dracut can read it. The solution creates a temporary mount unit mnt.mount that the generated cryptsetup service wants. The partition where the keyfile is then mounted to /mnt and the absolute path to the keyfile is changed so it points to this temporary mount instead. Well, I'd place this in /run somewhere. Maybe /run/systemd/cryptsetup/mount or so... I'm not sure if temporarily mounting something to /mnt in initrd is safe. If not, what would be a preffered way to do this? What does temporarily mean? When is this unmounted? Also, there's a problem that I'm not sure how to solve. If the keyfile_device is somehow misspecified (for example, the uuid simply isn't valid), the boot stalls. I believe that this was one of the problems in https://bugzilla.redhat.com/show_bug.cgi?id=905683. I was thinking about using udev to verify the uuid and its device, but I'm not sure if this makes sense to do in initrd. Any pointers would be appreciated. Things like this are necessarily racy: at boot time devices are not probed yet, and just start to appear. That means if you enumerate them it is highly likely your block device has not shown up yet, but will so shortly. Hence you need to wait for them. But that means you cannot really distuingish the case not shown up yet, but will from will never show up... Once the above problems are sorted out, an extension of this patch (perhaps another patch?) would be to also support the third argument that rd.luks.key can take in dracut. Which is? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] zsh-completion: add missing completions for machinectl
On Wed, 22.04.15 15:44, Lukas Rusak (loru...@gmail.com) wrote: Here is a rebase of the original patch to include the discussed changes Where? 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] cryptsetup-generator: support rd.luks.key=keyfile:keyfile_device
В Thu, 23 Apr 2015 00:48:38 +0200 Lennart Poettering lenn...@poettering.net пишет: On Fri, 20.02.15 10:56, Jan Synacek (jsyna...@redhat.com) wrote: Sorry for the late review. What's the precise background of this? Can you elaborate? Is there some feature request for this? There are multiple bug reports that switching to dracut with integrated systemd breaks ability to auto-setup encrypted devices using keyfile on external USB stick. What does this actually do? Is the specified key file read from the specified device? It reads keyfile from filesystem on device identifed by keyfile_device. The order of keyfile:device sounds weird, no? Shouldn't it be the other way round? keyfile is mandatory, keyfile_device is optional and can be omitted. I believe dracut looked at all existing devices then. This order makes it easier to omit optional parameter(s). In any case it became dracut API which is too late to change. Is this specific to Dracut so far? Is this widely used, and something that we really want. I can say about dracut only but yes, it is used and it is serious regression when it is used comparing with pre-systemd version. First version of the patch that allows rd.luks.key to be specified almost the same way as dracut can read it. The solution creates a temporary mount unit mnt.mount that the generated cryptsetup service wants. The partition where the keyfile is then mounted to /mnt and the absolute path to the keyfile is changed so it points to this temporary mount instead. Well, I'd place this in /run somewhere. Maybe /run/systemd/cryptsetup/mount or so... I'm not sure if temporarily mounting something to /mnt in initrd is safe. If not, what would be a preffered way to do this? What does temporarily mean? When is this unmounted? To fetch keyfile dracut needs to mount USB stick. This mount is not normally needed after cryptomount setup is completed. Also, there's a problem that I'm not sure how to solve. If the keyfile_device is somehow misspecified (for example, the uuid simply isn't valid), the boot stalls. I believe that this was one of the problems in https://bugzilla.redhat.com/show_bug.cgi?id=905683. I was thinking about using udev to verify the uuid and its device, but I'm not sure if this makes sense to do in initrd. Any pointers would be appreciated. Things like this are necessarily racy: at boot time devices are not probed yet, and just start to appear. That means if you enumerate them it is highly likely your block device has not shown up yet, but will so shortly. Hence you need to wait for them. But that means you cannot really distuingish the case not shown up yet, but will from will never show up... Once the above problems are sorted out, an extension of this patch (perhaps another patch?) would be to also support the third argument that rd.luks.key can take in dracut. Which is? LUKS device to which key applies. Can be wildcarded. Lennart ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 2/2] Add more firewire properties for sound, to be closer to USB and PCI
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1429751139-7651-2-git-send-email-agoode%40google.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3 2/2] Add more firewire properties for sound, to be closer to USB and PCI
USB and PCI soundcards have a nice set of ID_* properties. It would
be handy for firewire soundcards to have the same.
Note that this removes the explicit setting of ID_ID in the firewire
conditional. Because we are now setting ID_SERIAL, ID_ID will come
from later in the file.
---
rules/78-sound-card.rules | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/rules/78-sound-card.rules b/rules/78-sound-card.rules
index bd7a994..04740e8 100644
--- a/rules/78-sound-card.rules
+++ b/rules/78-sound-card.rules
@@ -41,14 +41,17 @@ IMPORT{builtin}=hwdb
SUBSYSTEMS==usb, IMPORT{builtin}=usb_id
SUBSYSTEMS==usb, GOTO=skip_pci
-SUBSYSTEMS==firewire, ATTRS{vendor_name}==?*, ATTRS{model_name}==?*, \
- ENV{ID_BUS}=firewire, ENV{ID_VENDOR}=$attr{vendor_name},
ENV{ID_MODEL}=$attr{model_name}
-SUBSYSTEMS==firewire, ATTRS{guid}==?*, ENV{ID_ID}=firewire-$attr{guid}
+SUBSYSTEMS==firewire, ATTRS{guid}==?*, \
+ ENV{ID_BUS}=firewire, ENV{ID_SERIAL}=$attr{guid},
ENV{ID_SERIAL_SHORT}=$attr{guid}, \
+ ENV{ID_VENDOR_ID}=$attr{vendor}, ENV{ID_MODEL_ID}=$attr{model}, \
+ ENV{ID_VENDOR}=$attr{vendor_name}, ENV{ID_MODEL}=$attr{model_name}
SUBSYSTEMS==firewire, GOTO=skip_pci
SUBSYSTEMS==pci, ENV{ID_BUS}=pci, ENV{ID_VENDOR_ID}=$attr{vendor},
ENV{ID_MODEL_ID}=$attr{device}
LABEL=skip_pci
+# Define ID_ID if ID_BUS and ID_SERIAL are set. This will work for both
+# USB and firewire.
ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==?*,
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}-$env{ID_USB_INTERFACE_NUM}
ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==,
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}
--
2.2.0.rc0.207.ga3a616c
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH v3 1/2] Don't use ALSA card id in ID_ID
The ALSA id sysattr is generated by the sound subsystem and is not
a stable identifier. It is generated though some string manipulation
then made unique if there is a conflict. This means that it is
enumeration-dependent and shouldn't be used for ID_ID.
If ID_ID is supposed to be system-unique, it is not already since
for firewire it is generated from the guid and there are broken
firewire devices that have duplicate guids across devices.
This is tracked for PulseAudio at
https://bugs.freedesktop.org/show_bug.cgi?id=90129.
This is essentially a revert of systemd
ed1b2d9fc7d5c5bfe2a67b0b8ff9e5ea8694268e.
---
rules/78-sound-card.rules | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/rules/78-sound-card.rules b/rules/78-sound-card.rules
index 295f490..bd7a994 100644
--- a/rules/78-sound-card.rules
+++ b/rules/78-sound-card.rules
@@ -49,8 +49,8 @@ SUBSYSTEMS==firewire, GOTO=skip_pci
SUBSYSTEMS==pci, ENV{ID_BUS}=pci, ENV{ID_VENDOR_ID}=$attr{vendor},
ENV{ID_MODEL_ID}=$attr{device}
LABEL=skip_pci
-ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==?*,
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}-$env{ID_USB_INTERFACE_NUM}-$attr{id}
-ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==,
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}-$attr{id}
+ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==?*,
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}-$env{ID_USB_INTERFACE_NUM}
+ENV{ID_SERIAL}==?*, ENV{ID_USB_INTERFACE_NUM}==,
ENV{ID_ID}=$env{ID_BUS}-$env{ID_SERIAL}
IMPORT{builtin}=path_id
--
2.2.0.rc0.207.ga3a616c
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v2 2/2] Add more firewire properties for sound, to be closer to USB and PCI
On Wed, Apr 22, 2015 at 11:17 AM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 21.04.15 17:45, Adam Goode (ago...@google.com) wrote: USB and PCI soundcards have a nice set of ID_* properties. It would be handy for firewire soundcards to have the same. As requested earlier, please document in the commit messsage that this does not eat up ID_ID. In v3, this is now mentioned in the commit message as well as being a comment in the rules file directly. Thanks, Adam ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] util: Fix assertion in split() on missing '
On Wed, 22.04.15 23:20, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello all, today I got a report about crashing systemd (pid 1) by installing a package with a broken unit file. Rebooting also doesn't work as systemd immediately crashes again. It turns out the unit file used a multi-line ExecStart= with ' quoting where the author (accidentally) added a trailing slash after the usual \ escaping of the newline: -- snip - [Unit] Description=test [Service] ExecStart=/bin/echo 'foo \ bar' -- snip - Instead of actually breaking your machine, you can just copy that unit to e. g. /tmp and then run systemd-analyze verify test.service to get the same assertion. Of course this syntax is invalid, but systemd certainly shouldn't spill its guts that hard, but just reject the broken .service file. Simple fix with test case attached. Thanks! Applied! We really should get rid of split() entirely. The code is ugly, and it pretends to do quoting, but actually doesn't do it properly. An unquote_first_word() loop is really the much better option. Would love if somebody would sit down and port this all over... 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] Failure(s) Building Systemd with --enable-resolved
On Tue, 21.04.15 08:39, aaron_wri...@selinc.com (aaron_wri...@selinc.com) wrote: I've been getting a few problems building systemd with --enable-resolved . Any help would be very welcomed. I don't have any problems when compiling with --disable-resolved. The first problem I got was this: CCLD libnss_resolve.la libsystemd_internal_la-bus-message.o (symbol from plugin): warning: memset used with constant zero length parameter; this could be due to transposed parameters /tmp/cc03x1nN.ltrans6.ltrans.o: In function `bus_error_name_to_errno.4725 ': cc03x1nN.ltrans6.o:(.text+0x12bb): undefined reference to `__stop_BUS_ERROR_MAP' cc03x1nN.ltrans6.o:(.text+0x12c2): undefined reference to `__start_BUS_ERROR_MAP' collect2: ld returned 1 exit status Kay made some changes to the build system for this. Can you check if this part works now for you? 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] util: Fix assertion in split() on missing '
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:2015042023.GD3982%40piware.de -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] zsh-completion: add missing completions for machinectl
Appologies, I'm still getting used to this mailing list thing and using git
send-email
---
shell-completion/zsh/_machinectl | 84 +---
1 file changed, 70 insertions(+), 14 deletions(-)
diff --git a/shell-completion/zsh/_machinectl b/shell-completion/zsh/_machinectl
index c666b7e..a81c5c7 100644
--- a/shell-completion/zsh/_machinectl
+++ b/shell-completion/zsh/_machinectl
@@ -1,5 +1,20 @@
#compdef machinectl
+__get_available_machines () {
+machinectl --no-legend list-images | awk '{print $1}' | {while read -r a
b; do echo $a; done;}
+}
+
+_available_machines() {
+local -a _machines
+_machines=(${(fo)$(__get_available_machines)})
+typeset -U _machines
+if [[ -n $_machines ]]; then
+_describe 'machines' _machines
+else
+ _message 'no machines'
+fi
+}
+
(( $+functions[_machinectl_command] )) || _machinectl_command()
{
local -a _machinectl_cmds
@@ -7,23 +22,55 @@
list:List currently running VMs/containers
status:Show VM/container status
show:Show properties of one or more VMs/containers
+start:Start container as a service
login:Get a login prompt on a VM/container
+enable:Enable automatic container start at boot
+disable:Disable automatic container start at boot
poweroff:Power off one or more VMs/containers
reboot:Reboot one or more VMs/containers
terminate:Terminate one or more VMs/containers
kill:Send signal to process or a VM/container
+copy-to:Copy files from the host to a container
+copy-from:Copy files from a container to the host
+bind:Bind mount a path from the host into a container
+
+list-images:Show available container and VM images
+image-status:Show image details
+show-image:Show properties of image
+clone:Clone an image
+rename:Rename an image
+read-only:Mark or unmark image read-only
+remove:Remove an image
+
+pull-tar:Download a TAR container image
+pull-raw:Download a RAW container or VM image
+pull-dkr:Download a DKR container image
+list-transfers:Show list of downloads in progress
+cancel-transfer:Cancel a download
)
+
if (( CURRENT == 1 )); then
_describe -t commands 'machinectl command' _machinectl_cmds || compadd $@
else
local curcontext=$curcontext
cmd=${${_machinectl_cmds[(r)$words[1]:*]%%:*}}
if (( $#cmd )); then
- case $cmd in
-list) msg=no options ;;
-*)
- _sd_machines
- esac
+ if (( CURRENT == 2 )); then
+case $cmd in
+ list*|cancel-transfer|pull-tar|pull-raw|pull-dkr)
+msg=no options ;;
+ start)
+_available_machines ;;
+ *)
+_sd_machines
+esac
+ else
+case $cmd in
+ copy-to|copy-from|bind)
+_files ;;
+ *) msg=no options
+esac
+ fi
else
_message no more options
fi
@@ -33,13 +80,22 @@
_arguments \
{-h,--help}'[Prints a short help text and exits.]' \
'--version[Prints a short version string and exits.]' \
- \*{-p+,--property=}'[Limit output to specified property.]:property:(Name Id
Timestamp TimestampMonotonic Service Scope Leader Class State RootDirectory)' \
- {-a,--all}'[Show all proerties]' \
- (-l,--full)'[Do not ellipsize cgroup members]' \
- '--no-pager[Do not pipe output into a pager]' \
- '--no-ask-password[Do not ask for system passwords]' \
- '--kill-who=[Who to send signal to]:killwho:(leader all)' \
- {-s+,--signal=}'[Which signal to send]:signal:_signals' \
- {-H+,--host=}'[Operate on remote host]:userathost:_sd_hosts_or_user_at_host'
\
- {-P,--privileged}'[Acquire privileges before execution]' \
+ '--no-pager[Do not pipe output into a pager.]' \
+ '--no-legend[Do not show the headers and footers.]' \
+ '--no-ask-password[Do not ask for system passwords.]' \
+ {-H+,--host=}'[Operate on remote
host.]:userathost:_sd_hosts_or_user_at_host' \
+ {-M+,--machine=}'[Operate on local container.]:machine:_sd_machines' \
+ {-p+,--property=}'[Limit output to specified property.]:property:(Name Id
Timestamp TimestampMonotonic Service Scope Leader Class State RootDirectory)' \
+ {-a,--all}'[Show all proerties.]' \
+ {-q,--quiet}'[Suppress output.]' \
+ {-l,--full}'[Do not ellipsize cgroup members.]' \
+ '--kill-who=[Who to send signal to.]:killwho:(leader all)' \
+ {-s+,--signal=}'[Which signal to send.]:signal:_signals' \
+ '--read-only[Create read-only bind mount.]' \
+ '--mkdir[Create directory before bind mounting, if missing.]' \
+ {-n+,--lines=}'[Number of journal entries to show.]:integer' \
+ {-o+,--output=}'[Change journal output mode.]:output modes:_sd_outputmodes' \
+ '--verify=[Verification mode for downloaded images.]:verify:(no checksum
signature)' \
+ '--force[Download image even if already exists.]' \
+ '--dkr-index-url=[Specify the index URL to use for DKR image downloads.]' \
'*::machinectl
[systemd-devel] [PATCH] util: Fix assertion in split() on missing '
Hello all,
today I got a report about crashing systemd (pid 1) by installing a
package with a broken unit file. Rebooting also doesn't work as
systemd immediately crashes again. It turns out the unit file used a
multi-line ExecStart= with ' quoting where the author (accidentally)
added a trailing slash after the usual \ escaping of the newline:
-- snip -
[Unit]
Description=test
[Service]
ExecStart=/bin/echo 'foo \
bar'
-- snip -
Instead of actually breaking your machine, you can just copy that unit
to e. g. /tmp and then run systemd-analyze verify test.service to
get the same assertion.
Of course this syntax is invalid, but systemd certainly shouldn't
spill its guts that hard, but just reject the broken .service file.
Simple fix with test case attached.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From ef581ce6e258ffc0c90f268b6054b83e15374ba6 Mon Sep 17 00:00:00 2001
From: Martin Pitt martin.p...@ubuntu.com
Date: Wed, 22 Apr 2015 23:09:43 +0100
Subject: [PATCH] util: Fix assertion in split() on missing '
When parsing a unit with a trailing slash after an escaped line break, like
ExecStart=/bin/echo 'foo \
bar'
the split() function (through config_parse()) asserted and crashed pid 1:
Assertion 'current[*l + 1] == quotechars[0]' failed at ../src/shared/util.c:583, function split(). Aborting.
Fix this by returning an error in this case (trailing garbage).
Add corresponding test case. Also fix the missing unit argument of
config_parse_exec() in the comment.
https://launchpad.net/bugs/1447243
---
src/shared/util.c | 3 +--
src/test/test-unit-file.c | 15 +++
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/src/shared/util.c b/src/shared/util.c
index 4a04484..6a883d7 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -570,13 +570,12 @@ const char* split(const char **state, size_t *l, const char *separator, bool quo
char quotechars[2] = {*current, '\0'};
*l = strcspn_escaped(current + 1, quotechars);
-if (current[*l + 1] == '\0' ||
+if (current[*l + 1] == '\0' || current[*l + 1] != quotechars[0] ||
(current[*l + 2] !strchr(separator, current[*l + 2]))) {
/* right quote missing or garbage at the end */
*state = current;
return NULL;
}
-assert(current[*l + 1] == quotechars[0]);
*state = current++ + *l + 2;
} else if (quoted) {
*l = strcspn_escaped(current, separator);
diff --git a/src/test/test-unit-file.c b/src/test/test-unit-file.c
index 22ac76d..5a9796d 100644
--- a/src/test/test-unit-file.c
+++ b/src/test/test-unit-file.c
@@ -91,6 +91,7 @@ static void check_execcommand(ExecCommand *c,
static void test_config_parse_exec(void) {
/* int config_parse_exec(
+ const char *unit,
const char *filename,
unsigned line,
const char *section,
@@ -302,6 +303,20 @@ static void test_config_parse_exec(void) {
assert_se(r == 0);
assert_se(c1-command_next == NULL);
+log_info(/* missing ending ' */);
+r = config_parse_exec(NULL, fake, 4, section, 1,
+ LValue, 0, /path 'foo,
+ c, NULL);
+assert_se(r == 0);
+assert_se(c1-command_next == NULL);
+
+log_info(/* missing ending ' with trailing backslash */);
+r = config_parse_exec(NULL, fake, 4, section, 1,
+ LValue, 0, /path 'foo\\,
+ c, NULL);
+assert_se(r == 0);
+assert_se(c1-command_next == NULL);
+
exec_command_free_list(c);
}
--
2.1.4
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
2015-04-22 14:14 GMT+02:00 Lennart Poettering lennart at poettering.net: Well, I really don't want to give networkd the caps for that, sorry. It's a network facing daemon, it should not be able to load kernel modules. But it is okay for networkd to manipulate the firewall directly. The nft manual page states that the iptable_nat module conflicts with the module that deals with nftables nat. Does that mean that the networkd IPMasquerade= functionality will not work if one blacklists iptables_nat? -- 02DFF788 4D30 903A 1CF3 B756 FB48 1514 3148 83A2 02DF F788 http://keys.gnupg.net/pks/lookup?op=vindexsearch=0x314883A202DFF788 Dominick Grift pgpNEepiniQub.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Setting up network interfaces for containers with --private-network
On Wed, 22.04.15 15:52, Spencer Baugh (sba...@catern.com) wrote: As soon as networkd gains a bus interface maybe an option could be to hook up nspawn's --network-interface= with it: if the specified interface doesn't exist, nspawn could synchronously ask networkd to create it. With that in place you could then configure .netdev files outside of the container, and neatly pass them on into the container, without races. Would that fix your issue? Yes, that sounds like it would work. This would destroy and recreate the interface on reboot, which is fine for my use case. I'll add it to the TODO list. It's not actually nspawn that destroys these interfaces, it's the kernel. There might at some point be a desire by someone else to have the interface not be destroyed on reboot. At that point it would just require teaching networkd something about network namespaces, which shouldn't be hard. I don't want that myself, of course. Hmm, I am not sure that that teaching networkd namespacing is that easy or desirable. But anyway, we can discuss this when this comes up. I would somewhat prefer to be using this feature of IPv6, rather than using DHCPv6; and anyway, networkd doesn't support DHCPv6 right now, right? So this doesn't necessarily work for me. True. It's certainly our plan to support it eventually. That's in reference to just DHCPv6, right? What about stateless autoconfiguration, out of curiosity? THe code for that is already in place. 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] tree-wide: Introduce a dup_cloexec inline helper
On Wed, 22.04.15 16:29, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
- Nicer easier to remember than fcntl(fd, F_DUPFD_CLOEXEC, 3)
- Update CODING_STYLE
- Use it tree-wide
I am not convinced this is a good idea like this.
Our own functions tend to return proper negative error codes. This
function should hence do the same, at least.
Also, It shouldn't be called dup_cloexec() I think, since that
misleads people to think it is just a cloexec version of dup(), which
it isn't. Maybe a name like dupfd_cloexec() would be better, since it
doesn't try to be similar named to dup(), and in fact is closer to
F_DUPFD_CLOEXEC that it internall wraps.
+static inline int dup_cloexec(int oldfd)
+{
+return fcntl(oldfd, F_DUPFD_CLOEXEC, STDERR_FILENO + 1);
+}
We place the opening { on the same line as the function name, see
CODING_STYLE.
Also, a comment next to that declaration is probably a good idea, to
explain why this function exists at all, and is better than dup().
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] machinectl login machine fails systemd 219
On Fri, 17.04.15 18:40, Keller, Jacob E (jacob.e.kel...@intel.com) wrote: On Wed, 2015-04-15 at 00:07 +0200, Stefan Tatschner wrote: On Di, 2015-04-14 at 21:56 +, Keller, Jacob E wrote: Failed to get machine PTY: Message did not receive a reply (timeout by message bus) I get a notification on the machine itself that it started container getty and then stopped it. It worked earlier so I am not sure what changed. No one on google seems to have this specific error. There is a patch which fixes this problem: http://lists.freedesktop.org/archives/systemd-devel/2015 -February/028603.html git log --grep tells me that is has been already commited as f2273101c21bc59a390379e182e53cd4f07a7e71: http://cgit.freedesktop.org/systemd/systemd/commit/?id=f2273101c21bc59a 390379e182e53cd4f07a7e71 Stay tuned, Stefan I still seem to have this issue with this. I am currently working on compiling upstream git of systemd so I can try running machined from there. Will let you know results. Are you sure you updated both the client machinectl and the machined daemon and restarted it? This works fine here with current git... 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] systemd startup failed...
On Fri, 20.02.15 19:39, aotto (aotto1...@t-online.de) wrote: Hi, Using fresh installation with suse 13.2 my startup with systemd is failing... THis appears to be the same issue as this one: https://bugs.freedesktop.org/show_bug.cgi?id=89817 Which appears to be a kernel issue, see last comment. 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] journald problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Any chance it may be related to copy on write or whatever? W dniu 2015-04-22 o 00:28, Michał Zegan pisze: Hello. I have just removed my journal files and restarted journald. I then generated sealing keys, saved the verification key. The system worked for maybe an hour or less, I had to power it off, then it was restarted. I tried to verify the journal. This is what happened: PASS: /var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/system.journal 390398: tag failed verification File corruption detected at /var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1000.journal:39 03 98 (of 8388608 bytes, 44%). FAIL: /var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1000.journal (Bad message) 3987a0: tag failed verification File corruption detected at /var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1002.journal:39 87 a0 (of 8388608 bytes, 44%). FAIL: /var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1002.journal (Bad message) 3903a0: tag failed verification File corruption detected at /var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1001.journal:39 03 a0 (of 8388608 bytes, 44%). FAIL: /var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1001.journal (Bad message) What is happening here? It always happens after sealing, no matter what I am doing, all new journal files are corrupted and show this message. Systemd version 219, system is archlinux, kernel 3.19.3-3-ARCH, and filesystem is btrfs if at all important. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVOBDDAAoJEHb1CzgxXKwYwmoP/3pKX6QBcUDxoNRhXzGmGCtG I4ojFgtZ1f6Q3r+RHtne7ph95r8vaHfNyB51qCvK6pWeZRUnpWf/RlB9Ha3UgMXp Hi2OKuWU8lw7jxFszh+LYcI6F0Kp95HQjKKGd0YShCkW2k+Bll6t1hmTSKq73IAF BGBSuddq3J1nkM2cq9lABsYBMviOZZ7XKo3C1uL5eXZRoEw3lCOmyB01dzqa1LYy KeJ0foiHWwERcoMz1Mu0CWqLrbfGq9BS3TdhIyoGRPYDTjBx570XYmNNWJIvuLJr E33JezQn7TTSIElo96bm4sKz+uPvny7prEwxzKy+glchmcM3aLEHIKXT51n1u/wM VwLhhvdzSely5ZQ2SdX7rByFGDgNsW1aIcOGAAVBGawkdVoWlANWlDwVaS4VBEKL 8STz/lN6rkcPRYzncVbHqldZ0Y3jYwHbr5u63jtbQTD0zBbfg7QZmcgSCYjMzHNG +0+DcOvmYIad2dzIjTIPUUPzwBVlNKHMdaxdvBQlAexxU/THH+NN/7kaQh6QntOb 4cdOZBKda0JYPyAKVytvaWabD+r0thDuiJJdQFl2rEV70t/RdVt0ivkRKrN2WokB TXKANrdLhH5hqcddEzWMjUoXZJJPjEfv7cRrszzeIqYJHvaCz7XIAP9+8Un/eIZ6 RfeGOiIZajOIlK1FiZc1 =pb+S -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/3] zsh-completion: add missing completions for machinectl
Here is a rebase of the original patch to include the discussed changes ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] journald problems
On Wed, 22 Apr 2015 00:28:12 +0200 Michał Zegan webczat_...@poczta.onet.pl wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. I have just removed my journal files and restarted journald. I then generated sealing keys, saved the verification key. The system worked for maybe an hour or less, I had to power it off, then it was restarted. I tried to verify the journal. This is what happened: PASS: /var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/system.journal 390398: tag failed verification File corruption detected at /var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1000.journal:3903 98 (of 8388608 bytes, 44%). FAIL: /var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1000.journal (Bad message) 3987a0: tag failed verification File corruption detected at /var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1002.journal:3987 a0 (of 8388608 bytes, 44%). FAIL: /var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1002.journal (Bad message) 3903a0: tag failed verification File corruption detected at /var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1001.journal:3903 a0 (of 8388608 bytes, 44%). FAIL: /var/log/journal/a523e1ef5ffe4b15b9d2698b85e944cd/user-1001.journal (Bad message) What is happening here? It always happens after sealing, no matter what I am doing, all new journal files are corrupted and show this message. Systemd version 219, system is archlinux, kernel 3.19.3-3-ARCH, and filesystem is btrfs if at all important. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBAgAGBQJVNs77AAoJEHb1CzgxXKwYldcP/jGnuCyN1hcQvUHgc4ZS+CkW gCEf59TteLYO/7yVQnrAs4gHFJ6WJlFw8+2L1Lt9gpts2h41oQxyPjhfa6578kSB 2ZC+9McpjLqMctn+hBt3GcPyi/vpr7QAm29sBoPpbCl8hCQQeRbGg5dfUnV0q7ot ueXiO2VMW2wYDz3/0gmqCf7Fh+ChWdBTNAZFrTMqP1hLw0xTukazpNFGm8sStgcp TC2p3JlLmmdCXHxPTGnxFj4jVWuYIOzDajh5GZUPlhmlBy48TKSzF+T3ri6zkOr5 +lyDC1fho5P7shdSN07OlGLSeg6JXC193gBB8WEhUwTs29fZzjyChke0dHVq/WSj 2pYpSr5cncxiUnwR5HTAhBRKHctKP8/5Rqmgu9GCEpy52mtuDsHUQQVbckjMaOYj 9Bz1y+pLNVi5v9AeD3wv/TnxEKeIYd4lwfs9pSutrF/KDo3XxPzys+jgbQvDrxVn zbiKW9X8gc0r6P9qQ5p1jcBndW3dstQExNqGSZCgrCckymDxiSzfhjKQe8G/rD/O 29By4j9vbhHRq/gVpo0MWdnn8I1PCAxpqrftxCLmkEUNCgNAn+xIzwe+G6ppmAv7 4ZnbYfvLAz4Fj0g4QmswCXZB+DEqowrHK5N89BWxRSiY19A87l7BeFDzIFytOfkC LHhedmjVTZXNvgTZXyeE =VsvH -END PGP SIGNATURE- ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel It seems you have exactly the same issue that I had. I described the problem here: http://lists.freedesktop.org/archives/systemd-devel/2015-February/028119.html , but no one answered it. I was just testing this sealing feature and forgot about it because I couldn't make it work, and there was no info what to do with the problem. It seems I'm not the only one who has the issue, you have it on archlinux, and I had it on debian, different kernels, and different filesystem types. pgp4xXrSZvggC.pgp Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] Partially revert patch 11689d2a which force the NOCOW attribute.
On Sun, 12.04.15 20:30, Goffredo Baroncelli (kreij...@libero.it) wrote: From: Goffredo Baroncelli kreij...@inwind.it Partially revert patch 11689d2a, which force the NOCOW attribute for the journal files. This patch was introduced to allievate the perfomances problem that journald shows on the BTRFS filesystem. Because the NOCOW attribute is forced the user can't revert to the old behavior. However NOCOW attribute disables the btrfs checksums, which prevent BTRFS to rebuild a currupted file in an RAIDx filesystem. To continue to set the NOCOW attribute, use the h|H command of systemd-tmpfile. I have now commited a similar patch that replaces the patching of the attribute for new journal files with a warning if we notice the journal file is on btrfs and the flag is not set. I hope this settles the issue! Thanks! 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] Setting up network interfaces for containers with --private-network
On Tue, 21.04.15 15:22, Spencer Baugh (sba...@catern.com) wrote: Also, trivial static IP configuration is seldom sufficient, you at least need to also provide DNS configuration, and if you don't use DHCP or something similar then you need to configure that inside the container anyway. But if you do that you might as well configure the static IP addresses in it too, so what is gained by doing this from a networkd outside of the cotnainer? Or am I misunderstanding the role of networkd? It seems like if I am writing a service that represents the network interface and namespace for this container, I am doing something that networkd should ultimately do. Sure, absolutely. But our idea so far was that networkd should run inside the container to configure the container's network, and on the host to configure the host's network, but not to cross this boundary and have the host networkd configure the container's network. Hmm, yes, but I think the problem is the configuration done at interface-creation-time. It seems to me that that configuration currently does not fit naturally in either the host networkd or the container networkd. Well, again, I doubt that configuration exclusivel at interface-creation-time will be useful for more than the most trivial cases, already because as mentioned it would not cover DNS server configuration and thelike. I am a bit careful with supporting something like this directly in nspawn if it cannot even cover the most basic cases... If you really want fixed IP addresses, I think this could work: We add configurability for the DHCP server address range in networkd, including taking ranges that contain a single IP address. You could then assign fixed addresses to your containers simply by dropping a .network snippet for them, that only contains a single dhcp range IP address for it. THat should work, no? 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] systemd-nspawn trouble
On Tue, 21.04.15 22:43, Tobias Hunger (tobias.hun...@gmail.com) wrote: Hi! Now that systemd 219 is finally available in arch I am playing with systemd-nspawn again. I was trying to run systemd-nspawn --ephemeral, but that failed since I had a read-only image in /var/lib/machines. Why is that not allowed? systemd-nspawn does create its own snapshot of that one after all (which can be read-write). Why does the base image have to be read-write, too? Hmm? This shouldn't fail. What's the precise error message you get? Then I have trouble with systemd-nspawn --network-veth: The host0 interface won't come up and stays in degraded state. On the host i get the following line in the journal: systemd-networkd[509]: ve-XXX : Could not enable IP masquerading: Protocol not available I have an nftables based firewall up and running, so maybe networkd is expecting iptables to be in use? Most likely iptables is compiled as kernel module for you. The module cannot be auto-loaded currently, iptables manually loads it for you on first invocation, networkd doesn't. If you load it manually (by adding it to modules-load.d for example) things should work. I am not sure how to fix this best. I#d rather not have networkd gain support for autoloading kernel modules. Also, it's unlikely to be sufficient, given that nspawn can make use of the iptables bits as well... Maybe we should simply list the iptables kernel modules in src/core/kmod-setup, and then tell people to blacklist them if they really don't want them. 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] systemd-nspawn trouble
On Wed, 22.04.15 13:46, Lennart Poettering (lenn...@poettering.net) wrote: I have an nftables based firewall up and running, so maybe networkd is expecting iptables to be in use? Most likely iptables is compiled as kernel module for you. The module cannot be auto-loaded currently, iptables manually loads it for you on first invocation, networkd doesn't. If you load it manually (by adding it to modules-load.d for example) things should work. I am not sure how to fix this best. I#d rather not have networkd gain support for autoloading kernel modules. Also, it's unlikely to be sufficient, given that nspawn can make use of the iptables bits as well... Maybe we should simply list the iptables kernel modules in src/core/kmod-setup, and then tell people to blacklist them if they really don't want them. I have made such a change now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d3087978a8ee23107cb64aa55ca97aefe9531e2 Any chance you can check if this makes things work for you? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] networkd: introduce vti6 tunnel
This patch add support to create vti6 tunnel
test:
vt6.network
[Match]
Name=wlan0
[Network]
Tunnel=ip6vti
vti6.netdev
[NetDev]
Name=ip6vti
Kind=vti6
[Tunnel]
Local=2a00:ffde:4567:edde::4987
Remote=2001:473:fece:cafe::5179
ip link
11: ip6_vti0@NONE: NOARP mtu 1500 qdisc noop state DOWN mode DEFAULT
group default
link/tunnel6 :: brd ::
12: ip6vti@wlan0: POINTOPOINT,NOARP mtu 1500 qdisc noop state DOWN
mode DEFAULT group default
link/tunnel6 2a00:ffde:4567:edde::4987 peer 2001:473:fece:cafe::5179
---
src/libsystemd/sd-rtnl/rtnl-types.c | 3 +++
src/libsystemd/sd-rtnl/rtnl-types.h | 1 +
src/network/networkd-netdev-tunnel.c | 43
src/network/networkd-netdev-tunnel.h | 1 +
src/network/networkd-netdev.c| 2 ++
src/network/networkd-netdev.h| 2 ++
src/network/networkd-network.c | 1 +
7 files changed, 53 insertions(+)
diff --git a/src/libsystemd/sd-rtnl/rtnl-types.c
b/src/libsystemd/sd-rtnl/rtnl-types.c
index a5c9fdf..d211684 100644
--- a/src/libsystemd/sd-rtnl/rtnl-types.c
+++ b/src/libsystemd/sd-rtnl/rtnl-types.c
@@ -204,6 +204,7 @@ static const char* const
nl_union_link_info_data_table[_NL_UNION_LINK_INFO_DATA_
[NL_UNION_LINK_INFO_DATA_IP6GRETAP_TUNNEL] = ip6gretap,
[NL_UNION_LINK_INFO_DATA_SIT_TUNNEL] = sit,
[NL_UNION_LINK_INFO_DATA_VTI_TUNNEL] = vti,
+[NL_UNION_LINK_INFO_DATA_VTI6_TUNNEL] = vti6,
[NL_UNION_LINK_INFO_DATA_IP6TNL_TUNNEL] = ip6tnl,
};
@@ -238,6 +239,8 @@ static const NLTypeSystem
rtnl_link_info_data_type_systems[_NL_UNION_LINK_INFO_D
.types =
rtnl_link_info_data_iptun_types },
[NL_UNION_LINK_INFO_DATA_VTI_TUNNEL] = { .max =
ELEMENTSOF(rtnl_link_info_data_ipvti_types) - 1,
.types =
rtnl_link_info_data_ipvti_types },
+[NL_UNION_LINK_INFO_DATA_VTI6_TUNNEL] = { .max =
ELEMENTSOF(rtnl_link_info_data_ipvti_types) - 1,
+ .types =
rtnl_link_info_data_ipvti_types },
[NL_UNION_LINK_INFO_DATA_IP6TNL_TUNNEL] = { .max =
ELEMENTSOF(rtnl_link_info_data_ip6tnl_types) - 1,
.types =
rtnl_link_info_data_ip6tnl_types },
diff --git a/src/libsystemd/sd-rtnl/rtnl-types.h
b/src/libsystemd/sd-rtnl/rtnl-types.h
index 72773ea..de1544b 100644
--- a/src/libsystemd/sd-rtnl/rtnl-types.h
+++ b/src/libsystemd/sd-rtnl/rtnl-types.h
@@ -87,6 +87,7 @@ typedef enum NLUnionLinkInfoData {
NL_UNION_LINK_INFO_DATA_IP6GRETAP_TUNNEL,
NL_UNION_LINK_INFO_DATA_SIT_TUNNEL,
NL_UNION_LINK_INFO_DATA_VTI_TUNNEL,
+NL_UNION_LINK_INFO_DATA_VTI6_TUNNEL,
NL_UNION_LINK_INFO_DATA_IP6TNL_TUNNEL,
_NL_UNION_LINK_INFO_DATA_MAX,
_NL_UNION_LINK_INFO_DATA_INVALID = -1
diff --git a/src/network/networkd-netdev-tunnel.c
b/src/network/networkd-netdev-tunnel.c
index 7aa9317..aef2ef4 100644
--- a/src/network/networkd-netdev-tunnel.c
+++ b/src/network/networkd-netdev-tunnel.c
@@ -212,6 +212,31 @@ static int netdev_vti_fill_message_create(NetDev *netdev,
Link *link, sd_rtnl_me
return r;
}
+static int netdev_vti6_fill_message_create(NetDev *netdev, Link *link,
sd_rtnl_message *m) {
+Tunnel *t = VTI6(netdev);
+int r;
+
+assert(netdev);
+assert(link);
+assert(m);
+assert(t);
+assert(t-family == AF_INET6);
+
+r = sd_rtnl_message_append_u32(m, IFLA_VTI_LINK, link-ifindex);
+if (r 0)
+return log_netdev_error_errno(netdev, r, Could not append
IFLA_IPTUN_LINK attribute: %m);
+
+r = sd_rtnl_message_append_in6_addr(m, IFLA_VTI_LOCAL, t-local.in6);
+if (r 0)
+return log_netdev_error_errno(netdev, r, Could not append
IFLA_IPTUN_LOCAL attribute: %m);
+
+r = sd_rtnl_message_append_in6_addr(m, IFLA_VTI_REMOTE,
t-remote.in6);
+if (r 0)
+return log_netdev_error_errno(netdev, r, Could not append
IFLA_IPTUN_REMOTE attribute: %m);
+
+return r;
+}
+
static int netdev_ip6tnl_fill_message_create(NetDev *netdev, Link *link,
sd_rtnl_message *m) {
Tunnel *t = IP6TNL(netdev);
uint8_t proto;
@@ -287,6 +312,9 @@ static int netdev_tunnel_verify(NetDev *netdev, const char
*filename) {
case NETDEV_KIND_VTI:
t = VTI(netdev);
break;
+case NETDEV_KIND_VTI6:
+t = VTI6(netdev);
+break;
case NETDEV_KIND_IP6TNL:
t = IP6TNL(netdev);
break;
@@ -374,6 +402,12 @@ static void vti_init(NetDev *n) {
Tunnel *t = VTI(n);
assert(n);
+
+if (n-kind == NETDEV_KIND_VTI)
+t = VTI(n);
+else
+t = VTI6(n);
+
assert(t);
t-pmtudisc = true;
@@ -447,6 +481,15 @@ const NetDevVTable
[systemd-devel] [PATCH 1/3] networkd: tunnel improve logging
Replaces a lof ot strerror() usage with log_netdev_error_errno()
---
src/network/networkd-netdev-tunnel.c | 240 ++-
1 file changed, 64 insertions(+), 176 deletions(-)
diff --git a/src/network/networkd-netdev-tunnel.c
b/src/network/networkd-netdev-tunnel.c
index 89ad3ee..7aa9317 100644
--- a/src/network/networkd-netdev-tunnel.c
+++ b/src/network/networkd-netdev-tunnel.c
@@ -54,44 +54,24 @@ static int netdev_ipip_fill_message_create(NetDev *netdev,
Link *link, sd_rtnl_m
assert(t-family == AF_INET);
r = sd_rtnl_message_append_u32(m, IFLA_IPTUN_LINK, link-ifindex);
-if (r 0) {
-log_netdev_error(netdev,
- Could not append IFLA_IPTUN_LINK attribute:
%s,
- strerror(-r));
-return r;
-}
+if (r 0)
+return log_netdev_error_errno(netdev, r, Could not append
IFLA_IPTUN_LINK attribute: %m);
r = sd_rtnl_message_append_in_addr(m, IFLA_IPTUN_LOCAL, t-local.in);
-if (r 0) {
-log_netdev_error(netdev,
- Could not append IFLA_IPTUN_LOCAL attribute:
%s,
- strerror(-r));
-return r;
-}
+if (r 0)
+return log_netdev_error_errno(netdev, r, Could not append
IFLA_IPTUN_LOCAL attribute: %m);
r = sd_rtnl_message_append_in_addr(m, IFLA_IPTUN_REMOTE,
t-remote.in);
-if (r 0) {
-log_netdev_error(netdev,
- Could not append IFLA_IPTUN_REMOTE
attribute: %s,
- strerror(-r));
-return r;
-}
+if (r 0)
+return log_netdev_error_errno(netdev, r, Could not append
IFLA_IPTUN_REMOTE attribute: %m);
r = sd_rtnl_message_append_u8(m, IFLA_IPTUN_TTL, t-ttl);
-if (r 0) {
-log_netdev_error(netdev,
- Could not append IFLA_IPTUN_TTL attribute:
%s,
- strerror(-r));
-return r;
-}
+if (r 0)
+return log_netdev_error_errno(netdev, r, Could not append
IFLA_IPTUN_TTL attribute: %m);
r = sd_rtnl_message_append_u8(m, IFLA_IPTUN_PMTUDISC, t-pmtudisc);
-if (r 0) {
-log_netdev_error(netdev,
- Could not append IFLA_IPTUN_PMTUDISC
attribute: %s,
- strerror(-r));
-return r;
-}
+if (r 0)
+return log_netdev_error_errno(netdev, r, Could not append
IFLA_IPTUN_PMTUDISC attribute: %m);
return r;
}
@@ -107,44 +87,24 @@ static int netdev_sit_fill_message_create(NetDev *netdev,
Link *link, sd_rtnl_me
assert(t-family == AF_INET);
r = sd_rtnl_message_append_u32(m, IFLA_IPTUN_LINK, link-ifindex);
-if (r 0) {
-log_netdev_error(netdev,
- Could not append IFLA_IPTUN_LINK attribute:
%s,
- strerror(-r));
-return r;
-}
+if (r 0)
+return log_netdev_error_errno(netdev, r, Could not append
IFLA_IPTUN_LINK attribute: %m);
r = sd_rtnl_message_append_in_addr(m, IFLA_IPTUN_LOCAL, t-local.in);
-if (r 0) {
-log_netdev_error(netdev,
- Could not append IFLA_IPTUN_LOCAL attribute:
%s,
- strerror(-r));
-return r;
-}
+if (r 0)
+return log_netdev_error_errno(netdev, r, Could not append
IFLA_IPTUN_LOCAL attribute: %m);
r = sd_rtnl_message_append_in_addr(m, IFLA_IPTUN_REMOTE,
t-remote.in);
-if (r 0) {
-log_netdev_error(netdev,
- Could not append IFLA_IPTUN_REMOTE
attribute: %s,
- strerror(-r));
-return r;
-}
+if (r 0)
+return log_netdev_error_errno(netdev, r, Could not append
IFLA_IPTUN_REMOTE attribute: %m);
r = sd_rtnl_message_append_u8(m, IFLA_IPTUN_TTL, t-ttl);
-if (r 0) {
-log_netdev_error(netdev,
- Could not append IFLA_IPTUN_TTL attribute:
%s,
- strerror(-r));
-return r;
-}
+if (r 0)
+return log_netdev_error_errno(netdev, r, Could not append
IFLA_IPTUN_TTL attribute: %m);
r = sd_rtnl_message_append_u8(m, IFLA_IPTUN_PMTUDISC, t-pmtudisc);
-if (r 0) {
-log_netdev_error(netdev,
- Could not append IFLA_IPTUN_PMTUDISC
attribute: %s,
- strerror(-r));
-return r;
-}
+if (r 0)
[systemd-devel] [PATCH 3/3] networkd: add man for vti6 tunnel
--- man/systemd.netdev.xml | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/man/systemd.netdev.xml b/man/systemd.netdev.xml index f413739..3bfd01b 100644 --- a/man/systemd.netdev.xml +++ b/man/systemd.netdev.xml @@ -155,6 +155,9 @@ rowentryvarnamevti/varname/entry entryAn IPv4 over IPSec tunnel./entry/row + rowentryvarnamevti6/varname/entry + entryAn IPv6 over IPSec tunnel./entry/row + rowentryvarnamevxlan/varname/entry entryA virtual extensible LAN (vxlan), for connecting Cloud computing deployments./entry/row /tbody @@ -441,7 +444,8 @@ literalgretap/literal, literalip6gre/literal, literalip6gretap/literal, -literalvti/literal, and +literalvti/literal, +literalvti6/literal, and literalip6tnl/literal and accepts the following keys:/para -- 2.3.5 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 3/3] networkd: add man for vti6 tunnel
Patchset imported to github. Pull request: https://github.com/systemd-devs/systemd/compare/master...systemd-mailing-devs:1429692296-5793-3-git-send-email-susant%40redhat.com -- Generated by https://github.com/haraldh/mail2git ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
2015-04-22 13:57 GMT+02:00 Lennart Poettering lenn...@poettering.net: Maybe we should simply list the iptables kernel modules in src/core/kmod-setup, and then tell people to blacklist them if they really don't want them. I have made such a change now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d3087978a8ee23107cb64aa55ca97aefe9531e2 Not everyone is using networkd or nspawn though, so loading this module for everyone is a bit excessive. Why non let nspawn and networkd complain loudly if iptables support is missing? This would also be better in case you have a kernel compiled withouth iptables support. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 14:09, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-22 13:57 GMT+02:00 Lennart Poettering lenn...@poettering.net: Maybe we should simply list the iptables kernel modules in src/core/kmod-setup, and then tell people to blacklist them if they really don't want them. I have made such a change now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d3087978a8ee23107cb64aa55ca97aefe9531e2 Not everyone is using networkd or nspawn though, so loading this module for everyone is a bit excessive. Well, then blacklist the module or don't build it at all. Why non let nspawn and networkd complain loudly if iptables support is missing? This would also be better in case you have a kernel compiled withouth iptables support. For the same reason that iptables doesn't complain loudly but loads it. To be user-friendly and just make things work? 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] Possible systemd segfault switching from 216 to 219 in fedora upgrade
On Fri, 13.03.15 17:59, Will Woods (wwo...@redhat.com) wrote: (Warming up this rally old thread again, sorry for not responding more timely) http://www.freedesktop.org/wiki/Software/systemd/SystemUpdates/ systemd has been implementing this for quite a while, at least for all systems fedup should care for. In this scheme you mark the system for upgrades, you reboot using the old kernel/initrd. This will now enter the special upgrade mode, where you make your changes, and then you reboot again with the new kernel. Yeah, I really wanted that to work, but... when you're replacing literally the entire system *while* part of it is running, stuff gets a little weird. Well, i doubt there's a way around it if you want this to work at all. I mean, the point of the system updates stuff was to only run early-boot services, i.e. udev, journald and systemd itself, whatever storage needs, nothing else. Are these really that problematic? All my efforts to make major-version upgrades work from the system-updates hook ended in weird crashes due to libraries being replaced out from under running binaries, etc. At this point people usually say: Hmm, maybe you need a minimal system you can chroot into and run the upgrade from? ..and that's exactly what the upgrade.img initramfs is! We just need to be able to switch-root from your running system into an upgrade image.. *WITH* your disks mounted in it. But we will not support something like this sorry. Not with full serialization/deserialization. This cannot work. We will not support two-way version transitions like this. Sorry. I also have doubts this will really work. Much of the storage stuff cannot just be left around without its backing daemon. Hence you need to leave those daemons around, and there you go: you will still have old stuff in memory then. I don't really like the new-old-new switchroot stuff, but I haven't got a better solution at the moment. But: if we could use something like systemd-nspawn to: 1) start your old system in a container, 2) let it mount its disks, 3) copy/bind/move those mounts back out to the host somehow Well, we don't allow access to devices from containers. The kernel does not virtualize access to it, and we will not pretend it does. Sorry, this cannot work either. There can raelly only be one udev daemon that manages devices, not two... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] journald-remote problem
Hi, I'm trying to sync my vps log to laptop. They are connected with openvpn. Both laptop and vps are, - Arch Linux - systemd 219-5 - vps: 10.8.0.1 - laptop: 10.8.0.6 It is already secured by openvpn tunnel. So I tried with normal http settings. Services are launched successfully. There is nothing happening in journal. Also there is nothing in /var/log/journal/remote/ . Also I tried example from man page. ~~~ $ ll /tmp/jjj -rw-r--r-- 1 a a 0 Apr 22 15:54 /tmp/jjj $ journalctl -o export | /usr/lib/systemd/systemd-journal-remote -o /tmp/jjj - Received 0 descriptors Using standard input as source. Failed to open output journal /tmp/jjj: Invalid argument Failed to get writer for source stdin: Invalid argument Failed to create source for fd:0 (stdin): Invalid argument ~~~ Am I doing right? I attach config and service file. Thanks. # laptop ; 10.8.0.6 # /etc/systemd/system/systemd-journal-remote.socket [Unit] Description=Journal Remote Sink Socket [Socket] ListenStream=10.8.0.6:19532 [Install] WantedBy=sockets.target # laptop ; 10.8.0.6 # /etc/systemd/system/systemd-journal-remote.service [Unit] Description=Journal Remote Sink Service Requires=systemd-journal-remote.socket [Service] ExecStart=/usr/lib/systemd/systemd-journal-remote \ --listen-http=-3 \ --output=/var/log/journal/remote/ User=systemd-journal-remote Group=systemd-journal-remote PrivateTmp=yes PrivateDevices=yes PrivateNetwork=yes WatchdogSec=10min [Install] Also=systemd-journal-remote.socket # vps ; 10.8.0.1 # /usr/lib/systemd/system/systemd-journal-upload.service [Unit] Description=Journal Remote Upload Service After=network.target [Service] ExecStart=/usr/lib/systemd/systemd-journal-upload \ --save-state User=systemd-journal-upload PrivateTmp=yes PrivateDevices=yes WatchdogSec=20min [Install] WantedBy=multi-user.target # vps ; 10.8.0.1 # /etc/systemd/journal-remote.conf [Upload] URL=http://10.8.0.6 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
2015-04-22 14:14 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Wed, 22.04.15 14:09, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-22 13:57 GMT+02:00 Lennart Poettering lenn...@poettering.net: Maybe we should simply list the iptables kernel modules in src/core/kmod-setup, and then tell people to blacklist them if they really don't want them. I have made such a change now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d3087978a8ee23107cb64aa55ca97aefe9531e2 Not everyone is using networkd or nspawn though, so loading this module for everyone is a bit excessive. Well, then blacklist the module or don't build it at all. That's the wrong way around. Why non let nspawn and networkd complain loudly if iptables support is missing? This would also be better in case you have a kernel compiled withouth iptables support. For the same reason that iptables doesn't complain loudly but loads it. To be user-friendly and just make things work? iptables loads it on-demand, If nspawn or networkd would load it on-demand, I would have no problem with it. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd-nspawn trouble
On Wed, 22.04.15 14:22, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-22 14:14 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Wed, 22.04.15 14:09, Michael Biebl (mbi...@gmail.com) wrote: 2015-04-22 13:57 GMT+02:00 Lennart Poettering lenn...@poettering.net: Maybe we should simply list the iptables kernel modules in src/core/kmod-setup, and then tell people to blacklist them if they really don't want them. I have made such a change now: http://cgit.freedesktop.org/systemd/systemd/commit/?id=1d3087978a8ee23107cb64aa55ca97aefe9531e2 Not everyone is using networkd or nspawn though, so loading this module for everyone is a bit excessive. Well, then blacklist the module or don't build it at all. That's the wrong way around. Nah, I disagree. We do this for a number of modules now. I mean, we load tons of modules automatically, even if you don't use them. For example, my laptop always loads the bluetooth modules, even though I never used bluetooth. We always load more kmods than strictly necessary, simply to ensure a good user experience, and so we should do this in this case too. And the blacklist is a good answer to give the user control, if he wants to opt out of some modules. (Also note that this is a non-issue on distros like Fedora, where the kmod is built-in anyway.) Why non let nspawn and networkd complain loudly if iptables support is missing? This would also be better in case you have a kernel compiled withouth iptables support. For the same reason that iptables doesn't complain loudly but loads it. To be user-friendly and just make things work? iptables loads it on-demand, If nspawn or networkd would load it on-demand, I would have no problem with it. Well, I really don't want to give networkd the caps for that, sorry. It's a network facing daemon, it should not be able to load kernel modules. 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] systemd-nspawn trouble
2015-04-22 14:22 GMT+02:00 Michael Biebl mbi...@gmail.com: 2015-04-22 14:14 GMT+02:00 Lennart Poettering lenn...@poettering.net: On Wed, 22.04.15 14:09, Michael Biebl (mbi...@gmail.com) wrote: Not everyone is using networkd or nspawn though, so loading this module for everyone is a bit excessive. Well, then blacklist the module or don't build it at all. [..] For the same reason that iptables doesn't complain loudly but loads it. To be user-friendly and just make things work? And making everyone who doesn't want this feature jump through hoops and having them blacklist the module is not user-friendly at all. Least of it, it's not really intuitive and discoverable, how this module got loaded in the first place. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
