I have installed the mqtt server mosquitto on a RPi3 and everything was working. I tried to clear all the persistence like so:
sudo cat /dev/null > /var/lib/mosquitto/mosquitto.db
After that the server did not start anymore and I had to disable persistence to get it up an running again.
How can I restore the file, such that it will work again? Btw. How can I clear the stored data without crashing the server?
mosquitto uses an in memory database. when persistence is enabled the data is written to mosquitto.db periodically and on shutdown. on startup it is read again.
your file is empty, there is nothing to load. this might be the problem.
if you just remove it and enable persistence mosquitto should create it again after restart.
if it is not there after restart you might have to wait the defaut 30min between saves. shorten that time in your config (autosave_interval) or send signal SIGUSR1 (kill -SIGUSR1 ‘mosquitto pid’)
Related
It is an existing and working application that I have in other server, same deployment process and same versions of everything, but can't understand what's happening with Puma.
Initially thought that was an issue with the SystemD service, but it turns out that after puma invokation it ends instantly and does not keep listening.
It seems that configuration is loaded and no errors are made.
The command shows the info, but it ends immediately.
What can be happening?
First, look in the log files.
Path to log files you can see in config/production/puma.rb
We use uwsgi with the python3 plugin, under nginx, to serve potentially hundreds of megabytes of data per query. Sometimes when nginx is queried from client a slow network connection, a uwsgi worker dies with "uwsgi_response_write_body_do() TIMEOUT !!!".
I understand the uwsgi python plugin reads from the iterator our app returns as fast as it can, trying to send the data over the uwsgi protocol unix socket to nginx. The HTTPS/TCP connection to the client from nginx will get backed up from a slow network connection and nginx will pause reading from its uwsgi socket. uwsgi will then fail some writes towards nginx, log that message and die.
Normally we run nginx with uwsgi buffering disabled. I tried enabling buffering, but it doesn't help as the amount of data it might need to buffer is 100s of MBs.
Our data is not simply read out of a file, so we can't use file offload.
Is there a way to configure uwsgi to pause reading from the our python iterator if that unix socket backs up?
The existing question here "uwsgi_response_write_body_do() TIMEOUT - But uwsgi_read_timeout not helping" doesn't help, as we have buffering off.
To answer my own question, adding socket-timeout = 60 is helping for all but the slowest client connection speeds.
That's sufficient so this question can be closed.
I started the influxdb. The meta server is getting started at 8088 and I am seeing a series of [wal] logs. When I try to connect with the server using influx command it throws
Failed to connect to http://localhost:8086
Please check your connection settings and ensure 'influxd' is running.
The server is running in the background. What could be the reason ? I have been writing continuously and then I restarted my server. After restarting I am not able to connect to the server. I also tried connecting after an hour of restarting to make sure it was not due to some startup tasks.
What could be the reason for this ?
The db had huge number of series and it took more than 2 hours for the meta server to be up fully. Later, the http listener was up after the initial start tasks.
I am getting the following errors and I dont know how to restart the server .I tried multiple times but I get the same error all the time.How can I stop and restart the server.I really appreciate any help.
./bin/neo4j start
displays:
/usr/local/neo4j/data/log/console.log: Permission denied
process [11825]... waiting for server to be ready.. Failed to start within 120 seconds.
Neo4j Server may have failed to start, please check the logs.
sudo ./bin/neo4j start
displays:
Another server-process is running with [ST=ESTABLISHED], cannot start a new one. Exiting.
The exception you get is because another server is running.
Also, there is another exception, you don't have write access in the folder for the logs.
Check if http://localhost:7474 is displaying the neo4j web browser.
If yes, locate the location of the running database :
Then go to the location and stop the db, eg based on the image :
cd /Users/cw/_graphs/tests
./bin/neo4j stop
If it is not working, try to kill the process :
sudo htop
kill -9 10522
And try to run your new database. And make sure you have the right permissions for the stores and logs.
how can I restart a grails application other than shutting it down by doing ctrl z and running it again.
when I do it that way it says
Error Server failed to start for port 8080: Address already in use
CTRL-Z doesn't shut down an application, sends a SIGTSTP signal to the process to suspend it... Suspended processes still have connections to their resources (ports, files, etc), so you cannot run another instance of grails on the same port whilst one is suspended.
To bring it back to the foreground, you can enter fg in the same shell (or if you want it to run in the background, you can use bg)
To shut it down, you need CTRL-C (or you can kill it as nickdos says in the comments)
To cleanly shut down a run-app or run-war, create an empty file named .kill-run-app in the top-level directory of your grails application (i.e. alongside grails-app, src, etc.). Grails will automatically delete this file once the application has been stopped, so don't be surprised when it disappears shortly after you created it.
Shutdown should not require process hacking and doesn't require a 'could ruin everything' disclaimer :)
Just run:
grails stop-app
If that still doesn't work:
lsof -i :8080 or ps aux | grep grails
Will show the process id, then first try killing it nicely:
kill 12345 (where 12345 is the processId)
Of if it really doesn't want to play nicely, then HAMMER it with:
kill -9 12345 (where 12345 is the processId)
Works every time (DISCLAIMER: Could ruin everything)