Description of problem: Recently, in both my F21 and Rawhide VirtualBox guests, I've had shutdowns, usually just after starting a yum distro-sync and just before the transaction starts, but once in the middle of the transaction. /var/log/messages shows "systemd: Forcibly powering off as result of failure." when this happens. See my thread https://lists.fedoraproject.org/pipermail/test/2014-October/123402.html . Presumably this is a timing issue caused by my hardware being slow, but it's not *that* slow (a 3 GHz E8400 Intel Core Duo, and each guest is using both cores). Version-Release number of selected component (if applicable): systemd-216-4.fc21.x86_64 How reproducible: sometimes
What exactly do you run before the poweroff happens? Do you have a custom service for that?
It's probably the functionality to poweroff if default.target is not reached fast enough (10 minutes?). On the TODO list is changing that to only limit the time until basic.target.
I have no custom service. Most days I just boot into GNOME, immediately do a yum distro-sync, then power down. The forced shutdown usually happens after I start the distro-sync but just before the transaction starts, after most or all of the drpms have finished building (although once it happened during the transaction, in F21).
I think it just happened again (in F21), but this time, it was after a completed transaction, and there was no error message in /var/log/messages, so I can't be sure it was a forced shutdown. However, I was in graphical mode, and there were no orphan inodes cleaned up, so it probably was. /var/log/wtmp wasn't cleaned up either (both output lines in "last -2 reboot" say "still running", all output lines in "last reboot" except for the first two show a shutdown, so the earlier forced shutdowns did update wtmp).
This bug may be a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1152220 ?
well, is initial-setup.service installed / enabled / running on your system?
[root@localhost ~]# systemctl status initial-setup- initial-setup-graphical.service initial-setup-text.service [root@localhost ~]# systemctl status initial-setup-graphical.service ● initial-setup-graphical.service - Initial Setup configuration program Loaded: loaded (/usr/lib/systemd/system/initial-setup-graphical.service; disabled) Active: inactive (dead) [root@localhost ~]# systemctl status initial-setup-text.service ● initial-setup-text.service - Initial Setup configuration program (text mode) Loaded: loaded (/usr/lib/systemd/system/initial-setup-text.service; disabled) Active: inactive (dead) [root@localhost ~]# I only appear to have these two, not initial-setup.service.
those are the relevant services indeed, and they're both disabled, so this doesn't appear to be a dupe of the i-s case at least. Can you poke around with systemctl before the system powers down and see if you can spot what services are still attempting to start up?
I think I can pretty reliably reproduce this by just booting in graphical mode and leaving it alone for around 10 minutes. The problem is that when it shuts down that way, the system logs will be truncated - I don't even get the "Forcibly powering off" message in /var/log/messages. I wouldn't be surprised if a lot more people are experiencing this and just attribute it to gremlins because there's nothing in the logs. To debug this, I can try repeatedly running something like "systemctl --all status > foo.txt". Is there a better way - either getting systemd to say which failed service is making it shut down, or at least getting it to trigger a specified command prior to shutdown (such as the systemctl command) so I can get the output at the exact correct time?
I'll disable the shutdown functionality on next update. When it's all ready and ironed out upstream than we can enable it in F22.
I take back my claim that I could reliably reproduce it by just leaving the system alone for 10 minutes - that doesn't always happen. However, at least twice now I've seen it shut down while truncating the system logs so it would be almost impossible to track down.
(In reply to Zbigniew Jędrzejewski-Szmek from comment #10) > I'll disable the shutdown functionality on next update. When it's all ready > and ironed out upstream than we can enable it in F22. Just a note, please also consider GNOME's offline updates functionality. It would be very unfortunate if it got affected by this new feature as well. Rebooting during system update has a good chance of leaving the system totally broken. Thanks.
(In reply to Kamil Páral from comment #12) > Just a note, please also consider GNOME's offline updates functionality. It > would be very unfortunate if it got affected by this new feature as well. > Rebooting during system update has a good chance of leaving the system > totally broken. Thanks. systemd-216-7.fc21 update has the new upstream mechanism (JobTimeoutAction and related settings), but no timeouts are configured. So unless someone explicitly configures a timeout, they should be safe.
Zbigniew, how will this feature interact with a system that does a periodic fsck on bootup, and has a very large / slow filesystem? That automatic fsck could well take an hour on some systems, and having the system automatically power off during the fsck could turn an annoyingly long reboot into an essentially unrecoverable system.
(In reply to Rik van Riel from comment #14) > Zbigniew, how will this feature interact with a system that does a periodic > fsck on bootup, and has a very large / slow filesystem? Yes, that's another case. The timeout now is turned off (or will be when systemd is updated). I didn't want to patch out the functionality, to minimize the difference wrt. upstram, just all timeout are left unconfigured.
This was fixed, but not properly closed.