Score:0

Ubuntu

Why doesn't 'systemctl reboot' work?

alchemy

4/9/23, 5:57 AM

Why dont these commands work in Kubuntu 20.04? Applications shut down and the screen goes black, but it never finishes poweroff. Any ideas?

systemctl poweroff
systemctl reboot

https://askubuntu.com/a/479368/795299

I should clarify.. the regular GUI restart and shutdown buttons work fine. The regular CLI commands (reboot and shutdown -H now) also don't work. But they were and I was concerned they are more abrupt, not giving applications time to save and close.

Here are some errors from journalctl -r (reverse order):

Dec 10 14:21:31 osboxes kernel: Fixing recursive fault but reboot is needed!
...theres a big chunk of what looks like machine code numbers for the kernel here...
Dec 10 14:21:31 osboxes kernel: CPU: 13 PID: 2635 Comm: QQmlThread Tainted: P           OE     5.4.0-91-generic #102-Ubuntu
Dec 10 14:21:31 osboxes kernel: Oops: 0010 [#1] SMP PTI
Dec 10 14:21:31 osboxes kernel: PGD 0 P4D 0 
Dec 10 14:21:31 osboxes kernel: #PF: error_code(0x0010) - not-present page
Dec 10 14:21:31 osboxes kernel: #PF: supervisor instruction fetch in kernel mode
Dec 10 14:21:31 osboxes kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000
Dec 10 14:21:31 osboxes pulseaudio[7418]: GetManagedObjects() failed: org.freedesktop.systemd1.ShuttingDown: Refusing activation, D-Bus is shutting down.
Dec 10 14:21:31 osboxes dbus-daemon[1171]: [system] Activation via systemd failed for unit 'dbus-org.bluez.service': Refusing activation, D-Bus is shutting down.
Dec 10 14:21:31 osboxes dbus-daemon[1171]: [system] Activation via systemd failed for unit 'rtkit-daemon.service': Refusing activation, D-Bus is shutting down.
...this error repeats for 10 dbus-daemon messages...
Dec 10 14:21:28 osboxes dbus-daemon[2354]: [session uid=1001 pid=2354] Activated service 'org.kde.kglobalaccel' failed: Process org.kde.kglobalaccel received signal 6
Dec 10 14:21:28 osboxes org.kde.kglobalaccel[7171]: Available platform plugins are: eglfs, linuxfb, minimal, minimalegl, offscreen, vnc, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposi>
Dec 10 14:21:28 osboxes org.kde.kglobalaccel[7171]: This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Dec 10 14:21:28 osboxes org.kde.kglobalaccel[7171]: qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
..no errors for about 15 lines..
Dec 10 14:21:28 osboxes systemd[1]: Stopped ACPI event daemon.
Dec 10 14:21:28 osboxes systemd[1]: acpid.service: Succeeded.
Dec 10 14:21:28 osboxes org.kde.kglobalaccel[7171]: qt.qpa.xcb: could not connect to display :0
Dec 10 14:21:27 osboxes kernel: snd_hda_codec_hdmi hdaudioC1D1: HDMI: invalid ELD data byte 9
Dec 10 14:21:27 osboxes systemd[1]: finalrd.service: Succeeded.
Dec 10 14:21:27 osboxes systemd[1]: Failed unmounting /media/abc/VHDs.
..added below errors..
Dec 10 17:55:40 osboxes systemd-udevd[16858]: veth5ed07fa: Failed to get link config: No such device
Dec 10 17:55:40 osboxes systemd-tmpfiles[17063]: [/run/finalrd-libs.conf:9] Duplicate line for path "/run/initramfs/lib64", ignoring.
Dec 10 17:55:40 osboxes libvirtd[1290]: unable to read: /sys/class/net/veth5ed07fa/operstate: No such file or directory
Dec 10 17:55:40 osboxes libvirtd[1290]: Failed to open file '/sys/class/net/veth5ed07fa/operstate': No such file or directory

The unmounting error is from a symlink to the docker directory onto a data partition. Disabling the mountpoint in fstab didnt resolve.

It looks like the last message is acpi related: Error "fixing recursive fault but reboot is needed". But using acpi noirq didn't resolve.

Comparing journalctl between using the restart button from the desktop which succeeds, I find there are similar dbus-daemon messages, and umounting error, but no kerner bug error. There is a "NVIDIA ACPI Video Driver.. failed with exit code", but it still succeeds.

reboot does work from tty2 if I dont log in from sddm as user first.

123

0 + 0

bash

shutdown

systemd

user535733

4/10/23, 3:53 AM

Please try a the poweroff command on a 21.10 LiveUSB's "Try Ubuntu" environment. If poweroff does not work properly on that hardware with the LiveUSB's newer kernel, then please file a bug report against the `linux` package.

stumblebee

4/11/23, 2:46 AM

Does `halt -p` (poweroff) or `halt --reboot` work?

alchemy

4/11/23, 3:04 AM

@stumblebee, no.. same thing. But I did find it works from tty2 before user login.

stumblebee

4/11/23, 4:30 AM

I am confused to what you are doing. How are you able to execute a command before user login? Please elaborate.

alchemy

4/11/23, 5:14 AM

@stumblebee. from tty2 before login of user through sddm. so terminal and console work, but something about the DE isnt. I'm using Kubuntu and Konsole. It doesnt change if I use root or user, so something about the user loading from sddm to DE causes the problem. Something loading for DE that isnt closing. And the kernel error is concerning. But again, using the DE GUI buttons to restart is fine with no kernel error.

sancho.s ReinstateMonicaCellio

4/11/23, 10:56 AM

Avoid "narrating" messages. Please post exactly what you get from `journalctl` when it works, so others could compare.

Score:1

Ubuntu

sancho.s ReinstateMonicaCellio

4/9/23, 10:06 AM

This does not answer Why doesn't 'systemctl reboot' work?, but it may solve your problem.

Try with

$ sudo shutdown
$ sudo shutdown -r

You could configure your system so you don't need sudo as well.

Yet another option is to add acpi=noirq to the grub line.

A possible cause is Nvidia drivers.

To dig a little further, please read and post the output of journalctl that includes a failed shutdown/reboot, with

$ journalctl --list-boots > boots.txt
$ journalctl --no-pager -b > boot_minus0.txt
$ journalctl --no-pager -b -1 > boot_minus1.txt
...

This creates files that you can later upload to pastebin. Make your effort in inspecting them.

Related:

https://www.debian.org/releases/buster/amd64/ch08s01.en.html

0 + 0

alchemy

4/10/23, 10:36 PM

thanks, sorry for the delay.. I posted the error messages closest to where the reboot hangs above. I'll look into them, but maybe you have some experience with them? ..again, normal reboot methods work.. just this method using systemctl hangs..

alchemy

4/11/23, 12:23 AM

if the GUI buttons work, as a workaround, is there a way to call their action from the shell with a command? I thought that's what the systemctl commands did.

Score:0

Ubuntu

TrinitronX

6/5/24, 6:08 AM

In your dmesg kernel logs, you glossed over an important detail: The kernel Oops!

Dec 10 14:21:31 osboxes kernel: Fixing recursive fault but reboot is needed!
...theres a big chunk of what looks like machine code numbers for the kernel here...
Dec 10 14:21:31 osboxes kernel: CPU: 13 PID: 2635 Comm: QQmlThread Tainted: P           OE     5.4.0-91-generic #102-Ubuntu
Dec 10 14:21:31 osboxes kernel: Oops: 0010 [#1] SMP PTI
Dec 10 14:21:31 osboxes kernel: PGD 0 P4D 0 
Dec 10 14:21:31 osboxes kernel: #PF: error_code(0x0010) - not-present page
Dec 10 14:21:31 osboxes kernel: #PF: supervisor instruction fetch in kernel mode
Dec 10 14:21:31 osboxes kernel: BUG: kernel NULL pointer dereference, address: 0000000000000000

A Linux kernel "Oops" is an error thrown when something is faulty, or when something throws an exception in the kernel code. It’s similar to segfaults in user-space. After the Oops, you snipped out the CPU register crash dumps when the fault occurred. That probably would have made it more noticeable to those answering this question that something else was going on with the system.

The offending process that triggered the kernel Oops was killed without releasing locks or cleaning up structures. In the case of a kernel Oops or panic, sometimes the system may not even resume normal operations and enters a possibly unstable state or freeze. Once you see that an Oops or kernel panic has occurred, the computer cannot be trusted any further to remain in a stable state and should probably be rebooted as nicely as possible. Try the Magic SysRq key combo: Alt+SysRq + r e i s u b (each key combination pressed in that order). That should usually reboot the system in a softer way when the kernel is still responding to those interrupts.

If the system still does not respond to the Magic SysRq key combinations, then you may be forced to do a hard poweroff shutdown using the power button.

+ 0