[systemd-devel] bpf-firewall:
I see the following when I run journalctl -g fail systemd-logind.service: bpf-firewall: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/systemd-logind.service failed: Invalid argument systemd-userdbd.service: bpf-firewall: Attaching egress BPF program to cgroup /sys/fs/cgroup/system.slice/systemd-userdbd.service failed: Invalid argument I have tried searching on this but I am unable to get any information on this What are these errors and how do I correct/stop them?
Re: [systemd-devel] Feedback sought: can we drop cgroupv1 support soon?
On Fr, 22.07.22 12:15, Lennart Poettering (mzerq...@0pointer.de) wrote: > > I guess that would mean holding on to cgroup1 support until EOY 2023 > > or thereabout? > > That does sound OK to me. We can mark it deprecated before though, > i.e. generate warnings, and remove it from docs, as long as the actual > code stays around until then. So I prepped a PR now that documents the EOY 2023 date: https://github.com/systemd/systemd/pull/24086 That way we shoudn't forget about this, and remind us that we still actually need to do it then. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Feedback sought: can we drop cgroupv1 support soon?
On Fr, 22.07.22 12:37, Wols Lists (antli...@youngman.org.uk) wrote: > On 22/07/2022 11:15, Lennart Poettering wrote: > > > I guess that would mean holding on to cgroup1 support until EOY 2023 > > > or thereabout? > > > That does sound OK to me. We can mark it deprecated before though, > > i.e. generate warnings, and remove it from docs, as long as the actual > > code stays around until then. > > You've probably thought of this sort of thing already, but can you wrap all > v1-specific code in #ifdefs? Especially if it's inside an if block, the > compiler can then optimise the test away if you compile with that set to > false. > > Upstream can then set the default to false, while continuing to support it, > but it will then become more and more a conscious effort on the part of > downstream to keep it working. > > Once it's visibly bit-rotting you can dump it :-) The goal really is to reduce code size, not to increase it further by having to maintain a ton of ifdeffery all over the place. we generally frown on ifdeffery in "main" code aleady, i.e. we try to isolate ifdeffery into "library" calls that hide it internally, and then return EOPNOTSUPP if somethings is compiled out. That way the "main" code can then treat compiled out stuff via usual error handling, greatly simplifying conditionalizations and the combinatorial explosion from having many optional deps. ifdeffery comes at a price, and is very hard to test for (because CIs do not test in all combinations of present and absent optional deps), hence the goal should be to minimize, isolate it, not emphasize it and sprinkle it over the whole codebase as if it was candy. Lennart -- Lennart Poettering, Berlin
Re: [systemd-devel] Regarding service rate limiting (systemd 237)
On Fri, Jul 22, 2022 at 06:14:11PM +0530, Ani A wrote: > Found the issue, posting here to close this thread (and possibly help > someone who might land in this situation!) Thanks for sharing. > The daemon which had issues with rate-limit, was invoking some > `systemctl stop/start ` > commands in its initialization! (probably this has some unwanted side > effects?) Timing comes to my mind that could affect that. > If I eliminate that, then the rate-limit on the main daemon works fine! :) Yeah, better use explicit dependencies (Wants=/After=) instead of such a call-back. Michal
Re: [systemd-devel] Feedback sought: can we drop cgroupv1 support soon?
On 22/07/2022 11:15, Lennart Poettering wrote: I guess that would mean holding on to cgroup1 support until EOY 2023 or thereabout? That does sound OK to me. We can mark it deprecated before though, i.e. generate warnings, and remove it from docs, as long as the actual code stays around until then. You've probably thought of this sort of thing already, but can you wrap all v1-specific code in #ifdefs? Especially if it's inside an if block, the compiler can then optimise the test away if you compile with that set to false. Upstream can then set the default to false, while continuing to support it, but it will then become more and more a conscious effort on the part of downstream to keep it working. Once it's visibly bit-rotting you can dump it :-) Cheers, Wol
Re: [systemd-devel] Regarding service rate limiting (systemd 237)
Hi Michal, Found the issue, posting here to close this thread (and possibly help someone who might land in this situation!) The daemon which had issues with rate-limit, was invoking some `systemctl stop/start ` commands in its initialization! (probably this has some unwanted side effects?) If I eliminate that, then the rate-limit on the main daemon works fine! :) Thanks. -- Ani
Re: [systemd-devel] Feedback sought: can we drop cgroupv1 support soon?
On Do, 21.07.22 16:24, Stéphane Graber (stgra...@ubuntu.com) wrote: > Hey there, > > I believe Christian may have relayed some of this already but on my > side, as much as I can sympathize with the annoyance of having to > support both cgroup1 and cgroup2 side by side, I feel that we're sadly > nowhere near the cut off point. > > >From what I can gather from various stats we have, over 90% of LXD > users are still on distributions relying on CGroup1. > That's because most of them are using LTS releases of server > distributions and those only somewhat recently made the jump to > cgroup2: > - RHEL 9 in May 2022 > - Ubuntu 22.04 LTS in April 2022 > - Debian 11 in August 2021 > > OpenSUSE is still on cgroup1 by default in 15.4 for some reason. > All this is also excluding our two largest users, Chromebooks and QNAP > NASes, neither of them made the switch yet. At some point I feel no sympathy there. If google/qnap/suse still are stuck in cgroupv1 land, then that's on them, we shouldn't allow ourselves to be held hostage by that. I mean, that Google isn't forward looking in these things is well known, but I am a bit surprised SUSE is still so far back. > I honestly wouldn't be holding deprecating cgroup1 on waiting for > those few to wake up and transition. > Both ChromeOS and QNAP can very quickly roll it out to all their users > should they want to. > It's a bit trickier for OpenSUSE as it's used as the basis for SLES > and so those enterprise users are unlikely to see cgroup2 any time > soon. > > Now all of this is a problem because: > - Our users are slow to upgrade. It's common for them to skip an > entire LTS release and those that upgrade every time will usually wait > 6 months to a year prior to upgrading to a new release. > - This deprecation would prevent users of anything but the most > recent release from running any newer containers. As it's common to > switch to newer containers before upgrading the host, this would cause > some issues. > - Unfortunately the reverse is a problem too. RHEL 7 and derivatives > are still very common as a container workload, as is Ubuntu 16.04 LTS. > Unfortunately those releases ship with a systemd version that does not > boot under cgroup2. Hmm, cgroupv1 named hiearchies should still be available even on cgroupv2 hosts. I am pretty sure nspawn at least should have no problem with running old cgroupv1 payloads on a cgroupv2 host. Isn't this issue just an artifact of the fact that LXD doesn't pre-mount cgroupfs? Or does it do so these days? because systemd's PID1 since time began would just use the cgroup setup it finds itself in if it's already mounted/set up. And only mount and make a choice between cgroup1 or cgroupv2 if there's really nothing set up so far. Because of that I see no reason why old systemd cgroupv1 payloads shouldn#t just work on cgroupv2 hosts: as long as you give them a pre-set-up cgroupv1 environemnt, and nothing stops you from doing that. In fact, this is something we even documented somewhere: what to do if the host only does a subset of the cgroup stuff you want, and what you have to do to set up the other stuff (i.e. if host doesn't manage your hierarchy of choice, but only others, just follow the same structure in the other hierarchy, and clean up after yourself). This is what nspawn does: if host is cgroupv2 only it will set up name=systemd hierarchy in cgroupv1 itself, and pass that to the container. (I mean, we might have regressed on this, since i guess this kind of setup is not as well tested with nspawn, but I distinctly remember that I wrote that stuff once upon a time, and it worked fine then.) > That last issue has been biting us a bit recently but it's something > that one can currently workaround by forcing systemd back into hybrid > mode on the host. This should not be necessary, if LXD would do minimal cgroup setup on its own. > With the deprecation of cgroup1, this won't be possible anymore. You > simply won't be able to have both CentOS7 and Fedora XYZ running in > containers on the same system as one will only work on cgroup1 and the > other only on cgroup2. I am pretty sure this works fine with nspawn... > I guess that would mean holding on to cgroup1 support until EOY 2023 > or thereabout? That does sound OK to me. We can mark it deprecated before though, i.e. generate warnings, and remove it from docs, as long as the actual code stays around until then. Thank you, for the input, Lennart -- Lennart Poettering, Berlin
[systemd-devel] sd_bus_process semantics
Hello,
I am trying to retrieve an sd_bus_message using the 'ret' argument of
sd_bus_process().
The documentation says the following:
sd_bus_process() processes at most one incoming message per call. If
the parameter ret is not NULL and the call processed a message, *ret
is set to this message.
I declared a method, and called it from outside my program. I am seeing
that my method is being executed, but the message returned in 'ret' is
NULL. Is this a normal behavior? If so the doc seems unclear to me.
Here is my full test program:
#include
#include
#include
#include
#include
static int dbus_test_method(sd_bus_message *m, void *userdata,
sd_bus_error *ret_error)
{
const char *str;
int ret;
ret = sd_bus_message_read(m, "s", );
if (ret < 0)
return sd_bus_error_set_errno(ret_error, -ret);
printf("test_method: %s\n", str);
sd_bus_reply_method_return(m, NULL);
return 0;
}
static const sd_bus_vtable vtable[] = {
SD_BUS_VTABLE_START(0),
SD_BUS_METHOD("TestMethod", "s", NULL, dbus_test_method, 0),
SD_BUS_VTABLE_END
};
int main()
{
struct sd_bus_message *m;
struct sd_bus *bus;
struct pollfd fds;
int ret;
ret = sd_bus_default_user();
if (ret < 0) {
printf("sd_bus_default_user: %s\n", strerror(-ret));
return EXIT_FAILURE;
}
ret = sd_bus_add_object_vtable(bus, NULL, "/marionm/test",
"marionm.test", vtable, NULL);
if (ret < 0) {
printf("sd_bus_add_object_vtable: %s\n", strerror(-ret));
return EXIT_FAILURE;
}
ret = sd_bus_request_name(bus, "marionm.test",
SD_BUS_NAME_ALLOW_REPLACEMENT | SD_BUS_NAME_REPLACE_EXISTING);
if (ret < 0) {
printf("sd_bus_request_name: %s\n", strerror(-ret));
return EXIT_FAILURE;
}
fds.events = POLLIN;
fds.fd = sd_bus_get_fd(bus);
if (fds.fd < 0) {
printf("sd_bus_get_fd: %s\n", strerror(-ret));
return EXIT_FAILURE;
}
while (true) {
ret = poll(, 1, -1);
if (ret < 0) {
printf("poll: %m\n");
return EXIT_FAILURE;
}
ret = sd_bus_process(bus, );
if (ret < 0) {
printf("sd_bus_process: %s\n", strerror(-ret));
return EXIT_FAILURE;
}
if (sd_bus_message_is_method_call(m, NULL, NULL))
printf("%p\n", m);
}
}
I compiled it with 'gcc -lsystemd'.
From another terminal I ran:
busctl --user call marionm.test /marionm/test marionm.test TestMethod s foo
Here is the resulting trace:
test_method: foo
m: (nil)
I expected to retrieve the message that was processed in
dbus_test_method. I can get into why I'd like to retrieve
the message here if needed, but it doesn't change the issue.
I am running Debian 11, and systemd v247.3
Re: [systemd-devel] Feedback sought: can we drop cgroupv1 support soon?
On Do, 21.07.22 11:55, Christian Brauner (brau...@kernel.org) wrote: > In general, I wouldn't mind dropping cgroup1 support in the future. > > The only thing I immediately kept thinking about is what happens to > workloads that have a v1 cgroup layout on the host possibly with an > older systemd running container workloads using a newer distro with a > systemd version without cgroup1 support. > > Think Ubuntu 18.04 host running a really new Ubuntu LTS that has a > version of systemd with cgroup1 support already dropped. People do > actually do stuff like that. Stéphane and Serge might know more about > actual use-cases in that area. The question is though how much can we get away with at that front. i.e. I think we can all agree that if you attempt to run an extremely new container on an extremely old host is something we really don't have to support, once the age difference is beyond some boundary. The question is at what that boundary is. Much the same way as we have a baseline on kernel versions systemd supports (currently 3.15, soon 4.5), we probably should start to define a baseline of what to expect from a container manager. Lennart -- Lennart Poettering, Berlin
