Note - If you do not fill in every section below, your post won’t be answered - you must provide the steps you have followed so far and the actions you’ve already taken. Make sure to remove this notice from your post too.
Make sure you search before posting! Duplicate posts for the same issue may not be answered.
OS Name/Version: Debian GNU/Linux 12 (Running in a Virtual Machine on Unraid 6.12.10)
Product Name/Version: AMP 2.6.0.6 - 20241120.1
Problem Description:
I’ve added a new instance to my, only, AMP installation. I now have 5 instances, which matches to my license. However, I have been unable to start the new instance (Space Engineers - would still prefer a Torch based version though). When I try to start it I get a message saying “Token Rejected No such token exists”. Not knowing why this is happening, and I can’t see anything in any of the logs - there is quite literally nothing beyond the request for an authentication token:
[23:58:25] [Core:admin Activity/27] : Managed remote instance SpaceEngineers01 at http://127.0.0.1:8085/
[23:58:25] [ADS:admin Activity/27] : Authentication token for admin requested by ManageInstance on behalf of admin
So I decided to take a gander at my license status - it says I have 8 out of 5 instances! But I don’t, I have only a single AMP installation and a total of 5 instances. I don’t know if this is what has caused the issue - or if there is just a problem trying to run a Space Engineers server on AMP under Linux (I have one running directly on Unraid in a Docker container so it shouldn’t be a problem).
Really hope somebody can shed some light on this as I’m stumped - with regards to both the instance not starting and the instance activation count being above what it should be.
Activations will sort themselves out over time, that error in the log isn’t related to your licence key at all, that’s in reference to a session token.
Try clearing your browser cache for the page, then try managing the instance.
If that doesn’t work, right click the instance and hit View Logs to see if there’s anything in there that can shed light on things. (might be as simple as reactivating the instance)
It is good to know that the instance count will sort itself out (though there is an item in there that is now almost 1 month old). I have tried flushing the browser cache - even went so far as to use a different browser (sometimes the sledgehammer approach is best). But no dice.
Looking at the logs:
Main ADS log:
[23:41:55] [Program Info/1] : Starting AMP version 2.6.0.6 (Phobos), built 20/11/2024 20:57
[23:41:55] [Program Info/1] : Stream: Mainline / Release - built by CUBECODERS/buildbot on CCL-DEV
[23:41:55] [Program Info/1] : Running in a QEMU KVM environment.
[23:41:55] [Program Info/1] : OS: Linux / x86_64
[23:41:55] [Program Info/1] : CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz (8C/16T)
[23:41:55] [Program Info/1] : RAM: 32088MB
[23:41:55] [Program Info/1] : AMP Instance ID: 56bff67e-ec12-45b6-a785-bda4f5c5dd1c
[23:41:59] [Core Info/1] : Loaded ADSModule version 2.6.0.6 by CubeCoders Limited
[23:41:59] [Loader Info/1] : Loaded FileManagerPlugin by CubeCoders Limited
[23:41:59] [Loader Info/1] : Loaded EmailSenderPlugin by CubeCoders Limited
[23:41:59] [Loader Info/1] : Loaded WebRequestPlugin by CubeCoders Limited
[23:41:59] [Loader Info/1] : Loaded CommonCorePlugin by CubeCoders Limited
[23:41:59] [Loader Info/1] : ADSModule requests dependency InstanceManagerPlugin…
[23:41:59] [Loader Info/1] : Loaded InstanceManagerPlugin by CubeCoders Limited
[23:41:59] [Loader Info/1] : ADSModule requests dependency SystemUserManagerPlugin…
[23:41:59] [Loader Info/1] : Loaded SystemUserManagerPlugin by CubeCoders Limited
[23:41:59] [Core Info/1] : Licence Present: AMP Professional Edition - Lifetime Licence
[23:42:00] [Loader Info/1] : Loaded steamcmdplugin by CubeCoders Limited
[23:42:00] [ADS Info/1] : Metrics server started OK on port 12820
[23:42:00] [Loader Info/1] : ADS startup complete in 533ms
[23:42:00] [System Info/12] : Updating remote source CubeCoders/AMPTemplates
[23:42:00] [System Info/12] : Updating existing remote source GitHub - CubeCoders/AMPTemplates: For the AMP community to share Generic Module templates.…
[23:42:00] [Loader Notice/1] : Using keypair with fingerprint REDACTED
No local changes to save
No stash entries found.
[23:42:00] [Loader Info/1] : SFTP Server started on 0.0.0.0:2223
Already up to date.
[23:42:05] [Core Info/1] : Webserver started on http://0.0.0.0:8080
[23:42:05] [System Info/14] : Startup mode is UpdateAndStart.
[23:42:05] [System Info/11] : Checking for AMP updates…
[23:42:05] [System Info/14] : AMP is up to date.
[23:42:05] [Core Info/14] : Using default tag: latest
[23:42:07] [Core Info/15] : latest: Pulling from cubecoders/ampbase
[23:42:07] [Core Info/14] : Digest: REDACTED
[23:42:07] [Core Info/14] : Status: Image is up to date for cubecoders/ampbase:latest
[23:42:08] [Core Info/7] : docker.io/cubecoders/ampbase:latest
[23:42:08] [Core Info/14] : docker: Error response from daemon: Conflict. The container name “/AMP_GarrysMod01” is already in use by container “d4c361797042787d38f1f8ccfa92977e3c1426af859ce25ee26e8136b564ef3e”. You have to remove (or rename) that container to be able to reuse that name.
[23:42:08] [Core Info/14] : See ‘docker run --help’.
[23:42:10] [System:Anonymous Warning/25] : Slow method invocation: Login took 4656ms to complete.
[23:42:10] [System:Anonymous Warning/25] : Slow response: Core.Login took 4661ms to complete.
[23:42:14] [System:Anonymous Warning/10] : Slow method invocation: Login took 7160ms to complete.
[23:42:14] [System:Anonymous Warning/10] : Slow response: Core.Login took 7161ms to complete.
[23:42:14] [System:Anonymous Warning/13] : Slow method invocation: Login took 7993ms to complete.
[23:42:14] [System:Anonymous Warning/15] : Slow method invocation: Login took 6152ms to complete.
[23:42:14] [System:Anonymous Warning/15] : Slow response: Core.Login took 6154ms to complete.
[23:42:14] [System:Anonymous Warning/13] : Slow response: Core.Login took 7998ms to complete.
[23:42:14] [Core Info/15] : wine8: Pulling from cubecoders/ampbase
[23:42:15] [Core Info/15] : Digest: REDACTED
[23:42:15] [Core Info/15] : Status: Image is up to date for cubecoders/ampbase:wine8
[23:42:15] [Core Info/15] : docker.io/cubecoders/ampbase:wine8
[23:42:15] [Core Info/10] : docker: Error response from daemon: Conflict. The container name “/AMP_SpaceEngineers01” is already in use by container “950f525dda9aba07e3d34d38ed16c61a0f1e75e18982b0ef9911bf5bb88f562e”. You have to remove (or rename) that container to be able to reuse that name.
[23:42:15] [Core Info/10] : See ‘docker run --help’.
[23:42:16] [System:Anonymous Warning/14] : Slow method invocation: Login took 7220ms to complete.
[23:42:16] [System:Anonymous Warning/14] : Slow response: Core.Login took 7220ms to complete.
[23:42:17] [System:Anonymous Warning/14] : Slow method invocation: Login took 11416ms to complete.
[23:42:17] [System:Anonymous Warning/14] : Slow response: Core.Login took 11420ms to complete.
[23:42:18] [System Warning/13] : Slow method invocation: Login took 4637ms to complete.
[23:42:18] [System Warning/13] : Slow response: Core.Login took 4638ms to complete.
[23:46:53] [Core:admin Activity/29] : Managed remote instance SpaceEngineers01 at http://127.0.0.1:8085/
[23:46:55] [ADS:admin Activity/29] : Authentication token for admin requested by ManageInstance on behalf of admin
[23:46:55] [System Error/29] : LIM - Failure to make API call to SpaceEngineers01: Connection refused (127.0.0.1:8085)
[23:47:27] [Core:admin Activity/33] : Managed remote instance SpaceEngineers01 at http://127.0.0.1:8085/
[23:47:27] [ADS:admin Activity/33] : Authentication token for admin requested by ManageInstance on behalf of admin
[23:47:29] [System Error/29] : LIM - Failure to make API call to SpaceEngineers01: Connection refused (127.0.0.1:8085)
[23:51:15] [Core:admin Activity/29] : Managed remote instance SpaceEngineers01 at http://127.0.0.1:8085/
[23:51:15] [ADS:admin Activity/29] : Authentication token for admin requested by ManageInstance on behalf of admin
[23:58:25] [Core:admin Activity/27] : Managed remote instance SpaceEngineers01 at http://127.0.0.1:8085/
[23:58:25] [ADS:admin Activity/27] : Authentication token for admin requested by ManageInstance on behalf of admin
And in the SpaceEngineers AMP_Logs:
[23:49:02] [Program Info/1] : Starting AMP version 2.6.0.6 (Phobos), built 20/11/2024 20:57
[23:49:02] [Program Info/1] : Stream: Mainline / Release - built by CUBECODERS/buildbot on CCL-DEV
[23:49:03] [Program Info/1] : Running in a Docker environment.
[23:49:03] [Program Info/1] : OS: Linux / x86_64
[23:49:03] [Program Info/1] : CPU: Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz (8C/16T)
[23:49:03] [Program Info/1] : RAM: 32088MB
[23:49:03] [Program Info/1] : AMP Instance ID: aac38b85-5113-4d37-b328-f8386241e8b4
[23:49:04] [Core Info/1] : Loaded ADSModule version 2.6.0.6 by CubeCoders Limited
[23:49:04] [Loader Info/1] : Loaded FileManagerPlugin by CubeCoders Limited
[23:49:04] [Loader Info/1] : Loaded EmailSenderPlugin by CubeCoders Limited
[23:49:04] [Loader Info/1] : Loaded WebRequestPlugin by CubeCoders Limited
[23:49:04] [Loader Info/1] : Loaded CommonCorePlugin by CubeCoders Limited
[23:49:04] [Loader Info/1] : ADSModule requests dependency InstanceManagerPlugin…
[23:49:04] [Loader Info/1] : Loaded InstanceManagerPlugin by CubeCoders Limited
[23:49:04] [Loader Info/1] : ADSModule requests dependency SystemUserManagerPlugin…
[23:49:05] [Loader Info/1] : Loaded SystemUserManagerPlugin by CubeCoders Limited
[23:49:05] [Core Info/1] : Licence Present: AMP Professional Edition - Lifetime Licence
[23:49:05] [Loader Info/1] : Loaded steamcmdplugin by CubeCoders Limited
[23:49:05] [ADS Info/1] : Metrics server started OK on port 12820
[23:49:05] [Loader Info/1] : ADS startup complete in 521ms
[23:49:05] [System Info/12] : Updating remote source CubeCoders/AMPTemplates
[23:49:05] [System Info/12] : Updating existing remote source GitHub - CubeCoders/AMPTemplates: For the AMP community to share Generic Module templates.…
No local changes to save
No stash entries found.
[23:49:06] [Loader Notice/1] : Using keypair with fingerprint REDACTED
[23:49:06] [Loader Info/1] : SFTP Server started on 0.0.0.0:2223
Already up to date.
[23:49:07] [Core Info/1] : Webserver started on http://127.0.0.1:8085
[23:49:07] [System Info/10] : Checking for AMP updates…
[23:49:07] [System Info/11] : AMP is up to date.
I just can’t see anything obvious - the docker container name error has been common for quite some time - sometimes it will complain about PalWorld, other times about Left4Dead2 (which still doesn’t work right). Not sure why it does this, but on a fresh boot it always throws errors about Docker containers being slow to start then sorts itself out.
How does one go about reactivating an instance? I’ve tried to do a quick search in the docs but can’t find anything. I assume this will be a command line job?
Yeah that all there looks pretty standard (except for the “LIM -Failure…” messages). It usually says in the instance’s logs whether it needed to be reactivated, but for reference you can reactivate a single instance via ampinstmgr reactivate TheInstanceName and all of them via the main panel, or ampinstmgr reactivateall.
You could try and right click the instance, then hit Manage in new tab and see if managing it that way works (it’ll prompt a login)
You could also try setting the Logging Level to Debug in the main panel to see if that spits out any extra info
So the fresh instance had no logs after I first created it - and had the same issue of not being able to be managed. So I just left it be after posting the above.
I looked just now (as I have only just seen your response)…and it started! The logs still are of no help, it seems it took AMP about an hour to get the instance ready, and then it started the server - without any config of course. So it is working, which makes me happy indeed - thank you for your responses.
However, I can’t help but feel that AMP should have been logging something saying what it was doing - and I still have no idea why this instance sorted itself out after an hour or so when the first one got stuck in limbo for 2 days.
Yeah that seems quite odd, I’ve personally never been able to get that issue to happen, but I’ve seen others have it at random. Next time I see someone with the issue, I’ll pass on the wise words of “give it a really long minute and see if that works”
It might be beneficial to set the Logging Level to debug inside the troublesome instances, so the next time it happens, we can see if there’s any extra errors being logged
