Hey! I've been having this trouble with Artix Linux OpenRC since last night, and I've spend a good amount of time trying to fix it, but with no luck, so I've gone ahead and made an account on the forum to ask for help!
My issue is that whenever I try to do
sudo reboot
or
sudo poweroff
it returns
Broadcast message from root@dirtman (pts/2) (Sat Mar 29 21:31:05 2025):
The system will reboot now
or
Broadcast message from root@dirtman (pts/2) (Sat Mar 29 21:31:05 2025):
The system will power off now
as it normally does, but now for some reason, it doesn't reboot/power off, it just returns that message and then does nothing.
I really have no idea what to do here, and I don't like shutting down by holding the power button because of the filesystem risks that come with that. Thanks for any help!
I don't know the answer. But in the meantime you can use ctrl-alt-delete to do a safe reboot and then use the power button once the computer exits Linux.
From within X, or wayland I guess, switch tty (ctrl-alt-f2) then ctrl-alt-delete.
Also learn about and enable Magic SysRq key (https://wiki.archlinux.org/title/Keyboard_shortcuts#Kernel_(SysRq)) and how to exit cleanly with REISUB. Useful if the computer hangs.
Does a good old
# shutdown -h now // "poweroff"
# shutdown -r now // "reboot"
work?
I always used the above and am not even sure where the plain "reboot", "poweroff", etc. commands come from. I thought that was a systemd thing even?
"reboot", "poweroff" etc are parts of a proper init system. So is "shutdown".
Check dmesg and logs for any errors when you try to reboot. Check for any halting processes.
I had an experience where it didn't want to shutdown the first time yesterday with 'shutdown'
This was after a kernel upgrade. After running it a few times, it finally took. I suspect it is a hardware issue. I'm not opposed to pulling the dam plug when it doesn't want to do what I say
or kill -9 1
Like you I have always used
shutdown -h now for poweroff, but it seems dinit doesn't allow a time so
shutdown -h now fails.
I'm fairly old now so unable to learn many new tricks :(
Thanks for this! This will act as a temporary work around until I find my solution.
I actually think that the 'poweroff' and 'reboot' commands are just aliases for these commands, because they return the exact same message, and also fail to power off/reboot. Even if they are different though, they still don't work.
Is it likely for a hardware issue to show up after ~2 months of completely fine use? What could've happened? I also don't have super uncommon or new hardware, so it seems odd to me that this would be the case. I can look into this I suppose however.
I've looked at dmesg and other seemingly related logs and they don't seem to show any errors (I'm not fully sure what logs you refer to, I just looked at a few that seemed related to power management), they just show the exact same message as I saw before in a different location. I should also mention that none of my processes even seem to try to stop, librewolf, spotify, etc, all keep running and behaving exactly as normal.
Lighting Strike, Tsumi, dropped computer, normal age of components, power surge, cat urinates on the power supply, evil spirits... need I add more?
Computers are no different than light bulbs. They burn out with normal use.
None of these things have happened lol, except possibly a power surge, I'm not sure of that one, it is possible. My PC is pretty new, no parts are older than 2-3 months. I don't think it's a hardware issue at this point. I also feel like any possible hardware issue would also cause other issues on the computer (which I don't have). My best guess for the source of this problem is that OpenRC isn't sending a power signal properly, or whatever receives said signal isn't doing anything with it, I really don't know though, I'm not super experienced on the low level side of computers. And on the side of the evil spirits, I'll look into my local exorcists. Thanks for the reply!
I have dinit. 'sudo shutdown' doesn't work for me, but 'sudo halt' works. But for me the problem was that linux shuts down, but the computer didn't power off.
'sudo halt' seems to be another alias for poweroff, at least on OpenRC, as it gives me the exact same result.
Would pulling the plug be safe once linux has shut down?
Yeah, well I bet this is ACPI related. Probably something got updated and now your linux box doesn't know what to sendoff properly.
I am very clueless so listen to me the least, plus I do not use openrc, but since there seem no good leads so far:
If I understand correctly, the openrc shutdown script uses a FIFO here:
/run/openrc/init.ctl
You could have a look if it exists, is a FIFO, has 0600 permissions set, etc. Might not hurt to post the output, if what I say is even correct.
There is also another thread that might give you some ideas?
https://forum.artixlinux.org/index.php/topic,6537.0.html (https://forum.artixlinux.org/index.php/topic,6537.0.html)
EDIT:
And could try to call
usr/bin/openrc-shutdown
manually and see if there is any message on the terminal?
not without setting off nuclear war
new computers also have hardware issues. Anyone who has ever built a server farm or run a few thousand installfests, is aware of that. Hardware is very cheaply built and it needs a shake out. There are always hardware problems and power off for some reason is one of their favorite problems. The truth is, computers aren't designed to be turned off. They are finiky and always changing. You do make an interesting point though... I am not sure what actually causes a computer to turn itself off or to reboot. I might look it up one day.
I do know, however, this problem is common and it is most often related to some hardware glitch.
That file does exist and has 0600 permissions, but I'm not sure how to check if its a FIFO, or even what that is really, but I don't know why it would be modified from plain install, as I've never touched it before. It's contents change based on what power action I try to take, if I do 'sudo reboot' its contents change to 'reboot' and if I do 'sudo poweroff' it's contents change to 'poweroff'. My guess is that this file is written to by the reboot/poweroff commands and then read by the system to actually shut off? If so, the file itself doesn't seem to be the issue, though I'm not really sure.
They didn't seem to actually solve the issue in that thread, but there were some decent ideas about checking for fs damage by using a live boot, I'll try that, but I really don't think it's a fs issue. There's also the idea of replacing my kernel, which I'm not keen on, but If I really have to, then I will.
This gives the exact same result as all of the previous attempts.
Thank you for your reply! That thread you shared might end up helping me if I look further into it! I also didn't know about that file, even though it doesn't seem to be the issue, it's something I should probably learn about.
I suppose that these things make sense, it just feels like if it was a hardware issue, sysrq+B/O wouldn't work, but I really have no idea, I guess those hotkeys are basically the same as pulling the plug so maybe not.
If it is a hardware issue, is the only way for me to fix it to get new hardware? And can I confirm that it's not a hardware issue by seeing if I can reboot from a live iso?
This sounds - and again don't trust what I say - like openrc does everything as intended up to the final system call. From then on it is kernel territory.
(I do not see issues about this on their bugtracker which might support this conclusion too?)
(Edit: This is not correct, there are kill(-1, SIGTERM) and kill(-1, SIGKILL) before the shutdown syscall. But for lack of other suggestions, testing kernel versions might be best for now?)
So before you dig the hole and bury the poor thing potentially alive, doing the live session test is worth a try!
If with "not keen on" you mean "never done before" then totally look into trying a LTS kernel. It is not hard at all!
Thank you! I'll look into these things tomorrow afternoon.
If this started after an upgrade I'd look at /var/log/pacman.log to see what got upgraded then downgrade to when it was OK, then upgrade bit by bit to try and identify what package caused this. Kernel, permissions and power manager packages would be likely culprits, although sometimes it is something less obvious. Installing an LTS kernel is an easy thing to try initially, I agree. Hardware issue could also refer to a hardware specific bug , a problem that only affects certain machines.
Hello everyone! Today I tested the troublesome commands in a live cd and they worked exactly as intended which for me solidifies that this isn't a hardware issue as some users have suggested. I also switched to linux-lts and unfortunately, that didn't fix it either. I can look at upgraded packages and see if I find something there, but unless somebody has an idea soon, I may just reinstall Artix, I've been thinking about reinstalling for some time now anyway so it's not a huge deal. I didn't exactly want to do that right now, but maybe this is just the motivation I need. Anyway, thanks for everybody's help! I'm not giving up immediately, so if you have any ideas left, please share.
If this was due to an update and not because of something you configured or installed yourself, you might reinstall and things will work, but after you update they may not. Plus if you do a massive single update when you bring the iso to current versions, it will be harder to determine which package was the cause, providing you had been updating regularly before the problem emerged.
See the post from Nous here:
https://forum.artixlinux.org/index.php/topic,7614.msg47483/topicseen.html#msg47483 (https://forum.artixlinux.org/index.php/topic,7614.msg47483/topicseen.html#msg47483)
There are other ways to downgrade too. It's expected in a cutting edge rolling release distro you might need to downgrade selected packages occasionally, so it's worth learning about the methods involved.
What Seven Hashes says!
I would just like to add that there are more than just "the" LTS kernel:
https://forum.artixlinux.org/index.php/topic,5201.msg33222.html#msg33222 (https://forum.artixlinux.org/index.php/topic,5201.msg33222.html#msg33222)
Nous maintains this one: https://packages.artixlinux.org/packages/galaxy/x86_64/linux-lts515/ (https://packages.artixlinux.org/packages/galaxy/x86_64/linux-lts515/)
And there are more pre-built on the AUR altho I have never tried those since switching to Artix.
... it still bothers me how an update can have such effects tho.
It cannot be something like ignoring .pacnew changes, right?
I went ahead and reinstalled Artix, this time using a base install like I should've and now things work fine. Thanks for everybody's help with this. I likely messed things up at some point on my own and it only started catching up with me now as I had no idea what I was doing when I first installed Artix (it was my first linux distro). I'm not sure whether or not to mark this as solved, so for now I'll leave it. Again, thank you all for your time!