motamman - I just updated my signal server from...
I just updated my signal k server from the UI and then restarted the server. When I did that, the aws instance where it is installed became unreachable. I restarted the instance and when it came back up fragments of the signalk install were there but signal k itself was not installed. (Other, unrelated web apps, are running fine.)
I reinstalled signal k (npm install signalk-server --save) and now I am getting this:
Could not handle admin ui root request
this is my settings.json
[Unit]
Description=Signal K Server
After=network.target
[Service]
ExecStart=/home/ubuntu/.signalk/node_modules/.bin/signalk-server -v
WorkingDirectory=/home/ubuntu/.signalk
User=ubuntu
Restart=always
Environment=NODE_ENV=production
[Install]
WantedBy=multi-user.target
This server has been running up and running for many many month without a hickup
12 Replies
That’s not the correct command for installing the server.
And that’s not normally where the server is installed
Ubuntu is the username and that's where it was originally installed.
Not using our Docker file then
No
I am a bit surprised it worked at all.
And updating via the GUI definitely won’t work.
It has many many times
I don't see how
with our Dockerfile, it won't even let you use the UI to update
the command the server update via GUI uses is "npm install -g signalk-server"
installs it globally
it's done differently with our Docker file, but then it won't let you update
You update by updating your image
Ah shit. I left of the -g switch
But your start script is running from /home/ubuntu/.signalk/node_modules/.bin/signalk-server
the -g won't put it there
I will remind and start again.
That script path was me kinda guess where it was.
The cause of the crash, and subsequent corruption of the signal k install and npm, was running out of RAM on the AWS instance and not having a swapfile running to mitigate that eventuality.
I guess that is my lesson of the day. It took a good amount of time to clean up that fragmentation grenade, if you will forgive me the violent metaphor.
I was able to restore all of the node-red flows, including the ingestion my boat's mirrored data from an mqtt broker.
I have one lingering problem that I cannot figure out: I use nginx to manage my ssl. I do that because I serve up a couple of other sites and don't want to have to manage multiple certs. That may or may not have been the best choice but it worked flawlessly before the crash and now works with the exception of authenticating with KIP. With KIP I now get a 404 error trying to hit the authentication endpoint: https://xx.xx.sv/signalk/v1/auth/login
It seems strange that it is ignoring the port (3443) when trying to authenticate as that would be using the domain's default port and so should cause a 404 error. When I append that domain with the port, I get the expected response.
My working theory is that I missed something when restoring all the signalk-related nginx/ssl setup that is causing KIP to ignore the port.
Strangely if I use an insecure connection on 3000 to access KIP, I can use the my logins and interact with KIP as I always have. @David Godin, maybe you have some thoughts on this.
Hi Mo. sadly I don’t know what could cause this. If you are using a proxy try the proxy connection option.
Oh FFS, hours I messed with this, and that check box fixed it.
THANKS. I don't remember having that box checked before but maybe I did