i am not sure what will happen so i am asking this question and also because i didn't tested this.i have a function send command which sends commands to remote machine and it works fine for normal commands but what if it sends command for reboot like below.
sendcommand reload
expect -re "$prompt"
send -- "exit"
expect eof
i mean after reload how would the rest of the script going to excecute or it will thorugh some error or it will work fine? please guide.
It depends on exactly how you ask for the reboot to be done. Rebooting may be done by asking the system to restart, and the time to process that might allow you to exit. Or it might not; there's a race condition. You certainly need to drop the network connection though; when the OS comes back, it won't recognize it and you'll get a forced connection reset (if not before).
Or you could ask it to reboot a couple of seconds in the future (I forget the exact syntax for this) to give yourself time to disconnect. Some individual research and experimentation is likely to be needed; VMs are good for this as they restart much more rapidly…
Related
I have a ubuntu server and i want to monitor it and start mysql service if it goes down, what can i do programatically to implement this.
I see this solution and set it via cron to execute every minute.
#!/bin/bash
if [[ ! "$(/usr/sbin/service mysql status)" =~ "start/running" ]]
then
/usr/sbin/service mysql start
fi
but would setting a cron to execute every minute load my server.
Any help in this direction will be appreciated. Thanks.
For the most part, running a short script like that every minute won't stress your server. So programmatically, assuming you tested it and all, I don't see much wrong with your approach.
I'd be more concerned as to why your service randomly shuts down though, have you looked for clues in logs? Depending on the severity of the cause, perhaps implementing a monitoring tool like nagios or icinga might be useful.
First time running queries in rails console...
I had a query run accidentally: something like this
User.where(:location => 'US'))
which apparently is pulling me quite amount of data.
Now the query is still hanging there. I know I could just close this session and restart another. But I just would like to know the safest way to kill a query. Is there something similar like in mysql :
show full processlist
and
kill #
When I want to stop a long running query, I typically just go up the chain of interrupts.
ctrl c will send SIGINT and hopefully just take you out of the current query or loop in the console. But, sometimes, this won't work so I go up a step to
ctrl \ which will send SIGQUIT to quit the current process. This command will exit out of the rails console and back in to the terminal (assuming you launched the console from rails c)
As a worst case scenario I will go to use ctrl z which will suspend the process allowing you to find the process ID (using top or ps or whatever else) and then use kill on that pid. If that doesn't work the final thing to use is kill -9 which will kill the process.
I want to use gearman as a queue-system for a webproject. Therefor I tried gearman and gearmanManager which works great. But know, I ask myself what happen if a worker, job or server has gone (for example php error or whatever the reason might be).
What happens if I run an synchron job where the client (browser)
waits for a callback and the worker/server crashed?
What happens if there is an asynchronus job which chrashed while it is in work? Will gearman try it again (cause it is stored as a queue in mysql) or will gearman ignore it? And what happen to it if it will not be ignored and the worker crash over and over again?
I would like to found out if the system ist scalabel (for example by NFS). Do you have examples for me or experiences on which I can get forward?
Thank you all and have a very nice weekend...
Phil
If the server has crashed, your client won't have anything to connect to. How you handle that is up to your application. If the worker has crashed, and you're attempting to run a synchronous task, the client will wait until a worker becomes available, unless you've provided a timeout value.
If the async task is performed and the worker, gearman will requeue the task at hand. If it crashes each worker that grabs it, you might be left without any active workers. The C-version / gearmand has an option to tweak this behavior:
-j [ --job-retries ] arg (=0) Number of attempts to run the job
before the job server removes it. This
is helpful to ensure a bad job does not
crash all available workers. Default is
no limit.
If you deploy broken or fragile code you will have issues, regardless of which system you're using. Bad code breaks applications. :-)
A Gearman setup is scalable, but remember that if you use the persistent queue support, each server needs to have it own backend. You can't share the same database and tables across server instances, since the persistent queue is only maintained as a backup in case gearmand dies and has to be restarted. It might be more useful to allow your application to easily queue tasks again if needed.
How can i delete the mysql process which is not used any more?
I am creating 1000 sql connection and some are not in use any more. I want to delete all the unused process.
you can list all active connections using the show processlist statement, and then kill the ones you don't need using the command kill {connectionid} . as others have pointed out, this is not a thing you should do often, instead try to fix the application so that unused connections are closed correctly.
You should modify the client application so it closes its connections when they are not needed.
Leaving connections open for a long time is usually counter-productive, it's often done as a (misguided, premature) optimisation. It causes problems because:
Connections are not stateless, and unexpected state causes problems
Connections get closed by the server after a while, or from network problems, leading to "morning bugs".
It is much better to close connections as soon as you're finished with them, in the general case.
This command will restart the server and close all open connections:
/etc/init.d/mysqld restart
You may however want to look into why the connections have not been closed in the first place. Your program is not supposed to leave 1000 connections unclosed.
I'm experiencing "mysql server has gone away" in my import script written in php
This http://dev.mysql.com/doc/refman/5.0/en/gone-away.html page has a list of possible reasons. But, how do I debug this, to know which of the reasons?
If some time out fired, I want to know which that his happened, which timeout etc. relevant details. If the query was broken, I want to know that this is the reason.
So, do I have a way to receive the details additionally to just the very global piece of information that the server "has gone away"?
Is there a way to log this stuff: timeouts for example?
I wouldn't think that there's a MySQL magic bullet to find out. It sounds like you need to use operating system and/or network diagnostic tools. Maybe within PHP you can do some things like try pinging the server, checking if the MySQL daemon is running, etc. You might also want to check into using a tool such as Wireshark or tcpdump to see if you're seeing anything funky on the network, such as reset packets or other dropped connection indicators.
If the MySQL server is remote, try doing a constant ping to it and see if you're seeing dropped or delayed packets. Make sure you check with large packets; I've seen systems on which a ping works fine, but routers screw up larger packet sizes due to MTU mismatches and such. On Windows, it is:
ping -t -l 1500 mysqlhost
On most Linux and Unix systems, it is:
ping -s 1500 mysqlhost