When I run sudo reboot it takes a bit for it to actually shut down the device. It feels like the traditional reboot command is modified or being aliased somewhere (given the print message it displays: „The system is going down for reboot NOW!“.
Can anyone point me to where the reboot command is coming from? How long can I expect it to take initiate the reboot? Is there a way to do this immediatly?
I’m fairly sure the reboot command hasn’t been modified from the standard one.
The message you mention is a standard message.
This post gives a decent summary of the reboot process:
How reboot process works in linux? I have searched how Linux reboot process work and everywhere found only the booting/start-up process. Suppose for a illegal reboot how machine recover my running processes/services (for example, if… In the case of PLCnext Control devices, the init subsystem is SysVinit.
On a PLCnext Control device, the major process that will be shut down during a reboot is usually the PLCnext Runtime process. You can get an idea of how long it takes to stop this process using this command:
sudo /etc/init.d/plcnext stop
This process can take some time to shut down. As the post above mentions, you can skip almost all the shutdown steps by using the -f option on the reboot command, but you will need to weigh up the risks and benefits of using that option.
Thanks for the response. I’m happy to be corrected, the thing that threw me off was the echo „The system is going down for reboot NOW!“ which I’ve not seen before.
I’m realizing after just a tiny bit more googling that this is just what you see over ssh as part of the standard shutdown procedure.
On a related note, the reason I’m rebooting over ssh is because I upload some pcwex binaries and then reboot to have them take effect. This works nicely, but takes a while.
I looked into running /etc/init.d/plcnext restart however it seemed inconsistent in returning the PLC to its running state. Every once in a while I end up with just a signle green light on the AXC 2152 and no lights returing to the SPLC 1000. I’m curious if there are different steps triggered by PLCNext Engineer when it flashes a program other than /etc/init.d/plcnext restart?
As I think I mentioned in an earlier discussion - currently the only supported ways of sending a PLCnext Engineer project to a PLCnext Control device are by using PLCnext Engineer or (possibly) the Device and Update Management service. But of course you’re free to try other ways. 
I’m curious if there are different steps triggered by PLCNext Engineer when it flashes a program other than /etc/init.d/plcnext restart?When a new project is sent to the PLCnext Control device from PLCnext Engineer, it does not trigger a restart of the PLCnext Runtime. If you follow the messages in the Output.log file during this process in a shell session (using something like tail -f /opt/plcnext/logs/Output.log), you will see that there are only some components of the PLCnext Runtime that are affected during a project download - mainly the „Plc“ component, which executes the PLCnext Engineer project.
I looked into running /etc/init.d/plcnext restart however it seemed inconsistent in returning the PLC to its running state. Every once in a while I end up with just a signle green light on the AXC 2152 and no lights returing to the SPLC 1000.If you’re going to try something like you describe - and again, we can’t support that - you should stop the PLCnext Runtime process before copying the new project files to the device, and then start it again afterwards. It’s not surprising that swapping out project files while the „Plc“ component is running would cause a problem - it’s like overwriting a shared object library (.so) while a running process is using that library - anything could happen.
Makes sense, thanks for the helpful ideas! And yes, fully understood it isn’t supported, thanks!