On Mon, Feb 23, 2026 at 7:43 PM Dave Close <[email protected]> wrote: > > I wrote: > > > On most of my machines, "reboot" entered as root causes the machine to > > shutdown and then reboot, as I expect it should. But on one machine, > > the machine does not restart. In the process of trying to understand > > why this might be, I discovered that reboot is not an actual command: > > > > # pwd > > /root > > # which reboot > > /usr/sbin/reboot > > # ls -l /usr/sbin/reboot > > lrwxrwxrwx 1 root root 13 2025-07-10 20:42 /usr/sbin/reboot -> > > ../bin/reboot > > # ls -l /bin/reboot > > lrwxrwxrwx 1 root root 16 2026-02-06 16:00 /bin/reboot -> > > ../bin/systemctl > > # ls -l /bin/systemctl > > -rwxr-xr-x 1 root root 322584 2026-02-06 16:00 /bin/systemctl
This is exactly the way reboot works in systemd. systemctl when called as the name "reboot", tells systemd to reboot the system (execute the systemd reboot.target, and shutdown all services and reboot when done). This is STANDARD arg[0] processing that has been used in Unix/Linux forever (>35 years) that is why it is not really documented as anything special because it is not. Lots of commands act this same way (lvm with all of its links is exactly the same, the man page for the specific command you invoked it as matters). Based on the name it is called as arguments may not be needed at all, or completely different arguments may be required. It is documented in "man reboot" , man systemctl has nothing to do with how the command works when the command name is reboot or something else designed in this manner. You would have to look in journalctl to see why reboot is getting hung up. Typically there should not be any difference between shutdown -r and reboot, which would make me suspect some sort of issue preventing reboot from changing the target to reboot. The combo of ssh + sshd + sudo + reboot may be triggering some sort of permission issue/selinux that prevents it from working. -- _______________________________________________ users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
