We have PC’s in the field that we would like to be able to reboot remotely. To do this we just FTP a file into a specific folder when our application sees this file it reboots the PC by running “shutdown -r”. However we have only been able to make this work using Debian. I need to be able to make this work in OpenSuse 15.3. Currently all that seems to happen is the PC halts but never reboots. Is there a more reliable method to ensure the PC actually reboots. Since these PC’s are hundreds of miles away in remote areas we use XRDP to connect remotely to them and having a reliable method to reboot them is must have feature.
(of course run “as root”) does not function on that system as expected?
And did you try that being logged in to test if it works from a terminal/console outside your special program/script that says: if file x exists then shutdown -r ?
In our lab if I open a terminal and enter sudo shutdown -r now and after I enter the password my remote desktop session ends but the PC never reboots. Since I have access to the PC in the lab I connected a screen and all I see is blank screen. The computer never reboots. The same is true if I login locally issue the same command the result is the same just a blank screen.
This a brand new computer with a fresh install of Leap 15.3.
Am I right that then the whole story about the ftp session storing a file that triggers the reboot is only obfuscating because shutdown -r does not work as intended at all?
In that case we should concentrate on the problem of a not functioning shutdown -r. Whnen that is repaired, I assume that your ftp trick will also work.
I am not sure what your lab has to do with it. But you say you “open a terminal”. Please explain. Is that from the console, or from a desktop session by using a terminal emulator?
The bit about the FTP is just a little background about the proposed method for remotely rebooting. The real problem is that shutdown -r does not work from the Linux console. It seems to just halt the PC.
It takes 60 sec to shutdown unless a time option is is set +0 or now to shutdown or reboot (-r) immediately WALL is an optional message sent to all user before shutdown
I have a vague idea that I have seen that earlier here on the forums. A system that would not reboot, but only stop (no power off however) on shutdown -r. The problem is to find that old thread.
You could check in the BIOS if there is any setting in this area. It looks a bit as if the system is going to sleep instead of reboot.
Also, you could try from a root console
systemctl reboot
as this is the “modern” way (with systemd) to do a reboot. (shutdown should work also, because it also uses sytemd).
I had this issue but it was hardware related - specific to a Lenovo X1 Carbon gen-9 laptop, where it would not reliably shutdown nor restart with the 5.3.18 kernel. After updating to the 5.14.11 kernel that problem disappeared.
However I suspect the OPs issue, while similar symptoms, is a different issue.
Not sure if this is relevant, but when using ssh to the computers on my network, I simply use the reboot command rather than shutdown -r and it works well. According the the man pages, all of these commands “should” work, but YMMV.
-r as an option to systemctl doesn’t look relevant to rebooting, so likely the result of shutting down using -r isn’t unexpected. I’ve been mostly using the reboot command for several years, but ISTR trying the shutdown command now & then, as I’ve known it’s a symlink, and not getting either a shutdown or a reboot.
The problem is IMHO not on how to get the the command executed in the remote system (most done of course using SSH, but in this case done by storing a file in it using FTP, that then is detected by a local program/script) but the fact that the command does not do what is expected.
As long as shutdown -r does not “work”, it is irrelevant how it is initiated.
As I said, the shutdown command is now executed by systemctl (and this backward compatibility is done using a soft link). This does however NOT mean that all of the shutdown man page (like -r option) are not working anymore as defined in the shutdown man page.
The systemctl program will be designed so that it detects that it is called as “shutdown” and then honour (at least it has to honour) all arguments as defined in the shutdown man page. This is transparent to the user.
As I tried to explain, all versions of starting a reboot mentioned above should “work”. It is the system itself that is the problem.
And I am still waiting for the OP to report on what at least one or two of the offered alternatives do on the system. Of course because I want to be 1000% sure that
shutdown -r
reboot
systemctl isolate reboot
systemctl reboot
are all not working (or otherwise, you never know until you tried it).