Gateway restoration failed, gateway will no longer load

HI all,

So, I took a backup of my laptops local gateway which was running a project I was using to experiment with the Ignition software with the intention of deploying another configuration over the top such that i could work locally on an issue we have (without the need to remote in over the internet and all the potential issues that come with that).

After the backup, I proceeded to deploy the GWBK file for the project i wanted to work on over the top.

Problem is, it got to a point whereby the gateway was reporting a 'Gateway is: Uknown' status.

Looking through the wrapper, it all seems as if it was going well, until, it attempted to restart...at which point it decided it had detected an error:

INFO   | jvm 1    | 2023/10/18 14:55:50 | I [g.IdpAdapterManager           ] [13:55:50]: Shut down in 0 ms 
INFO   | jvm 1    | 2023/10/18 14:55:50 | I [g.PersistentRecordIdpAdapterMetricsService] [13:55:50]: Shut down in 0 ms 
INFO   | jvm 1    | 2023/10/18 14:55:50 | I [g.PersistentRecordIdpAdapterConfigService] [13:55:50]: Shut down in 0 ms 
INFO   | jvm 1    | 2023/10/18 14:55:50 | I [g.SecurityLevelManager        ] [13:55:50]: Shut down in 0 ms 
INFO   | jvm 1    | 2023/10/18 14:55:50 | I [g.PersistentRecordSecurityLevelConfigService] [13:55:50]: Shut down in 0 ms 
INFO   | jvm 1    | 2023/10/18 14:55:50 | I [IgnitionGateway               ] [13:55:50]: Ignition Gateway shut down in 2712ms 
INFO   | jvm 1    | 2023/10/18 14:55:50 | 14:55:50,431 |-INFO in ch.qos.logback.classic.AsyncAppender[SysoutAsync] - Worker thread will flush remaining events before exiting. 
INFO   | jvm 1    | 2023/10/18 14:55:50 | 14:55:50,435 |-INFO in ch.qos.logback.classic.AsyncAppender[SysoutAsync] - Queue flush finished successfully within timeout.
INFO   | jvm 1    | 2023/10/18 14:55:50 | 14:55:50,435 |-INFO in ch.qos.logback.classic.AsyncAppender[DBAsync] - Worker thread will flush remaining events before exiting. 
INFO   | jvm 1    | 2023/10/18 14:55:50 | 14:55:50,439 |-INFO in ch.qos.logback.classic.AsyncAppender[DBAsync] - Queue flush finished successfully within timeout.
STATUS | wrapper  | 2023/10/18 14:55:53 | on_exit trigger matched.  Restarting the JVM.  (Exit code: 2)
STATUS | wrapper  | 2023/10/18 14:55:58 | Reloading Wrapper configuration...
STATUS | wrapper  | 2023/10/18 14:55:58 | Launching a JVM...
INFO   | jvm 2    | 2023/10/18 14:55:59 | Error opening zip file or JAR manifest missing : d:\opt\appd\appagent\javaagent.jar
INFO   | jvm 2    | 2023/10/18 14:55:59 | Error occurred during initialization of VM
INFO   | jvm 2    | 2023/10/18 14:55:59 | agent library failed to init: instrument
ERROR  | wrapper  | 2023/10/18 14:55:59 | JVM exited while loading the application.

Not entirely sure what all this means.

I have attached an extract of the
Wrapper.log (20.1 KB)
from the point I initiated the restoration operation.

The problem is, the Wrapper logging just stopped...as such, I assume that this means that the GW has also stopped...if that's the case, the root cause of the issue aside for a moment, having not had to deal with such a situation previously, I'd also be at a loss as to the steps required to get it to attempt a re-initialisation.

Either way, many thanks for any advice anyone may have here!

Cheers!
Rob

Can you upload the ignition.conf?

Sure!

Slight issue in that this forum wont allow files with extension of 'conf', but, renamed to TXT, it should be fine.

Here you are:

ignition.conf.txt (8.3 KB)

That said, I've not touched it (to my knowledge) and so I'm not expecting anything different to the 'normal' configuration within it.

Thanks again.
Rob

Whatever Ignition you got these from made these modifications that don't work on your system:

wrapper.java.additional.4=-javaagent:d:\opt\appd\appagent\javaagent.jar
wrapper.java.additional.5=-Dappagent.start.timeout=5000

Comment these lines out and try starting it again.

3 Likes

ok, how would I manually start the GW without access to the GW to interact with it?

Err, sorry, can you rephrase that question for me. I don't understand what you're asking.

what is the process of starting the Ignition gateway?

If you’re on windows you can run the start-ignition.bat file, or if it’s installed as a service already run net start ignition.

I’m confused why you’re asking this. You already tried to start it somehow… evidenced by the logs you provided.

no.

the restore process attempted to start the Ignition Gateway...not me.

I have never had to do this from the perspective of having to do it manually myself without the Ignition system (essentially the Gateway) there to do this for me.

Thanks again for your feedback, I will try to do this now.

Kind Regards
Rob

https://docs.inductiveautomation.com/display/DOC81/Installing+and+Upgrading+Ignition#InstallingandUpgradingIgnition-StartorStopIgnition

1 Like

ok, so it's back up and running once again...it does however appear to be running what was on there previously however...how should I now proceed with regards to swapping to the GWBK backup I want to interact with?

It would appear that the 'Restore' process may not be appropriate here?

This is confusing as it always has been in the past.

Many thanks for any further advice you or anyone else may have.

Kind Regards
Rob

Restoring the backup, followed by editing the ignition.conf to fix it, should be enough.

Sounds like you should give support a call and get them to walk you through this.

1 Like

Nope, I do not believe that the Ignition support team will be required (well, they won't be required just yet at least anyway :slight_smile: )

It seems as if it attempted to do the same thing during the restore process, causing the Gateway to report 'Unknown' once again, however, upon pasting a copy of the edited CONF file into the directory, the Gateway/Restore process suddenly sprung back into life again and was able to start the project upon, I assume, the next attempt at loading it.

After it got beyond this hurdle, the Restore process appears to have completed and as a result, was ultimately able to deploy the project.

Thanks again, this has indeed been most useful....although my system does not exactly match the source system, hopefully, I will now be able to modify a number of the gateway settings to match what I have and allow me to at least attend to what I need to.

Kind Regards
Rob