We recently fired up an instance from AWS marketplace, which has a 30 day "free trial" period.
In any case, we stood it up pretty smoothly, added a humongous VKG, and were sailing along .. but then ran into some issues when trying to set up a model .. I think maybe because I inadvertently triggered some queries that were trying to unravel the schema of the postgres database that we were attached to.
This database has 842 tables, and 841 views .. and it's completely devoid of any of the the nice metadata that you might expect .. so it's not surprising that the SD server struggled with it.
After seeing a lot of long-running queries in the queue for the database associated with the VKG, I decied to issue a stop command, similar to:
stardog-admin --server https://stardog.data-sbx.somewhere.com:5820 server stop
After a long wait, the command proclaimed success.
Then I issued a command like: stardog-admin --server https://stardog.data-sbx.somewhere.com:5820 server start
And that responded with: Your Stardog license has expired. To request a new license, please visit https://stardog.com/get-started or contact your sales associate
I think that this thing has only been up a little over a week .. so the license should not have expired.
In any case, we'll probably restart the machine, and if that works, I'll post a follow-up ..
We have also had some issues with using stardog-admin on that instance to change the admin password, add users etc.
stardog-admin server start ignores anything passed in via --server, since any remote server you're trying to start by definition wouldn't be running to accept the command (it might behoove us to print a warning to that effect). What is likely happening is that the command is looking at a local $STARDOG_HOME on the machine running it and finding an expired license. You would need to ssh into the remote box and start the server directly on it, either via stardog-admin server start or systemctl start stardog
Makes sense that server stop command would effectively be a "trap-door".
We did think of that .. but wanted to proceed carefully since the AMI is a little hard to wrangle. Our server is behind a zero-trust "fence" .. so remote access to the command line requires tying up a DevOps engineer.
FWIW, the fact that the issue is simply that the service is unavailable would be clearer if server start behaved more like the various other server commands in this case .. for example, a call to server stop when the remote server is down produces a response that is pretty clear:
~ % stardog-admin --server https://stardog.somewhere.com:5820 server stop
Service Unavailable
Given that command line access to our server is a bit of a choke-point, I wonder if server restore could be used as a make-do way to effectively "remotely reset" the server? We'll probably give that a try ..
Looks like there is still some sort of license issue on the Amazon instance:
The ops engineer i'm working with did the following in the command line:
[root@ip-10-0-0-228 ~]# /opt/stardog/bin/stardog-admin server start A valid Stardog license was not found in /root. Please copy your license file to this location or visit [https://stardog.com](https://stardog.com/) to acquire a new license. [root@ip-10-0-0-228 ~]#
and also remarked: odd enough I see a stardog process running and listening on 5820 mind checking if the endpoint is somehow online?
I gave the following a go, and the service reports as "unavilable" % stardog-admin --server https://stardog.middle-of-url-redacted.com:5820 server status Service Unavailable
I guess we'll restart the instance, and see if it recovers ..