Hide Forgot
Description of problem: After triggering shut-down over KDE or shutdown in the console, system hangs in the blue screen with the Fedora-logo at shut-down for about 5min (definitely more than 3min which i read is the time-out for the systemd) or with a blinking cursor in the upper left corner. It is possible to switch between tty 2-6 but login is not possible. It is possible to suspend2ram and suspend2disk within a few seconds (very fast!). Dmesg says nothing and messages just has these lines: May 28 16:59:16 Nifelheim systemd-shutdownd[4043]: Creating /run/nologin, blocking further logins... May 28 17:00:16 Nifelheim avahi-daemon[831]: Got SIGTERM, quitting. May 28 17:00:16 Nifelheim kernel: Kernel logging (proc) stopped. May 28 17:00:16 Nifelheim rsyslogd: [origin software="rsyslogd" swVersion="5.7.9" x-pid="866" x-info="http://www.rsyslog.com"] exiting on signal 15. The system is up-to-date so I don't think this is the known mysql-bug. Updated from F14 to 15 days ago and everything was fine. Problem started a few days ago. Version-Release number of selected component (if applicable): systemd: 26-1.fc15 (X86_64) How reproducible: Every shut-down. Steps to Reproduce: 1. trigger shut-down over cmd or KDE 2. 3. Actual results: System hangs for more than 4 minutes in the shutdown-screen and then turns off Expected results: System shuts down much faster. Additional info:
I have a similar issue with what I believe is a somewhat different setup: a pretty minimal installation upgraded from F-14 with yum, no desktop environment and just a handful of services - this is basically a headless PVR server. The setup is otherwise up to date with the latest F-15 updates except that I'm stuck with the F-14 kernel for now. A reasonably quick shutdown happens sometimes (very rarely), in the vast majority of cases it hangs for several minutes and eventually shuts down/reboots, and sometimes it hangs for so long time that I've given up waiting. Same problems if I reboot remotely over ssh or hit Ctrl-Alt-Del on the console. I've worked around the problem by using upstart for now (installed from updates-testing, init=/sbin/upstart in grub command line). I could help/try to find out the cause, but I have no idea where to start looking. There's not much anything in the system logs or the console, just something about systemd-logger.service and systemd-kmsg-syslogd.service entering failed state.
any network mounts involved?
To debug the shutdown progress, please boot with: log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg Create an executable script /lib/systemd/system-shutdown/debugshutdown.sh: #!/bin/sh mount -o remount,rw / dmesg > /shutdown-log.txt mount -o remount,ro / Then reproduce the problem and attach the resulting /shutdown-log.txt
Created attachment 501854 [details] Requested shutdown-log.txt (successful case) (In reply to comment #2) > any network mounts involved? None here. (In reply to comment #3) > To debug the shutdown progress, please boot with: [...] > Then reproduce the problem and attach the resulting /shutdown-log.txt As soon as I add systemd.log_target=kmsg to the kernel command line, I can no longer reproduce the problem, and removing that argument brings the problem back - other mentioned arguments do not seem to make a difference. So I'm unable to produce the requested output when the problem occurs according to the given recipe, but attached is the output from a successful shutdown case (note that it contains a bunch of logging related failure messages). Let me know if you'd like me to try the recipe from comment 3 sans the systemd.log_target=kmsg argument.
I updated to systemd: 26-2.fc15 (X86_64) and the problem is gone for me. FYI: no network mounts were involved or other external media.
(In reply to comment #4) > Created attachment 501854 [details] > Requested shutdown-log.txt (successful case) [ 0.000000] Linux version 2.6.35.13-91.fc14.x86_64 ... [ 3.745772] <31>systemd[1]: Child 338 died (code=exited, status=218/CAPABILITIES) [ 3.746430] <31>systemd[1]: Child 338 belongs to systemd-kmsg-syslogd.service [ 3.746698] <29>systemd[1]: systemd-kmsg-syslogd.service: main process exited, code=exited, status=218 [ 3.747292] <31>systemd[1]: systemd-kmsg-syslogd.service changed running -> failed [ 3.747782] <29>systemd[1]: Unit systemd-kmsg-syslogd.service entered failed state. systemd-kmsg-syslogd.service is not starting because of a mismatch in kernel capabilities which is known to happen when systemd built on a new kernel is run on an old kernel. With "systemd.log_target=kmsg" the service is not used, so the problem does not show up. Another workaround is to comment out all "CapabilityBoundingSet=" lines in /lib/systemd/system/* Why cannot use the F15 kernel anyway?
(In reply to comment #6) > Another workaround is to comment out all "CapabilityBoundingSet=" lines in > /lib/systemd/system/* Thanks, that seems to fix the problem too. If I want to do this without editing files in /lib/systemd/system, I suppose I should drop modified copies of those files to /etc/systemd/system instead - there's no single file/option somewhere I could use to disable this stuff globally, right? > Why cannot use the F15 kernel anyway? Because the primary and only functionality of the system in question requires out-of-tree kernel modules (em8300 and friends) and there's no version of them available that'd work with the F-15 kernel at least due to v4l related changes in it, maybe other things as well. I'll get to hacking them into shape eventually unless someone beats me to it though. (But as far as I'm concerned and given comment 5, this bug can be closed now.)
(In reply to comment #7) > Thanks, that seems to fix the problem too. If I want to do this without > editing files in /lib/systemd/system, I suppose I should drop modified copies > of those files to /etc/systemd/system instead - there's no single file/option > somewhere I could use to disable this stuff globally, right? Right. systemd could be made more tolerant of missing capabilities when running on older kernels. > (But as far as I'm concerned and given comment 5, this bug can be closed now.) Closing.
BTW, this is fixed in systemd git.