Re: [systemd-devel] kdbus refactoring?
On Sun, Nov 08, 2015 at 10:39:43PM +0100, Richard Weinberger wrote: > On Sun, Nov 8, 2015 at 10:35 PM, Greg KH wrote: > > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote: > >> Hi all, > >> > >> after reading on the removal of kdbus from Rawhide[1] I've searched > >> the mailinglist archives for more details but didn't find anything. > >> So, what are your plans? > >> > >> [1] > >> https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html > > > > As that link said, based on the result of the code being in Rawhide, it > > is now being reworked / redesigned. The result will be posted for > > review "when it's ready". > > If you rework/redesign something you have to know what you want to change. > That's why I was asking for the plan... Since when do people post "plans" or "design documents" on lkml without real code? Again, code will be posted when it's ready, like any other kernel submission. thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus refactoring?
On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote: > Hi all, > > after reading on the removal of kdbus from Rawhide[1] I've searched > the mailinglist archives for more details but didn't find anything. > So, what are your plans? > > [1] https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html As that link said, based on the result of the code being in Rawhide, it is now being reworked / redesigned. The result will be posted for review "when it's ready". thanks, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] kdbus refactoring?
On Sun, Nov 8, 2015 at 10:35 PM, Greg KH wrote: > On Sun, Nov 08, 2015 at 10:06:31PM +0100, Richard Weinberger wrote: >> Hi all, >> >> after reading on the removal of kdbus from Rawhide[1] I've searched >> the mailinglist archives for more details but didn't find anything. >> So, what are your plans? >> >> [1] https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html > > As that link said, based on the result of the code being in Rawhide, it > is now being reworked / redesigned. The result will be posted for > review "when it's ready". If you rework/redesign something you have to know what you want to change. That's why I was asking for the plan... -- Thanks, //richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] kdbus refactoring?
Hi all, after reading on the removal of kdbus from Rawhide[1] I've searched the mailinglist archives for more details but didn't find anything. So, what are your plans? [1] https://lists.fedoraproject.org/pipermail/kernel/2015-October/006011.html -- Thanks, //richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: Removing RequiresOverridable= and RequisiteOverridable=?
Grr, my first reply should have gone to the mailing list... 2015-11-08 21:03 GMT+01:00 Lennart Poettering : > On Sun, 08.11.15 19:40, Michael Biebl (mbi...@gmail.com) wrote: > >> 2015-11-08 19:10 GMT+01:00 Lennart Poettering : >> > Heya! >> > >> > At systemd.conf we discussed whether we can remove the unit dependency >> > types RequiresOverridable= and RequisiteOverridable=. I am pretty sure >> > they are pretty much unused in the wild, and hard to grok at all, and >> > hence, in order to clean things up a bit, we should really get rid of >> > it. >> >> https://codesearch.debian.net shows a few hits: >> >> RequiresOverridable= >> https://codesearch.debian.net/perpackage-results/RequiresOverridable/2/page_0 >> → golang-github-coreos-go-systemd, dracut, systemd-ui, fleet >> >> RequisiteOverridable= >> https://codesearch.debian.net/perpackage-results/RequisiteOverridable/2/page_0 >> → mandos, systemd-ui, golang-github-coreos-go-systemd, fleet >> >> >> The only interesting cases are probably dracut's rootfs-generator.sh >> using RequiresOverridable Do you have any concerns regarding dracut? Harald, this is probably for you and mandos using RequisiteOverridable. > > Hmm, how does the usage in "mandos" look like? http://sources.debian.net/src/mandos/1.7.1-1/mandos.service/?hl=11#L11 > I'd probably make RequiresOverridable= a legacy alias for Requires= > when removing it. Would this break anything? -- 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] Property 'MemoryLimit' is RO when using the D-Bus API
On Fri, 06.11.15 18:38, Francis Moreau (francis.m...@gmail.com) wrote: > Hi, > > I'm trying to change the MemoryLimit property of one the service unit > running on my system by using 'busctl set-property ...' but getting > the following error : > >Property 'MemoryLimit' is not writable. > > However using 'systemctl set-property' works as expected. > > I thought that 'systemctl set-property' was basically doing the same > D-Bus thing like my former test did but apparently not. > > Could anybody enlight me why I can't use busctl to set the MemoryLimit > property and why 'systemctl set-property' gives a different result ? We never hooked that up, that's all.. So, in systemd we have an explicit call SetUnitProperties() that is independent of the dbus-mandated Set() calls for the Properties interface. We do this mostly to allow atomic changes to multiple properties but also to be a step closer to unit file behaviour regarding assigning lists of settings to a property, so that it's easy to extend ratehr than reset properties that take lists. In all our tools we use SetUnitProperties() exclusively, since it has nicer behaviour. We never thought of hooking up Set() too... but if figure it might make sense to do that too, so i'd be happy to take a patch... 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] modules in container
On Sun, 08.11.15 13:17, arnaud gaboury (arnaud.gabo...@gmail.com) wrote: > > 1- SELinux is disabled as the host distro is difficult to setup with > it, so it is OK > 2- Running modprobe bridge nf_nat br_netfilter failed with message: , > error: exit status 1" > These modules are indeed loaded on host. How can I make the container > aware of it? I am pretty sure all container managers disallow loading kernel modules from within the container, and I think that's a good choice that way. Note that "container" means you do shared-kernel virtualization: you only have one kernel, and hence there's only one kernel to load kernel modules into. Hence loading a kernel modules on the host is sufficient to make its functionality available to the kernel. Now, not all functionality the kernel provides is available in containers (in fact only a small part actually is), and the software you are using assumes it is however. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] RFC: Removing RequiresOverridable= and RequisiteOverridable=?
Heya! At systemd.conf we discussed whether we can remove the unit dependency types RequiresOverridable= and RequisiteOverridable=. I am pretty sure they are pretty much unused in the wild, and hard to grok at all, and hence, in order to clean things up a bit, we should really get rid of it. Unless of course, anyone can make a really really strong case for them, or is aware of any real users of this? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: removing .shapshot
On Sat, 07.11.15 13:33, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > Hi, > > do you use .snapshot unit type? If you do, please speak up. > > I'd like to remove support for the .snapshot unit type. > It seems not be used, snapshots are basically transient targets, > and targets can be used to implement similar functionality. > > The advantage would be a small reduction of the learning curve of > systemd and removal of some code, shell completions, & documentation. Yes, I fully agree that we should remove this unit type. Let's see if anyone responds with a strong case. If not, I am happy to merge a PR that drops it. 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] modules in container
Am 08.11.2015 um 15:41 schrieb arnaud gaboury: On Sun, Nov 8, 2015 at 2:57 PM Richard Weinberger mailto:richard.weinber...@gmail.com>> wrote: On Sun, Nov 8, 2015 at 1:17 PM, arnaud gaboury mailto:arnaud.gabo...@gmail.com>> wrote: > I am trying to understand how kernel modules are "passed" to nspawn container. A container must not load any module as the kernel is a shared resource. So, why my container, and especially docker.service, is not aware of the loaded modules from the host? because he has no business to do so? kernel modules ahre *hardware drivers* there is no classical hardware in a container if you need that for whatever reason than don't use containers but full virtualization signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] modules in container
On Sun, Nov 8, 2015 at 2:57 PM Richard Weinberger < richard.weinber...@gmail.com> wrote: > On Sun, Nov 8, 2015 at 1:17 PM, arnaud gaboury > wrote: > > I am trying to understand how kernel modules are "passed" to nspawn > container. > > A container must not load any module as the kernel is a shared resource. > So, why my container, and especially docker.service, is not aware of the loaded modules from the host? > > -- > Thanks, > //richard > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] modules in container
On Sun, Nov 8, 2015 at 1:17 PM, arnaud gaboury wrote: > I am trying to understand how kernel modules are "passed" to nspawn container. A container must not load any module as the kernel is a shared resource. -- Thanks, //richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] modules in container
I am trying to understand how kernel modules are "passed" to nspawn container. My setup: Archlinux host, Fedora 23 container (function = server). Example of what I would like to solve: On container: -- $ systemctl status docker -l ● docker.service - Docker Application Container Engine Loaded: loaded (/usr/lib/systemd/system/docker.service; disabled; vendor preset: disabled) Active: failed (Result: exit-code) since Sun 2015-11-08 10:44:27 CET; 2h 27min ago Docs: http://docs.docker.com Main PID: 1146 (code=exited, status=1/FAILURE) Nov 08 10:44:27 poppy docker[1146]: time="2015-11-08T10:44:27.846565995+01:00" level=warning msg="Docker could not enable SELinux on the host system" Nov 08 10:44:27 poppy docker[1146]: time="2015-11-08T10:44:27.846925084+01:00" level=info msg="Option DefaultDriver: bridge" Nov 08 10:44:27 poppy docker[1146]: time="2015-11-08T10:44:27.846948089+01:00" level=info msg="Option DefaultNetwork: bridge" Nov 08 10:44:27 poppy docker[1146]: time="2015-11-08T10:44:27.848252833+01:00" level=warning msg="Running modprobe bridge nf_nat br_netfilter failed with message: , error: exit status 1" Nov 08 10:44:27 poppy docker[1146]: time="2015-11-08T10:44:27.852710572+01:00" level=info msg="Firewalld running: true" Nov 08 10:44:27 poppy docker[1146]: time="2015-11-08T10:44:27.918262393+01:00" level=fatal msg="Error starting daemon: Error initializing network controller: Error initializing bridge driver: Setup IP forwarding failed: open /proc/sys/net/ipv4/ip_forward: read-only file system" Nov 08 10:44:27 poppy systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE Nov 08 10:44:27 poppy systemd[1]: Failed to start Docker Application Container Engine. 1- SELinux is disabled as the host distro is difficult to setup with it, so it is OK 2- Running modprobe bridge nf_nat br_netfilter failed with message: , error: exit status 1" These modules are indeed loaded on host. How can I make the container aware of it? Thank you for any pointers/help. -- google.com/+arnaudgabourygabx ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
