gcwmd -r from the terminal has never let me down, but it's been a while since I've read this thread. What was the reason again for not simply performing the gateway restart the normal way using the gateway command line utility?
I'll chime in to say because it's a pain to have to rdp to the server just to restart the service, when it's possible through the UI through weird workarounds/hacks
I prefer there not be an obvious Web UI way to do this, as it is quite risky--as noted when prompted to restart for modules and similar config changes. The gateway might not restart. And then you need terminal or desktop access to its server in order to apply external direction.
I think routine gateway restart commands should remain external, so a newbie who doesn't have terminal/desktop access cannot easily precipitate a long outage. (Hunting for someone with the necessary privileges to rescue the situation.)
Perhaps this could be offered conditionally/configurably, so it can be forbidden on production gateways.
I think this is along the lines of our original thinking on this, which admittedly was a decade or more ago. There’s sneaky workarounds to cause a restart that have popped up since.
But yeah… restarts can fail, and then you’ll need real access, which could be problematic.
It is difficult for us to access the underlying machine as its managed by another team. If the restart fails we could of course get them to fix it, but we have to restart the gateway quite often...
This is a pretty fundamental requirement of running Ignition. Your team boundaries need to be fixed. Full stop.
Can I ask why? This seems odd to me.
Strongly disagree.
Most larger corps implement a zero trust architecture, for good reason.
FWIW, it looks like this is targeted for the 2027.2 release.
Happy medium would be add a UI restart option but with a gateway config setting to disable it or only allow it for certain roles.
This was due to a limitation on the target version field within our ticketing system. I've updated the ticket to reflect a target version of 2027.X. There is no guarantee this feature makes the 2027.2 release.
Ignition can be rather unstable.
Why are you referencing ZTA as an impediment to including server console/desktop access with Ignition Gateway Web UI access? I'm not arguing that gateway servers should be wide open.
I call Bull-[Expletive] on the ZTA argument. Please provide a real, relevant reason for your disagreement. Preferably something not already mitigated by Ignition best practices, like running only Ignition itself on that server. Something more important that being able to rescue a failed restart (particularly in production).
I have been using Ignition nearly a decade now I have never experienced this scenario where a gateway requires regular restarts. I highly suspect something underlying it that you may want to troubleshoot.
Sounds like a memory leak. The first two things that pop into my head to check for are improperly implemented http calls and recursive tag browsing. httpClient is supposed to be created at the top level of a library script and reused as needed. If it's being created for each call, I've read in the documentation that this can be problematic in Ignition versions 8.1.x and older. I've also seen evidence that recursive tag browsing within a UDT can be quite problematic as well. Perhaps some other people will chime in, and something will ring a bell. It would be great if we could eliminate the need for frequent gateway restarts with a simple implementation fix.
Without wading into the whole rest of this thread, since 8.3 I'll point out that you can take advantage of the "pending restart" tasks system and just invoke the restart endpoint directly, from e.g. a Perspective button, curl on your local machine, whatever.
Just POST <yourGatewayAddress>/data/api/v1/restart-tasks/restart?confirm=true, plus your X-Ignition-Api-Token authorization header.
You could also wire up a script to IgnitionGateway.get().restart(), if you really wanted.
I saw similar problems (back in the v7.9 era) with improperly used http calls.
If they are not reused or explicitly closed, the garbage collector may not clean them up as aggressively as you create new ones - aka 'memory leak'.
Ignition is very stable - restarts are not needed for Ignition. With hundreds of servers running for months on end the only restarts needed are for the dreaded Windows OS updates 
.
Psssst! In case you haven't heard, this is correctable. 
Additionally, trying to separate Ignition dev privileges and Ignition terminal privileges is purely cosmetic as anyone who gains access to the Designer would gain an RCE foothold.
There are better things to focus on for ZTA with Ignition.