I have a glassfish install and I would like to have a simple terminal command checking if it's running. If it is, it will shutdown the process. Or if it not running, it will start the server.
To start the server I can enter:
/Applications/NetBeans/glassfish-3.1.1/bin/./asadmin start-domain domain
To stop the server I can enter:
/Applications/NetBeans/glassfish-3.1.1/bin/.asadmin stop-domain domain
I will would like to make a simple Alfred.app script than can start this domain if it's not running, or stop it if it's running.
One way to do this is to note in a file the process ID of the server when it starts, and have another script check to see if that process is running.
For example, script A (to run the server unconditionally):
#!/bin/sh
/Applications/NetBeans/glassfish-3.1.1/bin/./asadmin start-domain domain
# file name is arbitrary
pgrep whateverTheProcessNameIs > ~/.glassfish-server.pid
And in script B:
#!/bin/sh
pid=`pgrep -F ~/.glassfish-server.pid` # file chosen in script A
if [ "x$pid" = "x" ] ; then
# process has died; restart by running script A
/path/to/scriptA
fi
Note that only Mac OS X 10.8 (Mountain Lion) installs pgrep by default; otherwise you'd have to use some other method (like parsing ps output) to see what processes are running.
As far as how to run this check periodically, there are various ways. I'm assuming Alfred will run any script that is executable (chmod +x scriptA scriptB) but I don't know for sure.
Related
I have a bash script that I have to regularly run on a remote server. Part of the script includes running a backup which takes a while, and after it has run, I have to hit "Y" to confirm that the backup worked before the script will continue.
I would like to know if there is a way to get my laptop to make a beep (or some sort of sound) when that happens. I know that echo -e '\a' makes a beep, but if I run it from within a script on the remote server, the beep happens on the remote server.
I have control of the script that is being run, so I could easily change it to do something special.
You could send the command through ssh back to your computer like:
ssh user#host "echo -e '\a'"
Just make sure you have ssh key authentication from your server to your computer so the command can run smoothly
In my case the offered solutions with echo didn't work. I'm using a macbook and connect to an ubuntu system. I keep the terminal open and I'd like to be informed when a long running bash script is ready.
What I did notice is that if I shutdown the remote system then it will beep the macbook and show an alarm icon on the relevant tab. So I have now implemented a bit of dirty workaround:
sudo shutdown 1440 && shutdown -c
This will initiate the system to shutdown and will immediately cancel the request. And I do get the alarm beep + icon. You will need to setup sudo to allow the user to permit shutdown. As it was my own remote server it was no problem but could limit the usability for others.
I am trying to run several roslaunch files, one after the other, from a bash script. However, when the nodes complete execution, they hang with the message:
[grem_node-1] process has finished cleanly
log file: /home/user/.ros/log/956b5e54-75f5-11e9-94f8-a08cfdc04927/grem_node-1*.log
Then I need to Ctrl-C to get killing on exit for all of the nodes launched from the launch file. Is there some way of causing nodes to automatically kill themselves on exit? Because at the moment I need to Ctrl-C every time a node terminates.
My bash script looks like this, by the way:
python /home/user/git/segmentation_plots/scripts/generate_grem_launch.py /home/user/Data2/Coco 0 /home/user/git/Async_CNN/config.txt
source ~/setupgremsim.sh
roslaunch grem_ros grem.launch config:=/home/user/git/Async_CNN/config.txt
source /home/user/catkin_ws/devel/setup.bash
roslaunch rpg_async_cnn_generator conf_coco.launch
The script setupgremsim.sh sources another catkin workspace.
Many thanks!
Thanks all for your advice. What I ended up doing was this; I launched my ROS Nodes from separate python scripts, which I then called from the bash script. In python you are able to terminate child processes with shutdown. So to provide an example for anyone else with this issue:
bash script:
#!/bin/bash
for i in {0..100}
do
echo "========================================================\n"
echo "This is the $i th run\n"
echo "========================================================\n"
source /home/timo/catkin_ws/devel/setup.bash
python planar_launch_generator.py
done
and then inside planar_launch_generator.py:
import roslaunch
import rospy
process_generate_running = True
class ProcessListener(roslaunch.pmon.ProcessListener):
global process_generate_running
def process_died(self, name, exit_code):
global process_generate_running
process_generate_running = False
rospy.logwarn("%s died with code %s", name, exit_code)
def init_launch(launchfile, process_listener):
uuid = roslaunch.rlutil.get_or_generate_uuid(None, False)
roslaunch.configure_logging(uuid)
launch = roslaunch.parent.ROSLaunchParent(
uuid,
[launchfile],
process_listeners=[process_listener],
)
return launch
rospy.init_node("async_cnn_generator")
launch_file = "/home/user/catkin_ws/src/async_cnn_generator/launch/conf_coco.launch"
launch = init_launch(launch_file, ProcessListener())
launch.start()
while process_generate_running:
rospy.sleep(0.05)
launch.shutdown()
Using this method you could source any number of different catkin workspaces and launch any number of launchfiles.
Try to do this
(1) For each launch you put in a separate shell script. So you have N script
In each script, call the launch file in xterm. xterm -e "roslaunch yourfacnylauncher"
(2) Prepare a master script which calling all N child script in the sequence you want it to be and delay you want it to have.
Once it is done, xterm should kill itself.
Edit. You can manually kill one if you know its gonna hang. Eg below
#!/bin/sh
source /opt/ros/kinetic/setup.bash
source ~/catkin_ws/devel/setup.bash
start ROScore using systemd or rc.local using lxtermal or other terminals to avoid accident kill. Then run the part which you think gonna hang or create a problem. Echo->action if necessary
xterm -geometry 80x36+0+0 -e "echo 'uav' | sudo -S dnsmasq -C /dev/null -kd -F 10.5.5.50,10.5.5.100 -i enp59s0 --bind-dynamic" & sleep 15
Stupid OUSTER LIDAR cant auto config like Veloydne and will hang here. other code cant run
killall xterm & sleep 1
Lets just kill it and continuous run other launches
xterm -e "roslaunch '/home/uav/catkin_ws/src/ouster_driver_1.12.0/ouster_ros/os1.launch' os1_hostname:=os1-991907000715.local os1_udp_dest:=10.5.5.1"
I have a shell script contain loop like this:
while true
do
if ... ; then
...
else
...
break
fi
done
I want this script to run backend while OS start. I have try to add this script into /etc/rc.d/local.rc as startup script. But OS start too long, and after OS start up, this script did not exist.
So how to add this script into backend while OS start up? And I need this script also could be start up by hand in backend. Thank you~
If you are scheduling on either Linux or Mac, then you can schedule through crontab.
Open terminal.
$crontab -e #use sudo to run as administrator
#add below line
#reboot sh /absolute_path/script.sh
Give the absolute path of the script, save the crontab and exit.
The script will start running from the next reboot.
I'm running a shell script on vagrant up via the inline shell config of a Vagrantfile. One of the commands starts up a tomcat web server which normally runs in the foreground.
My dilemma is that a) the commands in the vagrant shell script should exit or run in the background so that the prompt returns to the user correct, and b) if I send the output to the background with & the output isn't visible and the user has no idea when the web server has finished booting.
I either need a way to send output to the background and tell the user when the server has booted, or a way to send to the background once the server has booted. Without messing with the maven/tomcat side I don't see a way to do it.
$script = <<-SCRIPT
# other commands here
mvn tomcat7:run &
SCRIPT
config.vm.provision "shell", inline: $script, privileged: false, run: "always"
I use nohup command for this and redirect the output of the command in the specific log file - It does not fully answer the and tell the user when the server has booted
here's an example of a command I run
nohup java -jar /test/selenium-server-standalone-$1.jar -role hub &> /home/vagrant/nohup.grid.out&
If from the provisioning shell you'd want to give as much as possible information to the user, you could use sleep like 5/10 seconds (depending your deployment) then run tail -20 <log_file> so that would give users a good status of the progress of the task
I'm opening an ssh-session to a remote server and execute a larger (around 1000 lines) bash-script on the remote machine. It involves several very CPU-intensive calls which run for up to three minutes each. To track the scripts progress it echoes messages placed at several points in the script.
In general the script runs smoothly. From time to time the script runs trough (the resulting file on the remote machine is correct) but the output to the terminal stops. Ctrl-C doesn't help, no prompt, just a frozen session. top in a separate session shows normal execution of the script.
My question: How keep the session alive?
local machine:
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.9
BuildVersion: 13A603
remote machine:
$ lsb_release -d
Description: Ubuntu 12.04.3 LTS
Personally, I would recommend using screen or tmux on the remote terminal for exactly this reason.
Those apps will allow the remote process to continue even if your local SSH session times out.
http://www.bangmoney.org/presentations/screen.html
http://tmux.sourceforge.net/
Start a screen on the remote machine and run your command from it:
screen -S largeScript
And then
./yourLargeScript.sh
Whenever your ssh session gets frozen, you can kill it with ~.
If you ssh again, you can grab back your screen by:
screen -dr largeScript
Make it log to a file instead (perhaps via syslog), and tail that file from wherever is convenient for you. This also helps detach the script so you can run it headless, from a cron job, etc. Also, if the log file has read access for others, they too can monitor it.