| Summary: | systemd segfaults if no cgroups are available | ||
|---|---|---|---|
| Product: | systemd | Reporter: | Richard Weinberger <richard> |
| Component: | general | Assignee: | systemd-bugs |
| Status: | RESOLVED FIXED | QA Contact: | systemd-bugs |
| Severity: | major | ||
| Priority: | medium | CC: | brovvnout+bugzilla, pasthelod |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
From IRC, this is systemd v208 on OpenSUSE 13.1. To make this work we'd need a patch, as nobody of us tests this. Hope all of you either test all the combinations or do not break *at will* those you don't have the time and inclination to test, at least in system-wide components that are not specific to systemd, while pushing the latter hard. Well, cgroups-less kernels are explicitly not supported by systemd. However we added some hacks to allow it to boot to a certain degree even if a lot of things will not work correctly afterwards. In this mode when you boot you will actually get a warning on screen and bootup is delayed by 10s to make sure the user understands this. Now, this mode recently broke, and it will segfault early on. I am happy to take a patch to 'fix' this again, but I will not work on this as i dont run kernels like this, and as mentioned its not really supported anyway... Another option is to simply be honest amd stop supporting in entirely, and refuse booting completely. And I figure this is what I will eventually do if nobody cares enough to send me a patch to fix that segfault. You are right, it is a well known fact that cgroups-less kernels won't work with systemd. But users will also face this bug if they boot a Linux container without mounting cgroups into the container. This is how I've found the issue. Mounting cgroups into container is got fixed lately in libvirt-lxc, but other LXC implementations may still suffer from that issue... (In reply to comment #2) > To make this work we'd need a patch, as nobody of us tests this. Yes, it's clear you don't test for NULL pointers before deferencing. Nobody else should need to provide a patch to fix the bug you created. If you can't figure out how to check for NULL pointers, STOP WRITING CODE IMMEDIATELY! You should never EVER be deferencing any pointer without first sanity checking its value. NO EXCEPTIONS! P.S. Please go die in a fire. (In reply to comment #6) > (In reply to comment #2) > > To make this work we'd need a patch, as nobody of us tests this. > > Yes, it's clear you don't test for NULL pointers before deferencing. Nobody > else should need to provide a patch to fix the bug you created. If you can't > figure out how to check for NULL pointers, STOP WRITING CODE IMMEDIATELY! > You should never EVER be deferencing any pointer without first sanity > checking its value. NO EXCEPTIONS! > > P.S. Please go die in a fire. Please stay civil. Such a tone is not acceptable. (In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #2) > > > To make this work we'd need a patch, as nobody of us tests this. > > > > Yes, it's clear you don't test for NULL pointers before deferencing. Nobody > > else should need to provide a patch to fix the bug you created. If you can't > > figure out how to check for NULL pointers, STOP WRITING CODE IMMEDIATELY! > > You should never EVER be deferencing any pointer without first sanity > > checking its value. NO EXCEPTIONS! > > > > P.S. Please go die in a fire. > > Please stay civil. Such a tone is not acceptable. Dereferencing NULL pointers is not acceptable. Demanding someone else to provide a patch to correct such bad behavior is also not acceptable. Systemd now fails to boot when the cgroups filesystem is not available, the same way it requires proc, sys, devtmpfs, and the variuos tmpfs mounts. If cgroups are missing, it prints an error which filesystem preparation step went wrong. http://cgit.freedesktop.org/systemd/systemd/commit/?id=99a17ada9caa8e190b5cafa5cd3c19618feeff48 |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
On systems without cgroups (like linux containers) systemd takes the following branch in manager_setup_cgroup() /* 0. Be nice to Ingo Molnar #628004 */ if (path_is_mount_point("/sys/fs/cgroup/systemd", false) <= 0) { log_warning("No control group support available, not creating root group."); return 0; } But later it dies due to a NULL pointer exception in unit_default_cgroup_path(). Full backtrace: #0 0x00007f735230a8cb in raise () from /lib64/libpthread.so.0 #1 0x000000000040cbcb in crash (sig=11) at src/core/main.c:143 #2 <signal handler called> #3 0x00007f7351fceeea in strlen () from /lib64/libc.so.6 #4 0x00007f7351fcec0e in strdup () from /lib64/libc.so.6 #5 0x0000000000479a79 in unit_default_cgroup_path (u=u@entry=0x2431690) at src/core/unit.c:2022 #6 0x000000000044d4a9 in unit_create_cgroups (mask=(unknown: 0), u=0x2431690) at src/core/cgroup.c:385 #7 unit_realize_cgroup_now (u=0x2431690) at src/core/cgroup.c:445 #8 0x000000000044d4a1 in unit_realize_cgroup_now (u=0x2430fb0) at src/core/cgroup.c:442 #9 0x000000000044d4a1 in unit_realize_cgroup_now (u=u@entry=0x2448b40) at src/core/cgroup.c:442 #10 0x000000000044d83f in unit_realize_cgroup (u=u@entry=0x2448b40) at src/core/cgroup.c:523 #11 0x000000000041e161 in service_spawn (s=s@entry=0x2448b40, c=0x2433350, timeout=<optimized out>, pass_fds=pass_fds@entry=true, apply_permissions=apply_permissions@entry=true, apply_chroot=apply_chroot@entry=true, apply_tty_stdin=apply_tty_stdin@entry=true, set_notify_socket=false, is_control=is_control@entry=false, _pid=_pid@entry=0x7fff9774049c) at src/core/service.c:1813 #12 0x0000000000421b00 in service_enter_start (s=s@entry=0x2448b40) at src/core/service.c:2240 #13 0x00000000004221b8 in service_enter_start_pre (s=0x2448b40) at src/core/service.c:2323 #14 service_start (u=0x2448b40) at src/core/service.c:2600 #15 0x0000000000481e91 in job_run_and_invalidate (j=0x243df80) at src/core/job.c:517 #16 0x000000000040fbfe in manager_dispatch_run_queue (m=m@entry=0x2425540) at src/core/manager.c:1198 #17 0x0000000000412f3f in manager_loop (m=0x2425540) at src/core/manager.c:1826 #18 0x000000000040ad44 in main (argc=<optimized out>, argv=0x7fff97740ed8) at src/core/main.c:1652