Re: [systemd-devel] systemd-networkd bridge with DHCP working
On Sat, Mar 22, 2014 at 5:06 AM, poma pomidorabelis...@gmail.com wrote: systemd-networkd bridge dhcp OK https://bugzilla.redhat.com/attachment.cgi?id=877526 Thanks for reporting back. Cheers, Tom ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] A potentially cross platform solution forprocess containment in init applications
* On Friday, 21 March 2014 19:42, Greg KH gre...@linuxfoundation.org wrote: Great, I suggest you try it out and see how it works. Patches are always gladly accepted. I'm not so sure of that, but if you say so... -- Benjamin SANS ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] stopping a systemd-nspwan container
Hello, I had created a container according to systemd-nspwan man page and ran it by: systemd-nspawn -D/srv/mycontainer I killed it by pkill systemd-nspaw (and not by poweroff from within the container). Now, running machinectl shows that the container still runs: machinectl MACHINE CONTAINER SERVICE mycontainer container nspawn 1 machines listed. but the following is strange: Running: systemd-nspawn -D/srv/mycontainer gives: Spawning namespace container on /srv/mycontainer (console is /dev/pts/2). Init process in the container running as PID 2305. Failed to register machine: File exists Container failed with error code 239. (and running it again gives the same result but with a different pid number). Is there a way to shut down the container which is running in such a scenario ? regards, Kevin ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] domain: grab the domain's parent lock only when needed
On 03/21/2014 12:35 PM, Djalal Harouni wrote: I've two questions: 1) Can we improve it in ordre to reduce the lock hold time ? We don't consider that a very frequent operation, so we never thought about optimizing this code path. What use case do you have in mind so that performance would matter much? currently creating a domain will make create/disconnect/open... buses and endpoints on the parent of that domain block, these are separated operations on different domains. I don't quite follow. Can you elaborate? Also it seems that now there is only support for one level of nested domains? will this be increased? I don't think so. What's your use case here? 2) What about creating custom endpoints on the bus that was already unrefed ? IMHO this is the same scenario! That shouldn't happen of course. We've been dealing with locking in that area quite a bit, but we might have overlooked something. Please send a patch if you see such an unsafe locking scenario. Hmm perhaps this can be improved by taking a ref ASAP and revalidate objects by checking the *-disconnected ? -disconnected isn't so much of an issue, and we do check for it where necessary. Apart from that, users that store a pointer to any object should take a reference, so it can't disappear underneath them. But again, if you think we've overlooked anything, let us know. Reviewing all these details is certainly much appreciated. Thanks, Daniel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/1] sd-rtnl: Introduce container parsing
Introducing generic container parsing . Now supported for type
FLA_INFO_KIND and IFLA_VLAN_ID which can be extended to other
container parsing which is based on table based look up.
---
src/libsystemd/sd-rtnl/rtnl-internal.h | 20 +
src/libsystemd/sd-rtnl/rtnl-message.c | 79 +++---
src/libsystemd/sd-rtnl/rtnl-util.c | 31 +
src/libsystemd/sd-rtnl/rtnl-util.h | 2 +
src/libsystemd/sd-rtnl/test-rtnl.c | 13 +-
5 files changed, 138 insertions(+), 7 deletions(-)
diff --git a/src/libsystemd/sd-rtnl/rtnl-internal.h
b/src/libsystemd/sd-rtnl/rtnl-internal.h
index f011dbe..eb30682 100644
--- a/src/libsystemd/sd-rtnl/rtnl-internal.h
+++ b/src/libsystemd/sd-rtnl/rtnl-internal.h
@@ -85,6 +85,15 @@ struct sd_rtnl {
sd_event *event;
};
+struct rtnl_container {
+unsigned short container_type;
+
+size_t *rta_offset_tb;
+unsigned short rta_tb_size;
+
+LIST_FIELDS(struct rtnl_container, container);
+};
+
struct sd_rtnl_message {
RefCount n_ref;
@@ -96,6 +105,10 @@ struct sd_rtnl_message {
size_t next_rta_offset; /* offset from hdr to next rta */
size_t *rta_offset_tb;
unsigned short rta_tb_size;
+struct rtnl_container *container_list[RTNL_CONTAINER_DEPTH];
+
+LIST_HEAD(struct rtnl_container, containers);
+
bool sealed:1;
};
@@ -112,6 +125,13 @@ int rtnl_message_parse(sd_rtnl_message *m,
struct rtattr *rta,
unsigned int rt_len);
+int rtnl_container_new(struct rtnl_container **ret, uint16_t container_type);
+int rtnl_message_parse_container(sd_rtnl_message *m,
+ uint8_t type,
+ uint8_t tb_size,
+ struct rtattr *rta,
+ unsigned int rt_len);
+
/* Make sure callbacks don't destroy the rtnl connection */
#define RTNL_DONT_DESTROY(rtnl) \
_cleanup_rtnl_unref_ _unused_ sd_rtnl *_dont_destroy_##rtnl =
sd_rtnl_ref(rtnl)
diff --git a/src/libsystemd/sd-rtnl/rtnl-message.c
b/src/libsystemd/sd-rtnl/rtnl-message.c
index e243c7b..c1ade55 100644
--- a/src/libsystemd/sd-rtnl/rtnl-message.c
+++ b/src/libsystemd/sd-rtnl/rtnl-message.c
@@ -58,6 +58,7 @@ int message_new(sd_rtnl *rtnl, sd_rtnl_message **ret, size_t
initial_size) {
m-hdr-nlmsg_flags = NLM_F_REQUEST | NLM_F_ACK;
m-sealed = false;
+LIST_HEAD_INIT(m-containers);
if (rtnl)
m-rtnl = sd_rtnl_ref(rtnl);
@@ -276,10 +277,18 @@ sd_rtnl_message *sd_rtnl_message_ref(sd_rtnl_message *m) {
}
sd_rtnl_message *sd_rtnl_message_unref(sd_rtnl_message *m) {
+struct rtnl_container *i, *j;
+
if (m REFCNT_DEC(m-n_ref) = 0) {
sd_rtnl_unref(m-rtnl);
free(m-hdr);
free(m-rta_offset_tb);
+
+LIST_FOREACH_SAFE(container, i, j, m-containers) {
+free(i-rta_offset_tb);
+free(i);
+}
+
free(m);
}
@@ -752,6 +761,22 @@ int sd_rtnl_message_open_container(sd_rtnl_message *m,
unsigned short type) {
return -ENOTSUP;
}
+int sd_rtnl_message_enter_container(sd_rtnl_message *m, unsigned short type) {
+struct rtnl_container *itr;
+
+LIST_FOREACH(container, itr, m-containers) {
+if (itr-container_type == type)
+break;
+}
+
+if(!itr)
+return -ENODATA;
+
+m-container_list[m-n_containers++] = itr;
+
+return 0;
+}
+
int sd_rtnl_message_close_container(sd_rtnl_message *m) {
assert_return(m, -EINVAL);
assert_return(!m-sealed, -EPERM);
@@ -807,18 +832,34 @@ int sd_rtnl_message_read(sd_rtnl_message *m, unsigned
short *type, void **data)
}
int rtnl_message_read_internal(sd_rtnl_message *m, unsigned short type, void
**data) {
+size_t *rta_offset;
+
assert_return(m, -EINVAL);
assert_return(m-sealed, -EPERM);
assert_return(data, -EINVAL);
assert_return(m-rta_offset_tb, -EINVAL);
assert_return(type m-rta_tb_size, -EINVAL);
-if(!m-rta_offset_tb[type])
-return -ENODATA;
+/* We are not inside a container */
+if(!m-n_containers) {
+if(!m-rta_offset_tb[type])
+return -ENODATA;
-*data = RTA_DATA((struct rtattr *)((uint8_t *) m-hdr +
m-rta_offset_tb[type]));
+rta_offset = m-rta_offset_tb[type];
+} else {
+struct rtnl_container *c;
-return 0;
+c = m-container_list[m-n_containers - 1];
+
+if(!c-rta_offset_tb[type])
+return -ENODATA;
+
+rta_offset = c-rta_offset_tb[type];
+}
+
+*data = RTA_DATA((struct rtattr *)((uint8_t *) m-hdr
Re: [systemd-devel] [PATCH] README: Correct EFI requirements
On Sat, Mar 22, 2014 at 1:41 AM, Thomas Bächler tho...@archlinux.org wrote: systemd does not need or use CONFIG_EFI_VARS anywhere, this should be CONFIG_EFIVAR_FS instead. --- README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Applied. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] domain: grab the domain's parent lock only when needed
On Fri, Mar 21, 2014 at 12:35 PM, Djalal Harouni tix...@opendz.org wrote:
On Thu, Mar 20, 2014 at 10:58:21AM +0100, Daniel Mack wrote:
/* link into parent domain */
if (parent) {
What if 'parent' was already unrefed at this point? That can happen any
time as soon we give up the lock.
Ok yes, but in that case what about the first 'parent' check at line
259 ? we can also race against it? I thought that since we are at this
point, we are sure that the parent won't be unrefed!
The caller should be the parent itself, and as long as the caller has
a file (handle.c) open, the domain of the caller should be pinned into
memory.
Kay
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] domain: grab the domain's parent lock only when needed
On Sat, Mar 22, 2014 at 3:43 PM, Daniel Mack dan...@zonque.org wrote: On 03/21/2014 12:35 PM, Djalal Harouni wrote: I've two questions: 1) Can we improve it in ordre to reduce the lock hold time ? We don't consider that a very frequent operation, so we never thought about optimizing this code path. What use case do you have in mind so that performance would matter much? currently creating a domain will make create/disconnect/open... buses and endpoints on the parent of that domain block, these are separated operations on different domains. I don't quite follow. Can you elaborate? Creating domains and buses are relatively expensive system operations, they involve udev, device node creation, sysfs/driver-core interaction. If you think it's worth, please try it, we just took the easy road so far, not sure how much we can really optimize here. Also it seems that now there is only support for one level of nested domains? will this be increased? I don't think so. What's your use case here? We never tried, but the code was supposed to allow stacking of them. I'll fix it. 2) What about creating custom endpoints on the bus that was already unrefed ? IMHO this is the same scenario! That shouldn't happen of course. We've been dealing with locking in that area quite a bit, but we might have overlooked something. Please send a patch if you see such an unsafe locking scenario. Hmm perhaps this can be improved by taking a ref ASAP and revalidate objects by checking the *-disconnected ? -disconnected isn't so much of an issue, and we do check for it where necessary. Apart from that, users that store a pointer to any object should take a reference, so it can't disappear underneath them. But again, if you think we've overlooked anything, let us know. Reviewing all these details is certainly much appreciated. I'll add a few more disconnected checks before we link into the parent objects. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] domain: grab the domain's parent lock only when needed
On Sat, Mar 22, 2014 at 07:37:38PM +0100, Kay Sievers wrote: On Sat, Mar 22, 2014 at 3:43 PM, Daniel Mack dan...@zonque.org wrote: Also it seems that now there is only support for one level of nested domains? will this be increased? I don't think so. What's your use case here? We never tried, but the code was supposed to allow stacking of them. I'll fix it. Yes I was thinking of applications that create domains, they wont work if they are inside a container domain! 2) What about creating custom endpoints on the bus that was already unrefed ? IMHO this is the same scenario! That shouldn't happen of course. We've been dealing with locking in that area quite a bit, but we might have overlooked something. Please send a patch if you see such an unsafe locking scenario. Hmm perhaps this can be improved by taking a ref ASAP and revalidate objects by checking the *-disconnected ? -disconnected isn't so much of an issue, and we do check for it where necessary. Apart from that, users that store a pointer to any object should take a reference, so it can't disappear underneath them. But again, if you think we've overlooked anything, let us know. Reviewing all these details is certainly much appreciated. I'll add a few more disconnected checks before we link into the parent objects. Yes, I've located some sites, and I'm trying to do more tests... I'll get back to you, Thanks Daniel, Kay! Kay -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] domain: grab the domain's parent lock only when needed
On Sat, Mar 22, 2014 at 7:56 PM, Djalal Harouni tix...@opendz.org wrote: On Sat, Mar 22, 2014 at 07:37:38PM +0100, Kay Sievers wrote: On Sat, Mar 22, 2014 at 3:43 PM, Daniel Mack dan...@zonque.org wrote: Also it seems that now there is only support for one level of nested domains? will this be increased? I don't think so. What's your use case here? We never tried, but the code was supposed to allow stacking of them. I'll fix it. Yes I was thinking of applications that create domains, they wont work if they are inside a container domain! Domain creation at the moment is limited to privileged processes, because we have no limits for accounting or other safeguards in place. Domains are a conceptually bit closer to an OS container, applications should see a custom endpoint or can create their own private buses in the domain they run in. 2) What about creating custom endpoints on the bus that was already unrefed ? IMHO this is the same scenario! That shouldn't happen of course. We've been dealing with locking in that area quite a bit, but we might have overlooked something. Please send a patch if you see such an unsafe locking scenario. Hmm perhaps this can be improved by taking a ref ASAP and revalidate objects by checking the *-disconnected ? -disconnected isn't so much of an issue, and we do check for it where necessary. Apart from that, users that store a pointer to any object should take a reference, so it can't disappear underneath them. But again, if you think we've overlooked anything, let us know. Reviewing all these details is certainly much appreciated. I'll add a few more disconnected checks before we link into the parent objects. Yes, I've located some sites, and I'm trying to do more tests... I'll get back to you, Thanks Daniel, Kay! I've committed a few more guards which check for disconnected, right before we try to link into the parent object. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 2/2] domain: grab the domain's parent lock only when needed
On Sat, Mar 22, 2014 at 08:28:38PM +0100, Kay Sievers wrote: On Sat, Mar 22, 2014 at 7:56 PM, Djalal Harouni tix...@opendz.org wrote: On Sat, Mar 22, 2014 at 07:37:38PM +0100, Kay Sievers wrote: On Sat, Mar 22, 2014 at 3:43 PM, Daniel Mack dan...@zonque.org wrote: Also it seems that now there is only support for one level of nested domains? will this be increased? I don't think so. What's your use case here? We never tried, but the code was supposed to allow stacking of them. I'll fix it. Yes I was thinking of applications that create domains, they wont work if they are inside a container domain! Domain creation at the moment is limited to privileged processes, Yes! because we have no limits for accounting or other safeguards in place. Domains are a conceptually bit closer to an OS container, applications should see a custom endpoint or can create their own private buses in the domain they run in. Ok, thanks for the explanation. 2) What about creating custom endpoints on the bus that was already unrefed ? IMHO this is the same scenario! That shouldn't happen of course. We've been dealing with locking in that area quite a bit, but we might have overlooked something. Please send a patch if you see such an unsafe locking scenario. Hmm perhaps this can be improved by taking a ref ASAP and revalidate objects by checking the *-disconnected ? -disconnected isn't so much of an issue, and we do check for it where necessary. Apart from that, users that store a pointer to any object should take a reference, so it can't disappear underneath them. But again, if you think we've overlooked anything, let us know. Reviewing all these details is certainly much appreciated. I'll add a few more disconnected checks before we link into the parent objects. Yes, I've located some sites, and I'm trying to do more tests... I'll get back to you, Thanks Daniel, Kay! I've committed a few more guards which check for disconnected, right before we try to link into the parent object. Yep, I see it now, commit e7f6ec74d3f that was fast ;-) Thanks -- Djalal Harouni http://opendz.org ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] stopping a systemd-nspwan container
On Sat, Mar 22, 2014 at 04:35:19PM +0200, Kevin Wilson wrote: Hello, I had created a container according to systemd-nspwan man page and ran it by: systemd-nspawn -D/srv/mycontainer I killed it by pkill systemd-nspaw (and not by poweroff from within the container). Now, running machinectl shows that the container still runs: machinectl MACHINE CONTAINER SERVICE mycontainer container nspawn 1 machines listed. but the following is strange: Running: systemd-nspawn -D/srv/mycontainer gives: Spawning namespace container on /srv/mycontainer (console is /dev/pts/2). Init process in the container running as PID 2305. Failed to register machine: File exists Container failed with error code 239. (and running it again gives the same result but with a different pid number). Is there a way to shut down the container which is running in such a scenario ? Hmm, I'm able to shut it down gracefully. I frequently do package builds in systemd-nspawn. Reading your email, I did this below test: On one terminal: $ systemd-nspawn -D /srv/testcontainer Spawning container testcontainer on /srv/testcontainer. Press ^] three times within 1s to abort execution. On another terminal, invoke machinectl: $ machinectl MACHINE CONTAINER SERVICE testcontainercontainer nspawn 1 machines listed. Kill the systemd-nspawn process: $ pkill systemd-nspawn At this point, on the other terminal you see KILL signal invokcation: [. . .] -bash-4.2# Container testcontainer terminated by signal KILL. $ Invoke machinectl again: $ machinectl MACHINE CONTAINER SERVICE 0 machines listed. $ machinectl status testcontainer Could not get path to machine: No machine 'testcontainer' known $ Versions: $ uname -r; rpm -q systemd 3.13.4-200.fc20.x86_64 systemd-210-7.fc21.x86_64 -- /kashyap ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] stopping a systemd-nspwan container
Hi, I tried again and now it did work. maybe I was wrong somewhere, sorry. KW On Sat, Mar 22, 2014 at 10:40 PM, Kashyap Chamarthy kcham...@redhat.comwrote: On Sat, Mar 22, 2014 at 04:35:19PM +0200, Kevin Wilson wrote: Hello, I had created a container according to systemd-nspwan man page and ran it by: systemd-nspawn -D/srv/mycontainer I killed it by pkill systemd-nspaw (and not by poweroff from within the container). Now, running machinectl shows that the container still runs: machinectl MACHINE CONTAINER SERVICE mycontainer container nspawn 1 machines listed. but the following is strange: Running: systemd-nspawn -D/srv/mycontainer gives: Spawning namespace container on /srv/mycontainer (console is /dev/pts/2). Init process in the container running as PID 2305. Failed to register machine: File exists Container failed with error code 239. (and running it again gives the same result but with a different pid number). Is there a way to shut down the container which is running in such a scenario ? Hmm, I'm able to shut it down gracefully. I frequently do package builds in systemd-nspawn. Reading your email, I did this below test: On one terminal: $ systemd-nspawn -D /srv/testcontainer Spawning container testcontainer on /srv/testcontainer. Press ^] three times within 1s to abort execution. On another terminal, invoke machinectl: $ machinectl MACHINE CONTAINER SERVICE testcontainercontainer nspawn 1 machines listed. Kill the systemd-nspawn process: $ pkill systemd-nspawn At this point, on the other terminal you see KILL signal invokcation: [. . .] -bash-4.2# Container testcontainer terminated by signal KILL. $ Invoke machinectl again: $ machinectl MACHINE CONTAINER SERVICE 0 machines listed. $ machinectl status testcontainer Could not get path to machine: No machine 'testcontainer' known $ Versions: $ uname -r; rpm -q systemd 3.13.4-200.fc20.x86_64 systemd-210-7.fc21.x86_64 -- /kashyap ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
