I have many data-servers I need to download data from via http as soon as it is available. For each server I start a bash "while true"-loop and within that a wget to poll the server for new data. To start all the bashs I created a tmux config starting a window for every loop such loop and wget. This adds the benefit of easier inspecting what is happening.
I want to create a supervisor-service from this config, which would allow me to start, stop, and restart this tmux and its downloading clients all at once.
However, when I quit tmux, by the very nature of tmux, the bashs and their wgets keep running. Is there a way around that, so I can quit everything and restart everything with a simple supvervisorctl tmuxservice restart?
Related
Im writing a tool and one of its commands allows you to start a new session
How can I make a golang program restart itself? If your solution is OS-Strict im on Linux.
I tried
// exec from os/exec
exec.Command(os.Args[0]).Run()
but it doesnt work. I get a blank input session which is hard to explain
My Program Input: session new
:(
:(
each of the :( represent a blank line where im able to type stuff and hit enter, there are 2 which means i hit enter twice
Im expecting
My Program Input: session new
My Program Input:
Edit: more accurately, i want to make a subprocess of the same program
You could use a separate process, like radovskyb/gobeat.
Example:
sudo gobeat -pid=1234 -cmd="go run sendemail.go"
Run with sudo so gobeat will restart the server in the same terminal tty that it originated in. (sudo)
Point gobeat to the process of the running server that you want gobeat to monitor. (gobeat -pid=1234)
Set the cmd flag to run a Go file that will send an email notifying you that the server was restarted. (-cmd="go run sendemail.go")
If you do not want a separate process, then consider implementing a graceful upgrade
You can use the library cloudflare/tableflip for instance.
So we are using Putty to connect to our server. Sometime when a user is running a job, they would have to wait for the job to be done before they can close the session. If they close the session before the job is done, it would corrupted. I wonder is there anyway we can stop the user from closing the session when something is running.
No, there is not. Tell your clients to use the screen command. This will create a separate session, then you run the long-running command (batch, ...). If you're disconnected, you just have to run screen -r to reconnect.
I have to restart 100's of scripts for at least 20+ users once the server restarts for any reason. I wanted to come up with a single script to trigger of all scripts/programs under all users with just one script (without root privilege).
Is it possible to do so? Linux If not, what is the best approach to proceed?
Thanks,
You can make a boot script in /etc/init.d/rc3.d that will use su - someuser -c somescript for the different users.
When you want the different users to control which scripts they want, you can give them control over the somescript (perhaps $HOME/bin/startme.sh).
When you are anxious that the scripts are always running, you can consider another approach: do not start them at a server restart, but put them in monitoring script in the users crontab. Each minute (or 5 minutes or hour) this monitor script can check the running scripts and restart them when needed.
I'm having issues keeping the queue:work command running on my server. I tried nohup, but as soon as I close the terminal (which times out every 5 minutes or so no matter what I've tried) the process goes away.
I thought about running a script in cron to kick off the nohup command, however that runs in jailshell too so I have no way of seeing if the process is still running from a previous cron or not and I don't want a potential 20k copies of this running because it's trying to kick off every minute.
I also don't have access to install software to install Supervisord.
So, what other solutions can I use to ensure this stays running?
EDIT I contacted the support for my host, and pretty much it looks like there are no real alternatives for me. I think I'm going to have to set this project up on Linode, or rework things to not have queuing tasks.
It seems that the problem resides in the shell configuration, because the command ps is rewritten to show only the children process.
The solution is to ask your hosting provider (or change it yourself if allowed) to set this variable:
SHELL="/bin/bash"
This simple fix allowed me to have the function working properly.
Now my Kernel.php looks as follows:
$command = "ps faux | grep queue:work";
exec($command, $task_list);
// Process are duplicate in ps and show also the command as two single lines
$running_process = (count($task_list) / 2) - 1;
if($running_process < 1)
$schedule->command('queue:work --queue=high,low --tries=3')
->everyMinute();
else if($running_process > 5)
// If too many are active, restart everything to avoid overload
$schedule->call(function(){
Artisan::call('queue:restart');
})->everyMinute();
This code makes sure that at least one worker is always running, and at the same time forces a restart if you have more that 5 workers active.
So I've got dozens of servers I connect to and want a simple Ruby script that provides me with a list of those servers. Picking one will start up SSH with the proper connection details and let me start using it. That's it!
But, I don't want/need Ruby to keep running. If I did I could use Net::SSH and capture all output and send it back to the user, but this is an extra layer I don't need. I simply want to use Ruby as a "script starter" and then close itself.
Any ideas? I've thought about forking processes but I don't know how I'd attach the terminal to the new ssh one.
I have a simple bash script that does this already, but I want to add more functionality like being able to add to the list, remove servers, etc. all from the command line. I'm sure I could do this with bash as well but I'm much more comfortable with Ruby.
Maybe exec will do the trick
http://en.wikipedia.org/wiki/Exec_(operating_system)
http://ruby-doc.org/core/classes/Kernel.html#M005968