Re: [systemd-devel] inetd/chroot
From: Filipe Brandenburger [mailto:filbran...@google.com] > Hi, > Yes, I could reproduce this. > It happens while systemd tries to find the SELinux label of the binary. > I pushed a PR with a fix here: > https://github.com/systemd/systemd/pull/8405 > Once it's merged, you might want to ask the maintainers of your distro > to backport it... > Cheers! > Filipe Thank you most kindly for the fix! I am glad to have reported it. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] networkd dhcp client - serialize / run stand alone / inject or restart dhcp client
I have a request to start/stop/restart the dhcp lease client, and/or run networkd dhcp client stand alone, or somehow serialize dhcpclient lease and inject that for networkd-dhcp to pick that up and restart. For example, Ubuntu initramfs currently does not have networkd in it, but it can bring interfaces up with dhcp. And i'm not sure if there is a way to pass/inject the dhcp lease to networkd as a runtime state to pick up from there. Ideally without re-acquiring the lease once again. I'm currently pondering if I should be trying to get networkd running in the initramfs (without systemd in the initramfs), or like generate a runtime networkd config for post-pivot to root. Ideally, it would be nice to ship a "one-shot" dhcp lease acquire helper binary, that could be shipped in the initramfs, which does everything using the internal networkd dhcp lease and serializes the state in /run/. Such that post-pivot, the full networkd can notice that lease file and start running the longterm dhcp client. Think, something like $ ipconfig -c dhcp eth0 -> as shipped by klibc-utils Would such a util, be in-scope, for systemd-networkd? -- Regards, Dimitri. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [ANNOUNCE] systemd v238
On Fr, 09.03.18 07:57, Umut Tezduyar Lindskog (u...@tezduyar.com) wrote: > Hello Zbigniew, > > On Mon, Mar 5, 2018 at 11:37 PM, Zbigniew Jędrzejewski-Szmek > wrote: > > Hi, > > > > systemd-238 has been tagged. > > > > https://github.com/systemd/systemd/archive/v238/systemd-238.tar.gz > > > > CHANGES WITH 238: > > > > * The MemoryAccounting= unit property now defaults to on. After > > discussions with the upstream control group maintainers we learnt > > that the negative impact of cgroup memory accounting on current > > kernels is finally relatively minimal, so that it should be safe > > to > > enable this by default without affecting system performance. > > Besides > > memory accounting only task accounting is turned on by default, > > all > > other forms of resource accounting (CPU, IO, IP) remain off for > > now, > > because it's not clear yet that their impact is small enough to > > move > > from opt-in to opt-out. We recommend downstreams to leave memory > > accounting on by default if kernel 4.14 or higher is are primarily > > used. On very resource constrained systems or when support for old > > kernels is a necessity, -Dmemory-accounting-default=false can be > > used > > to revert this change. > > Are these optimisations for v1 or v2? Do you have more resource you > can reference? We made this change after discussing directly and personally with Tejun, the upstream kernel cgroups go-to guy, who suggested it was OK to turn it on now. Facebook has turned it on across its fleet now with good results, and hence we came to the conclussion we can do the same by default now. Given that cgroups v1/v2 is primarily just a question of API (and not controller implementation) I figure it should be fine on both, but maybe ping Tejun directly. Of course, I figure fb's fleet is very different from let#s say an embedded device. If you play around with this on such devices from the other end of the spectrum, please report issues if you do experience major problems with this change of default after all... Thanks, Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] RFC: enable suspend to idle
On Mon, Mar 5, 2018 at 5:19 PM, Oliver Neukum wrote: > On Fri, 2018-03-02 at 10:18 +0100, Lennart Poettering wrote: > > > But why wouldn't that be a kernel option? I mean, so far the goal was > > to encode "reasonable defaults" in the kernel itself, so that > > userspace is only used when those "reasonable defaults" do not apply > > onto one local case. > > > > Really, already for compatibility reasons the kernel should just carry > > the "reasonable defaults", so that it's not necessary to match it up > > with a udev version that carries the right policy for it. > > Well, no. The kernel must carry conservative defaults that do no harm > in any case. Setting defaults sensible for the class of systems systemd > runs on is the job of udev. > What would set sensible defaults on systems which don't run systemd nor udev? -- Mantas Mikulėnas ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] About supporting relative values (e.g. 50%) in configuration
On Thu, Mar 08, 2018 at 03:48:54PM +0800, ChenQi wrote: > Hi All, > > I'd like to know if systemd community thinks that adding support for > relative values in configuration is a good idea. > > I found a related patch and discussion in > https://lists.freedesktop.org/archives/systemd-devel/2015-May/032191.html. > > Quoting from the comments: > """ > > I'd always keep our basic structures as generic as possible, and as > close to the way CPUs work. Hence: store things as fixed-point > 32bit/32bit internally, but make it configurable in percent as > user-pointing UI. > > """ > > According to the comments, it seems that adding such support is acceptable? > > I' sending out this email because I want to check with the community > before I start to investigate more. Hi, yes, a patch to allow relative values would be very much welcome. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
