my apologies upfront for anything that i miss, it is my first question.
I was trying to setup my raspberry as sip client.
This sipclient would trigger a bash script to trigger the gpios.
finally this would be the interface for a door latch opener.
setting up the sip client works just fine.
triggering works also fine (after figuring out that every script has to have #!/bin/bash as header!)
going through a whitelist... everything perfect.
execpt:
i was not able to manage to start twinkle as "service" on start up.
start-stop-daemon --start --quiet --user pi --pidfile /var/run/twinkle.pid --make-pidfile --background --exec /usr/bin/twinkle -- -c
did not do the job.
export DISPLAY=:1
twinkle -c
works only interactively.
with xvfb installed.
/usr/bin/Xvfb :1 -screen 0 640x480x24 -ac +extension GLX +render -noreset
but twinkle seems to stop immediately when parent process is destroyed.
i also tried linphone... but could not figure out how to trigger my script :-(
another tool i tried was asterisk, but would not install on my raspberry.
after a long install process it just stopped. thats why i set it asside. i dont have the results anymore. sorry for that.
any help is appreciated.
i went a different route:
doorpi is the tool that gave me all the possibilities that i needed.
doorpi is running in background (as service)
doorpi is able to start a sip client and with that receive calls
doorpi can use the gpios
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 use GMediaRenderer to send audio via UPNP from a Raspberry Pi. Occasionally, for reasons unknown, I have to SSH into my Pi and send the command sudo service gmediarenderer restart to get it to work properly. I'd like to add a command to crontab or similar that periodically checks whether the service is running properly. I already have a crontab entry that checks whether the service is running, and starts if it isn't. The trouble I'm having is that sometimes, even though the service is running, it doesn't appear to be communicating with UPNP control points. Executing the restart command brings it back, so I assume it is simply the case that the service has crashed but not closed down.
Does anyone know how to programmatically check (preferably using a bash script) whether the GMediaRenderer service is up and running?
I have found a solution to this. The command gssdp-discover returns a list of active renderers. I setup a sudo crontab job to run a bash script every minute that checks whether or not a particular renderer is running, and to restart gmediarenderer if it isn't found.
The following command will list your active renderers:
gssdp-discover -i wlan0 --timeout=3
Change wlan0 above depending on your specific network connection. In my case, the renderer that I'm interested in is listed as urn:av-openhome-org:service:Info:1 (run the command with and without the renderer active, and look for the one that only appears when running). So, my bash script contains the following:
gssdp-discover -i wlan0 --timeout=3 --target=urn:av-openhome-org:service:Info:1 | grep available &> /dev/null
if [ $? == 0 ]; then
echo "OpenHome renderer is already running"
else
echo "restarting gmediarenderer"
/etc/init.d/gmediarenderer stop
/etc/init.d/gmediarenderer start
fi
I connected via ssh to remoute server and started very long wget downloading. Then ssh session was broke, and after reconnect new copy of interpretator was created. Now I see wget process in ps, but is it possible to return control to old interpretator? I know that better solution is to use screen for long commands, but is there other way?
No, there is no way to reattach a process to a different terminal if it's not set up to do that (by way of screen / tmux / what have you) in the first place.
As a crude approximation, connecting a debugger to the running process may allow you to interact with it in some limited ways, but in this particular scenario, I don't think it will be beneficial.
If you want to know the progress of your currently running wget, check out the size of the downloaded file, it should be growing. If it doesn't, run killall wget and start over.
Next time, consider running wget --background to prevent the problem from happening. See the wget info page.
This command let Wget to work in the background, and write its progress to log file my.log.
Еhe number of retries 45 (-t options)
wget -t 45 -o my.log http://upload.wikimedia.org/wikipedia/commons/5/51/Google.png &
I'm creating a pallet crate for elasticsearch. I was stuck on the service not starting however after looking at the logs it seems that it's not really anything to do with pallet. I am using the elasticsearch apt package for 1.0 which includes an init script. If I run sudo service elasticsearch start then ES starts with no problems. If pallet does this for me then it records standard out as having started it successfully
start elasticsearch
* Starting Elasticsearch Server
...done.
However it is not started.
sudo service elasticsearch status
* elasticsearch is not running
I messed around with the init script and I found if I added sleep 1 after starting the daemon then it works correctly with pallet.
start-stop-daemon --start -b --user "$ES_USER" -c "$ES_USER" --pidfile "$PID_FILE" --exec $DAEMON -- $DAEMON_OPTS
#this sleep will allow it to work
#sleep 1
log_end_msg $?
I don't understand what is going on?
I've seen issues like this before, too. It generally comes down to expecting something to have finished before the script finishes, which may not always happen with services since they fork off background tasks that may still get killed when the ssh connection is terminated.
For these kinds of things you should use Pallet's built in code for running things under supervision. This also has the advantage of making it very easy to switch from plain init.d to runit or daemontools later, which is especially useful for Elasticsearch because it's a JVM process and nearly any JVM will eventually crash if you let it run long enough.
One of our application servers (Glassfish v3.0.1) keeps crushing down with no reason. Sometimes, I am away from Internet so I cannot run it back again. Therefore, I wrote a simple bash script to wait for 10 minutes and then run asadmin. It is like:
#!/bin/bash
while true;
do sleep 600;
sudo /home/ismetb/glassfishv3.0.1/glassfish/bin/asadmin start-domain;
done
This seems to work fine however I have a couple of problems:
If I terminate the bash script (by pressing ctrl+z buttons), the Java process (Glassfish) dies and start-domain and stop-domain commands do not work at all. That means, I can neither stop Glassfish nor can I access it. I do not know if anybody else experienced this problem before or not. If the process dies, only thing I can do is to look for the ID of Java process and kill it from terminal. This not desirable at all. Any ideas why Java process dies when I quit script?
What I want to add to my script is something like to check the port Glassfish is using. If port is occupied maybe I can assume that Glassfish is not down! (However, the port (8080 default) might still be used by Glassfish although Glassfish is dead, I am not sure of it). If not, then with the help of a simple code, I can get the id of the Java process and kill them all. Then start-domain command will successfully work. Any ideas or any directions on how I can do this?
You can use a cron job instead. To install a cron job for root, enter
sudo crontab -e
and add this line
*/10 * * * * /home/ismetb/glassfishv3.0.1/glassfish/bin/asadmin start-domain
This will run asadmin every ten minutes.
If you're not comfortable with the command line, you might also try gnome-schedule, but I have no experience with that.
For your second problem, you can use curl or wget to access glassfish. You can try to get some URL, or even access the administration interface, and if you don't get a response, assume glassfish is down.