Related
The Upstart script using the start-stop-daemon we've been using for Play 1.2.7 is now unable to stop/restart Play since Play 1.3 due to it having an incorrect PID.
Framework version: 1.3.0 on Ubuntu 12.04.5 LTS
Reproduction steps:
Setup an upstart script (playframework.conf) for a Play application
Play application starts successfully on server reboot Run 'sudo
status playframework' will return playframework start/running,
process 28912 - At this point process 28912 doesn't exist
vi {playapplicationfolder}/server.pid shows 28927
'stop playframework'
then fails due to unknown pid 28912 'status playframework' results in
playframework stop/killed, process 28912
Only way to restart play framework after this point is to either find the actual process and kill it then start play using the usual 'play start' command manually. Or restart the server.
This has broken our deployments scripts now as we used to install the new version of our app, then do play restart before reconnecting to the load balancer.
Upstart Script:
#Upstart script for a play application that binds to an unprivileged user.
# put this into a file like /etc/init/playframework
# you can then start/stop it using either initctl or start/stop/restart
# e.g.
# start playframework
description "PlayApp"
author "-----"
version "1.0"
env PLAY_BINARY=/opt/play/play
env JAVA_HOME=/usr/lib/jvm/java-7-openjdk-amd64
env HOME=/opt/myapp/latest
env USER=ubuntu
env GROUP=admin
env PROFILE=prod
start on (filesystem and net-device-up IFACE=lo) or runlevel [2345]
stop on runlevel [!2345]
limit nofile 65536 65536
respawn
respawn limit 10 5
umask 022
expect fork
pre-start script
test -x $PLAY_BINARY || { stop; exit 0; }
test -c /dev/null || { stop; exit 0; }
chdir ${HOME}
rm ${HOME}/server.pid || true
/opt/configurer.sh
end script
pre-stop script
exec $PLAY_BINARY stop $HOME
end script
post-stop script
rm ${HOME}/server.pid || true
end script
script
exec start-stop-daemon --start --exec $PLAY_BINARY --chuid $USER:$GROUP --chdir $HOME -- start $HOME -javaagent:/opt/newrelic/newrelic.jar --%$PROFILE -Dprecompiled=true --http.port=8080 --https.port=4443
end script
We've tried specifying the PID file in the start-stop-daemon as per: http://man.he.net/man8/start-stop-daemon however this also didnt seem to have any effect.
I have found some threads on similar issues https://askubuntu.com/questions/319199/upstart-tracking-wrong-pid-of-process-not-respawning but have been unable to find a way round this so far. I have tried changing fork to daemon but the same issue remains. I also can't see what has changed between Play 1.2.7 and 1.3 to cause this.
Another SO post has also asked a similar question but not had an answer as yet: https://stackoverflow.com/questions/23117345/upstart-gets-wrong-pid-after-launching-celery-with-start-stop-daemon
This is because getJavaVersion() spawns a subprocess, which bumps the PID count, which breaks Upstart, the latter which expects Play to fork exactly none, once or twice, depending on which expect stanza you use.
I've fixed this in a pull request.
On an Amazon S3 Linux instance, I have two scripts called start_my_app and stop_my_app which start and stop forever (which in turn runs my Node.js application). I use these scripts to manually start and stop my Node.js application. So far so good.
My problem: I also want to set it up such that start_my_app is run whenever the system boots up. I know that I need to add a file inside init.d and I know how to symlink it to the proper directory within rc.d, but I can't figure out what actually needs to go inside the file that I place in init.d. I'm thinking it should be just one line, like, start_my_app, but that hasn't been working for me.
First create your startup script # /home/user/startup.sh, and make it executable
chmod +x /home/user/startup.sh
Then set a crontab for it:
$ crontab -e
#reboot /home/user/startup.sh
Now your your startup.sh script will run at every start.
The file you put in /etc/init.d/ have to be set to executable with:
chmod +x /etc/init.d/start_my_app
As pointed out by #meetamit, if it still does not run you might have to create a symbolic link to the file in /etc/rc.d/
ln -s /etc/init.d/start_my_app /etc/rc.d/
Please note that on the latest versions of Debian, this will not work as your script will have to be LSB compliant (provide at least the following actions: start, stop, restart, force-reload, and status):
https://wiki.debian.org/LSBInitScripts
As a note, you should always use the absolute path to files in your scripts instead of the relative one, it may solve unexpected issues:
/var/myscripts/start_my_app
Finally, make sure that you included the shebang on top of the file:
#!/bin/sh
A simple approach is to add a line in /etc/rc.local :
/PATH/TO/MY_APP &
or if you want to run the command as a special user :
su - USER_FOOBAR -c /PATH/TO/MY_APP &
(the trailing ampersand backgrounds the process and allows the rc.local to continue executing)
If you want a full init script, debian distro have a template file, so :
cp /etc/init.d/skeleton /etc/init.d/your_app
and adapt it a bit.
This is the way I do it on Red Hat Linux systems.
Put your script in /etc/init.d, owned by root and executable. At the top of the script, you can give a directive for chkconfig. Example, the following script is used to start a Java application as user oracle.
The name of the script is /etc/init.d/apex
#!/bin/bash
# chkconfig: 345 99 10
# Description: auto start apex listener
#
case "$1" in
'start')
su - oracle -c "cd /opt/apex ; java -jar apex.war > logs/apex.log 2>logs/apex_error.log &";;
'stop')
echo "put something to shutdown or kill the process here";;
esac
This says that the script must run at levels 3, 4, and 5, and the priority for start/stop is 99 and 10.
Then, as user root you can use chkconfig to enable or disable the script at startup:
chkconfig --list apex
chkconfig --add apex
And you can use service start/stop apex.
Enter cron using sudo:
sudo crontab -e
Add a command to run upon start up, in this case a script:
#reboot sh /home/user/test.sh
Save:
Press ESC then :x to save and exit, or hit ESC then ZZ (that's shift+zz)
Test Test Test:
Run your test script without cron to make sure it actually works.
Make sure you saved your command in cron, use sudo crontab -e
Reboot the server to confirm it all works sudo #reboot
Just have a line added to your crontab..
Make sure the file is executable:
chmod +x /path_to_you_file/your_file
To edit crontab file:
crontab -e
Line you have to add:
#reboot /path_to_you_file/your_file
That simple!
Another option is to have an #reboot command in your crontab.
Not every version of cron supports this, but if your instance is based on the Amazon Linux AMI then it will work.
Edit the rc.local file using nano or gedit editor and add your scripts in it. File path could be /etc/rc.local or /etc/rc.d/rc.local.
sudo nano /etc/rc.local
This is the edit:
#!/bin/sh
/path-to-your-script/your-scipt-name.sh
once done press ctrl+o to update, pressEnter then ctrl+x.
Make the file executable.
sudo chmod 755 /etc/rc.local
Then initiate the rc-local service to run script during boot.
sudo systemctl start rc-local
You can do it :
chmod +x PATH_TO_YOUR_SCRIPT/start_my_app
then use this command
update-rc.d start_my_app defaults 100
Please see this page on Cyberciti.
Many answers on starting something at boot, but often you want to start it just a little later, because your script depends on e.g. networking. Use at to just add this delay, e.g.:
at now + 1 min -f /path/yourscript
You may add this in /etc/rc.local, but also in cron like:
# crontab -e
#reboot at now + 1 min -f /path/yourscript
Isn't it fun to combine cron and at? Info is in the man page man at.
As for the comments that #reboot may not be widely supported, just try it. I found out that /etc/rc.local has become obsolete on distros that support systemd, such as ubuntu and raspbian.
The absolute easiest method if all you want to run is a simple script, (or anything) is if you have a gui to use system > preferences then startup apps.
just browse to the script you want and there you go. (make script executable)
This simple solution worked for me on an Amazon Linux instance running CentOS.
Edit your /etc/rc.d/rc.local file and put the command there. It is mentioned in this file that it will be executed after all other init scripts. So be careful in that regards. This is how the file looks for me currently.. Last line is the name of my script.
Create your own /init executable
This is not what you want, but it is fun!
Just pick an arbitrary executable file, even a shell script, and boot the kernel with the command line parameter:
init=/path/to/myinit
Towards the end of boot, the Linux kernel runs the first userspace executable at the given path.
Several projects provide popular init executables used by major distros, e.g. systemd, and in most distros init will fork a bunch of processes used in normal system operation.
But we can hijack /init it to run our own minimal scripts to better understand our system.
Here is a minimal reproducible setup: https://github.com/cirosantilli/linux-kernel-module-cheat/tree/f96d4d55c9caa7c0862991025e1291c48c33e3d9/README.md#custom-init
I refered to this blog, always sound a good choice
https://blog.xyzio.com/2016/06/14/setting-up-a-golang-website-to-autorun-on-ubuntu-using-systemd/
vim /lib/systemd/system/gosite.service
Description=A simple go website
ConditionPathExists=/home/user/bin/gosite
[Service]
Restart=always
RestartSec=3
ExecStart=/home/user/bin/gosite
[Install]
WantedBy=multi-user.target
systemctl enable gosite.service
multi ways to finish it:
crontab
rc.local
init.d
systemd
For Debian 9 see https://askubuntu.com/questions/228304/how-do-i-run-a-script-at-start-up. It is helped me. Short version for Debian 9:
add commands (as root) to /etc/rc.local
/path_to_file/filename.sh || exit 1 # Added by me
exit 0
Probably, /path_to_file/filename.sh should be executable (I think so).
In Lubuntu I had to deal with the opposite situation. Skype start running after booting and I found in ~/.config/autostart/ the file skypeforlinux.desktop. The content of the file is as follows:
[Desktop Entry]
Name=Skype for Linux
Comment=Skype Internet Telephony
Exec=/usr/bin/skypeforlinux
Icon=skypeforlinux
Terminal=false
Type=Application
StartupNotify=false
X-GNOME-Autostart-enabled=true
Deleting this file helped me.
Here is a simpler method!
First: write a shell script and save it a .sh
here is an example
#!/bin/bash
Icoff='/home/akbar/keyboardONOFF/icon/Dt6hQ.png'
id=13
fconfig=".keyboard"
echo "disabled" > $fconfig
xinput float $id
notify-send -i $Icoff "Internal Keyboard disabled";
this script will disable the internal keyboard at startup.
Second: Open the application " Startup Application Preferences"
enter image description here
enter image description here
Third: click Add.
fourth: in the NAME section give a name.
fifth: In the command section browse to your .sh .
sixth: edit your command section to:
bash <space> path/to/file/<filename>.sh <space> --start
seventh: click Add. Thats it! Finished!
Now confirm by rebooting your pc.
cheers!
Add your script to /etc/init.d/ directory
Update your rc run-levels:
$ update-rc.d myScript.sh defaults NN where NN is the order in which it should be executed. 99 for example will mean it would be run after 98 and before 100.
Painless, easiest and the most universal method is simply
executing it with ~.bash_profile or ~.profile (if you don't have bash_profile file).
Just add the execution command at the bottom of that file and it will be executed when system started.
I have this one at the bottom an example;
~\Desktop\sound_fixer.sh
Working with Python 3 microservices or shell; using Ubuntu Server 18.04 (Bionic Beaver) or Ubuntu 19.10 (Eoan Ermine) or Ubuntu 18.10 (Cosmic Cuttlefish) I always do like these steps, and it worked always too:
Creating a microservice called p example "brain_microservice1.service" in my case:
$ nano /lib/systemd/system/brain_microservice1.service
Inside this new service that you are in:
[Unit]
Description=brain_microservice_1
After=multi-user.target
[Service]
Type=simple
ExecStart=/usr/bin/python3.7 /root/scriptsPython/RUN_SERVICES/microservices /microservice_1.py -k start -DFOREGROUND
ExecStop=/usr/bin/python3.7 /root/scriptsPython/RUN_SERVICES/microservices/microservice_1.py -k graceful-stop
ExecReload=/usr/bin/python3.7 /root/scriptsPython/RUN_SERVICES/microservices/microservice_1.py -k graceful
PrivateTmp=true
LimitNOFILE=infinity
KillMode=mixed
Restart=on-failure
RestartSec=5s
[Install]
WantedBy=multi-user.target
Give the permissions:
$ chmod -X /lib/systemd/system/brain_microservice*
$ chmod -R 775 /lib/systemd/system/brain_microservice*
Give the execution permission then:
$ systemctl daemon-reload
Enable then, this will make then always start on startup
$ systemctl enable brain_microservice1.service
Then you can test it;
$ sudo reboot now
Finish = SUCCESS!!
This can be done with the same body script to run shell, react ... database startup script ... any kind os code ... hope this help u...
...
For some people, this will work:
You could simply add the following command into System → Preferences → Startup Applications:
bash /full/path/to/your/script.sh
I have a node.js script which need to start at boot and run under the www-data user. During development I always started the script with:
su www-data -c 'node /var/www/php-jobs/manager.js
I saw exactly what happened, the manager.js works now great. Searching SO I found I had to place this in my /etc/rc.local. Also, I learned to point the output to a log file and to append the 2>&1 to "redirect stderr to stdout" and it should be a daemon so the last character is a &.
Finally, my /etc/rc.local looks like this:
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
su www-data -c 'node /var/www/php-jobs/manager.js >> /var/log/php-jobs.log 2>&1 &'
exit 0
If I run this myself (sudo /etc/rc.local): yes, it works! However, if I perform a reboot no node process is running, the /var/log/php-jobs.log does not exist and thus, the manager.js does not work. What is happening?
In this example of a rc.local script I use io redirection at the very first line of execution to my own log file:
#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.
exec 1>/tmp/rc.local.log 2>&1 # send stdout and stderr from rc.local to a log file
set -x # tell sh to display commands before execution
/opt/stuff/somefancy.error.script.sh
exit 0
On some linux's (Centos & RH, e.g.), /etc/rc.local is initially just a symbolic link to /etc/rc.d/rc.local. On those systems, if the symbolic link is broken, and /etc/rc.local is a separate file, then changes to /etc/rc.local won't get seen at bootup -- the boot process will run the version in /etc/rc.d. (They'll work if one runs /etc/rc.local manually, but won't be run at bootup.)
Sounds like on dimadima's system, they are separate files, but /etc/rc.d/rc.local calls /etc/rc.local
The symbolic link from /etc/rc.local to the 'real' one in /etc/rc.d can get lost if one moves rc.local to a backup directory and copies it back or creates it from scratch, not realizing the original one in /etc was just a symbolic link.
I ended up with upstart, which works fine.
In Ubuntu I noticed there are 2 files. The real one is /etc/init.d/rc.local; it seems the other /etc/rc.local is bogus?
Once I modified the correct one (/etc/init.d/rc.local) it did execute just as expected.
You might also have made it work by specifying the full path to node. Furthermore, when you want to run a shell command as a daemon you should close stdin by adding 1<&- before the &.
I had the same problem (on CentOS 7) and I fixed it by giving execute permissions to /etc/local:
chmod +x /etc/rc.local
if you are using linux on cloud, then usually you don't have chance to touch the real hardware using your hands. so you don't see the configuration interface when booting for the first time, and of course cannot configure it. As a result, the firstboot service will always be in the way to rc.local. The solution is to disable firstboot by doing:
sudo chkconfig firstboot off
if you are not sure why your rc.local does not run, you can always check from /etc/rc.d/rc file because this file will always run and call other subsystems (e.g. rc.local).
I got my script to work by editing /etc/rc.local then issuing the following 3 commands.
sudo mv /filename /etc/init.d/
sudo chmod +x /etc/init.d/filename
sudo update-rc.d filename defaults
Now the script works at boot.
I am using CentOS 7.
$ cd /etc/profile.d
$ vim yourstuffs.sh
Type the following into the yourstuffs.sh script.
type whatever you want here to execute
export LD_LIBRARY_PATH=/usr/local/cuda-7.0/lib64:$LD_LIBRARY_PATH
Save and reboot the OS.
I have used rc.local in the past. But I have learned from my experience that the most reliable way to run your script at the system boot time is is to use #reboot command in crontab. For example:
#reboot path_to_the_start_up_script.sh
This is most probably caused by a missing or incomplete PATH environment variable.
If you provide full absolute paths to your executables (su and node) it will work.
It is my understanding that if you place your script in a certain RUN Level, you should use ln -s to link the script to the level you want it to work in.
first make the script executable using
sudo chmod 755 /path/of/the/file.sh
now add the script in the rc.local
sh /path/of/the/file.sh
before exit 0
in the rc.local,
next make the rc.local to executable with
sudo chmod 755 /etc/rc.local
next to initialize the rc.local use
sudo /etc/init.d/rc.local start
this will initiate the rc.local
now reboot the system.
Done..
I found that because I was using a network-oriented command in my rc.local, sometimes it would fail. I fixed this by putting sleep 3 at the top of my script. I don't know why but it seems when the script is run the network interfaces aren't properly configured or something, and this just allows some time for the DHCP server or something. I don't fully understand but I suppose you could give it a try.
I had exactly same issue, the script was running fine locally but when I reboot/power-on it was not.
I resolved the issue by changing the file path. Basically need to give the complete path in the script. While running locally, file can be accessed but when running on reboot, local path will not be understood.
1 Do not recommend using root to run the apps such as node app.
Well you can do it but may catch more exceptions.
2 The rc.local normally runs as root user.
So if the your script should runs as another user such as www U should make sure the PATH and other environment is ok.
3 I find a easy way to run a service as a user:
sudo -u www -i /the/path/of/your/script
Please prefer the sudo manual~
-i [command]
The -i (simulate initial login) option runs the shell specified by the password database entry of the target user as a loginshell...
rc.local only runs on startup. If you reboot and want the script to execute, it needs to go into the rc.0 file starting with the K99 prefix.
I need a program in Nokia N900 - Meego Linux - to be always on if it dies it must restart by itself how do i do it?
I would like to use it on 'x11vnc'
also maybe start the process again if its killed by any other process, restarting itself again
Add your process to /etc/inittab, and let init restart your process when it terminates.
I.e.
mp:2345:respawn:/usr/app/bin/my_process
See inittab(5) for details.
(Credit goes to Lew Pitcher, http://forum.soft32.com/linux2/process-alive-ftopict10675.html)
Using inittab as suggested by blinry is good when you have root access.
When you don't have root access, you can run a shell in screen and have it do this:
$ while true; do run_program; done
This is assuming that your "run_program" script does not go into the background otherwise the loop will keep on spawning instances of "run_program" indefinitely.
I ended up using daemon, which I installed from apt-get. It has an argument -r that should restart my command if it dies. So my final command ended up being:
daemon -u www-data -n arbitrary_name -r -X "ffmpeg blah blah blah"
I'm trying to ensure a script remains running on a development server. It collates stats and provides a web service so it's supposed to persist, yet a few times a day, it dies off for unknown reasons. When we notice we just launch it again, but it's a pain in the rear and some users don't have permission (or the knowhow) to launch it up.
The programmer in me wants to spend a few hours getting to the bottom of the problem but the busy person in me thinks there must be an easy way to detect if an app is not running, and launch it again.
I know I could cron-script ps through grep:
ps -A | grep appname
But again, that's another hour of my life wasted on doing something that must already exist... Is there not a pre-made app that I can pass an executable (optionally with arguments) and that will keep a process running indefinitely?
In case it makes any difference, it's Ubuntu.
I have used a simple script with cron to make sure that the program is running. If it is not, then it will start it up. This may not be the perfect solution you are looking for, but it is simple and works rather well.
#!/bin/bash
#make-run.sh
#make sure a process is always running.
export DISPLAY=:0 #needed if you are running a simple gui app.
process=YourProcessName
makerun="/usr/bin/program"
if ps ax | grep -v grep | grep $process > /dev/null
then
exit
else
$makerun &
fi
exit
Then add a cron job every minute, or every 5 minutes.
Monit is perfect for this :)
You can write simple config files which tell monit to watch e.g. a TCP port, a PID file etc
monit will run a command you specify when the process it is monitoring is unavailable/using too much memory/is pegging the CPU for too long/etc. It will also pop out an email alert telling you what happened and whether it could do anything about it.
We use it to keep a load of our websites running while giving us early warning when something's going wrong.
-- Your faithful employee, Monit
Notice: Upstart is in maintenance mode and was abandoned by Ubuntu which uses systemd. One should check the systemd' manual for details how to write service definition.
Since you're using Ubuntu, you may be interested in Upstart, which has replaced the traditional sysV init. One key feature is that it can restart a service if it dies unexpectedly. Fedora has moved to upstart, and Debian is in experimental, so it may be worth looking into.
This may be overkill for this situation though, as a cron script will take 2 minutes to implement.
#!/bin/bash
if [[ ! `pidof -s yourapp` ]]; then
invoke-rc.d yourapp start
fi
If you are using a systemd-based distro such as Fedora and recent Ubuntu releases, you can use systemd's "Restart" capability for services. It can be setup as a system service or as a user service if it needs to be managed by, and run as, a particular user, which is more likely the case in OP's particular situation.
The Restart option takes one of no, on-success, on-failure, on-abnormal, on-watchdog, on-abort, or always.
To run it as a user, simply place a file like the following into ~/.config/systemd/user/something.service:
[Unit]
Description=Something
[Service]
ExecStart=/path/to/something
Restart=on-failure
[Install]
WantedBy=graphical.target
then:
systemctl --user daemon-reload
systemctl --user [status|start|stop|restart] something
No root privilege / modification of system files needed, no cron jobs needed, nothing to install, flexible as hell (see all the related service options in the documentation).
See also https://wiki.archlinux.org/index.php/Systemd/User for more information about using the per-user systemd instance.
I have used from cron "killall -0 programname || /etc/init.d/programname start". kill will error if the process doesn't exist. If it does exist, it'll deliver a null signal to the process (which the kernel will ignore and not bother passing on.)
This idiom is simple to remember (IMHO). Generally I use this while I'm still trying to discover why the service itself is failing. IMHO a program shouldn't just disappear unexpectedly :)
Put your run in a loop- so when it exits, it runs again... while(true){ run my app.. }
I couldn't get Chris Wendt solution to work for some reason, and it was hard to debug. This one is pretty much the same but easier to debug, excludes bash from the pattern matching. To debug just run: bash ./root/makerun-mysql.sh. In the following example with mysql-server just replace the value of the variables for process and makerun for your process.
Create a BASH-script like this (nano /root/makerun-mysql.sh):
#!/bin/bash
process="mysql"
makerun="/etc/init.d/mysql restart"
if ps ax | grep -v grep | grep -v bash | grep --quiet $process
then
printf "Process '%s' is running.\n" "$process"
exit
else
printf "Starting process '%s' with command '%s'.\n" "$process" "$makerun"
$makerun
fi
exit
Make sure it's executable by adding proper file permissions (i.e. chmod 700 /root/makerun-mysql.sh)
Then add this to your crontab (crontab -e):
# Keep processes running every 5 minutes
*/5 * * * * bash /root/makerun-mysql.sh
The supervise tool from daemontools would be my preference - but then everything Dan J Bernstein writes is my preference :)
http://cr.yp.to/daemontools/supervise.html
You have to create a particular directory structure for your application startup script, but it's very simple to use.
first of all, how do you start this app? Does it fork itself to the background? Is it started with nohup .. & etc? If it's the latter, check why it died in nohup.out, if it's the first, build logging.
As for your main question: you could cron it, or run another process on the background (not the best choice) and use pidof in a bashscript, easy enough:
if [ `pidof -s app` -eq 0 ]; then
nohup app &
fi
You could make it a service launched from inittab (although some Linuxes have moved on to something newer in /etc/event.d). These built in systems make sure your service keeps running without writing your own scripts or installing something new.
It's a job for a DMD (daemon monitoring daemon). there are a few around; but I usually just write a script that checks if the daemon is running, and run if not, and put it in cron to run every minute.
Check out 'nanny' referenced in Chapter 9 (p197 or thereabouts) of "Unix Hater's Handbook" (one of several sources for the book in PDF).
A nice, simple way to do this is as follows:
Write your server to die if it can't listen on the port it expects
Set a cronjob to try to launch your server every minute
If it isn't running it'll start, and if it is running it won't. In any case, your server will always be up.
I think a better solution is if you test the function, too. For example, if you had to test an apache, it is not enough only to test, if "apache" processes on the systems exist.
If you want to test if apache OK is, then try to download a simple web page, and test if your unique code is in the output.
If not, kill the apache with -9 and then do a restart. And send a mail to the root (which is a forwarded mail address to the roots of the company/server/project).
It's even simplier:
#!/bin/bash
export DISPLAY=:0
process=processname
makerun="/usr/bin/processname"
if ! pgrep $process > /dev/null
then
$makerun &
fi
You have to remember though to make sure processname is unique.
One can install minutely monitoring cronjob like this:
crontab -l > crontab;echo -e '* * * * * export DISPLAY=":0.0" && for
app in "eiskaltdcpp-qt" "transmission-gtk" "nicotine";do ps aux|grep
-v grep|grep "$app";done||"$app" &' >> crontab;crontab crontab
disadvantage is that the app names you enter have to be found in ps aux|grep "appname" output and at same time being able to be launched using that name: "appname" &
also you can use the pm2 library.
sudo apt-get pm2
And if its a node app can install.
Sudo npm install pm2 -g
them can run the service.
linux service:
sudo pm2 start [service_name]
npm service app:
pm2 start index.js