Automatic Resume on Reboot

Hi Team,

I’m sure someone must have suggested this but could we get Orchestrator to automatically handle re-boots? This would work as follows:

  1. Process not responding - attempt to automatically kill after X minutes of no logs.
  2. Reboot the VM (required to ensure all apps are closed down).
  3. Automatically restart the process that was originally running
  4. Pick up the next queue item

This would cover situations where the process is just hanging OR the machine itself is not responding. Maybe a max number of 3 reboots a day should be permitted before someone should investigate the machine manually?

Thoughts?

RD

1 Like

For queue items you have automatic retry. Is this needed at job level?

But it means that a person has to reboot the machine, and also restart the job manually? I’m thinking it could all be handled automatically up to X number of attempts before a person needs to get involved?

  1. It runs within a try-catch therefore the robot will try another item
  2. Now, we are talking about multiple bots running in parallel, so the item will be send to another one who is up and running
  3. 18.3 will bring job queues per environment, so there’s no issue if you assign multiple bots to a queue, if one fails no issue
  4. However, when the job fails the robot will restart (not reboot) and continue with the same process or another one.

If the machine itself is not responding or UiPath is not responding, how would it be able to execute the activity to reboot which it received from Orchestrator?

If the process it not working properly (maybe due to other programs which are not responding). then you can easily identify those robots in Orchestrator. You can then either reboot those computers/VMs through your common server management or RDP.
Or you can make a simple workflow which you can send to thesesystems, which includes powershell code to reboot the system: How To Restart Computers Remotely via PowerShell -- Microsoft Certified Professional Magazine Online

If not responding programs is a common thing which will need you to reboot several times a day, then it’s probably better to investigate the issue and put the robot on hold and take it out of production.