Can a client run alone without ever connecting to an API?

[tm6907]

Wondering if a Linux client can run activity alone without ever having connected to a API.

If so what should be written in the application.json file? Right now I have it as it was out-of-the-box, but doesn't work. Tried on Rocky9, Rocky8 and Centos8.

I did have my Rocky8 client working yesterday but that was a client who was connected to an API in the past i.e. had an instance ID.
I removed that instance folder and set the value in application.json back to "localhost:5000/api" as it is from a fresh download and now it doesn't work. My theory is it only worked because it had been connected in the past with that instance ID, even if you change around the connection to localhost rather than the API.

[sei-dupdyke]

Yes, clients will work without the API, you just won't be able to send them commands or collect activity history, but every activity should occur and be logged locally to ./logs/.

You can turn off the API stuff in the client via the application.json file.

When you say it doesn't work, what specifically is not working?

[sei-dupdyke]

Have not seen this. I'm not familiar with Packer.

With Docker, I have definitely come across weird behavior when it starts to run out of memory. This is solved with a docker system prune which typically clears up copious GB of space :)

[tm6907]

Docker shouldn't come into play here since its just a client right? Packer is just the user name.

I reverted the change I made in application.json but get the same issue as before. I changes the isEnabled value from true to false for the Id block. It did work in testing before but now doesn't.

[sei-dupdyke]

Right, docker not involved with client.

What is in system-lv_root? — that is a lot of space.

[tm6907]

I'm not sure but that shouldn't matter really if its not full.

Turns out rebooting the VM does fix this "out of memory" issue but it does keep coming back. Still don't know whats causing it but it seems to be Ghosts specifically.

I'll try a clean install just incase it corrupted or something.

[tm6907]

Yeah still stuck, not sure whats happening

[sei-dupdyke]

Hmm.

• What version are you running? dotnet ghosts.client.linux.dll --version
• Are there any errors or fatals in ./logs/application.log?
• What handlers are you running? Browser? Something else?
• Try running in debug mode: dotnet ghosts.client.linux.dll --debug and see if that tells us more in the logs please.

[tm6907]

Seems to work inconsistently. Rebooting does fix it temporarily.

Version:

Logs show nothing of note. Shows its working at the moment because I rebooted again, but it wasn't working 30 mins ago.

The only handler is for Firefox, with the basic timeline that comes with the download. Perhaps its to with the geckodriver again? Looking at the logs at past runs it shows errors relating to that but it also has been working so idk. Usually a problem with the driver is shown in the command line instead of this "out of memory" error.

I'll wait for it to break again and post the full logs.

[tm6907]

I'm trying to run it remotely with an Ansible script, which is how I discovered this error

[sei-dupdyke]

Ah, so we have seen this weird Firefox behavior (on Windows IIRC) where it is creating an enormous amount of temp files. Can you please check the FF directories (app and profile) to see if this is the case?

[tm6907]

Yeah didn't take long to break again

Got this weirdness too, not seen this one before :D

Logs are just going on about the driver

I'll take a look in the FF files now

[tm6907]

Well the ./cache/mozilla/firefox and /.mozilla/firefox are empty which is the default location for temp files I believe. I wasn't sure where else to look so I just remove firefox and related files then reinstalled it.

Ghosts is running fine at the moment, but it might break again soon like before.

[tm6907]

Still broken, any idea which file in FF is causing it? If this is the issue after all?

[sei-dupdyke]

Please try this:

run a top -n 1 and log all that to a log file also inject a timestamp:

top -n 1;date > mylogfile.txt

[tm6907]

I think my issue stems from my Ansible code. I've been trying to start Ghosts with a ansible task and not seeing anything I would expect because its effectively acting on a shell I can't see. So when I've been starting & restarting Ghosts over and over either by Ansible or manually, its clogging up memory leading to the 'out of memory' I've been seeing and why rebooting solves all issues.

I tired making a script for Ansible to run that instead but no help. I think I'll have to keep my Ansible playbook to just configuring the client before starting it up.