So this seems to be a relatively common occurrence (lots of similar questions have been asked like here , here and here) with some variations. I have execute permissions for the script and have tried all the solutions mentioned in those questions but it's still not working. When I try to run the following command to start my Django server, the bash script opens and closes. How do I get it to persist after starting the server?
startserver.sh:
#!/bin/bash
python3 manage.py runserver 7888
So the command runs when I type it directly into cmd (in that directory), but when I try to run the bash file it just flashes and disappears. I have tried running it as
.\startserver.sh
. startserver.sh
sh startserver.sh
start startserver.sh
but each does the same. Ideally I would like to have it such that you can double click on the server.sh file and it runs persistently. Anyone have any ideas why this is the case? I feel like it's something very small I'm missing.
You need to add the nohup to your script.
Change
#!/bin/bash
python3 manage.py runserver 7888
to
#!/bin/bash
START=`pwd`
nohup python3 manage.py runserver 7888 >"${START}/startserver.LOG" 2>"${START}/startserver.ERR"
You don't want to rely on the longevity or continued existence of nohup.out because that default destination can be easily clobberred by other programs.
Related
I have a python script that get started automatically as a service (activated with systemd). In this python script, I call a bash script using subprocess.call(script_file,shell=True).
When I call the python script manually ($ python my_python_script.py), everything works perfectly. However, the automatically started program does not execute the bash script (however it does run, I checked this my making it edit a text file, which it indeed does).
I (think) I gave everyone read-write permissions to the bash scripts. Does anyone have ideas as to what I'm doing wrong?
Addendum: I want to write a small script that sends me my public IP address via telegram. The service file looks like this:
[Unit]
Description=IPsender
After=networking.service
[Service]
Type=simple
User=root
WorkingDirectory=/home/pi/projects/tg_bot
ExecStart=/home/pi/miniconda3/bin/python /home/pi/projects/tg_bot/ip_sender_tg.py
Restart=always
[Install]
WantedBy=multi-user.target
Protawn, welcome to the Unix and Linux StackExchange.
Why scripts work differently under system is a common question. Check out this answer to the general question elsewhere on the site.
Without the source code for your Python and Bash scripts it's hard to guess which difference you have encountered.
My personal guess is that your bash script is calling some other binaries without full paths, and those paths are found in your shell $PATH but not the default systemd path.
Add set -x to the top of your bash script so that all actions are logged to standard out, which will be captured in the systemd journal. Then after it fails, use journalctl -u your-service-name to view the logs for your service to see if you can find the last command that bash executed successfully. Also consider using set -e in the bash script to have it stop at the first error.
Despite the two "off-topic" "close" votes on this topic, why things work differently under systemd is on topic for this Stack Exchange site.
I have a VM that I want running indefinitely. The server is always running but I want the script to keep running after I log out. How would I go about doing so? Creating a cron job?
In general the following steps are sufficient to convince most Unix shells that the process you're launching should not depend on the continued existence of the shell:
run the command under nohup
run the command in the background
redirect all file descriptors that normally point to the terminal to other locations
So, if you want to run command-name, you should do it like so:
nohup command-name >/dev/null 2>/dev/null </dev/null &
This tells the process that will execute command-name to send all stdout and stderr to nowhere (instead of to your terminal) and also to read stdin from nowhere (instead of from your terminal). Of course if you actually have locations to write to/read from, you can certainly use those instead -- anything except the terminal is fine:
nohup command-name >outputFile 2>errorFile <inputFile &
See also the answer in Petur's comment, which discusses this issue a fair bit.
I have written a batch file like this:
Start putty.exe -ssh 172.17.0.52 -l root -m dummy.txt
Then in dummy.text I have written this command:
avahi-daemon --no-drop-root -D
export XVHMI_USERCONFIG_PATH=/home/UserProfileConfig
export XDG_RUNTIME_DIR=/tmp
cd /opt/bosch/airis/bin
When I run the .bat file, PuTTY starts, commands execute (hopefully, not sure) and it exits.
How to keep that window open?
I have googled for the same, but no solid help. I read on stack overflow itself that we need to define something in txt file, but what and most importantly how?
The SSH session closes (and PuTTY with it) as soon as the command finishes. Normally the "command" is shell. As you have overridden this default "command" and yet you want to run the shell nevertheless, you have to explicitly execute the shell yourself:
avahi-daemon ... ; /bin/bash
Also as use of -m switch implies a non-interactive terminal, you probably want to force an interactive terminal back using -t switch.
Though, I'm not really sure if you want to execute shell or if you just want to see your command output. If the latter, did you consider using plink? It's console terminal client from PuTTY package. Being console application, it inherits console of parent batch file, and you can pause the batch console from closing using pause command, if needed.
Another option (both for PuTTY and plink) is to pause on remote side. E.g. Using read command.
avahi-daemon ... ; read
As suggested by Martin I tried this step:
putty.exe -ssh 172.17.0.52 -l root -m dummy.txt -t
added /bin/bash at the end of commands in dummy.txt
It worked for me. Please note, you have to follow both the steps as mentioned above.
This way you can keep the session alive and can manually execute further commands.
I am on shared hosting and I'm trying to schedule cronjob to run every now and then. Via cPanel I scheduled to execute my script but even though that according to my host support the cronjob runs, the script doesn't seem as doing anything. The cron job command I set via cPanel is:
/bin/sh /home1/myusername/public_html/somefolder/cronjob2.sh
and the cronjob2.sh
#!/bin/bash
/home1/myusername/public_html/somefolder/node_modules/forever/bin/forever stop 0
when via SSH I execute:
/home1/myusername/public_html/somefolder/cronjob2.sh
it stops forever process as needed. From cronjob doesn't do anything.
How can I get this working?
EDIT:
So I've tried:
/bin/sh /home1/username/public_html/somefolder/cronjob2.sh >> /tmp/mylog 2>&1
and mylog entries say:
/usr/bin/env: node: No such file or directory
It seems that forever needs to run node and this cannot be found. How would I possibly fix this?
EDIT2:
Accepted answer at superuser.com. Thank you all for help
https://superuser.com/questions/763261/simple-script-run-via-cronjob-doesnt-work-but-works-from-shell/763288#763288
For cron job lines in a crontab it's not required to specify kind of shell or e.g. of perl.
It's enough, that your script contains
shebang
line.
Therefore you should remove /bin/sh from your cron job line.
Another aspect, that might cause a different behavior of your script by interactive start and by cron daemon start is possible different environment, first of all the PATH variable. Therefore check, if you script is able to be executed in very restricted environment, that is provided by cron daemon. You can determine your cron job environment experimentally by start of temporary cron job, that executes "env" command and writes its output to a file.
Once more aspect: Have you redirected STDOUT and STDERR of the cron job to a log file and read its content to analyze the issue? You can do it as follows:
your_cron_job >/tmp/any_name.log 2>&1
According to what you wrote, when you run your script via SSH, you are using bash, because this line is the first of your script:
#!/bin/bash
However, in the crontab, you are forcing the use of sh instead of bash. Are you sure your script is fully compatible with sh? Otherwise, simply replace /bin/sh with /bin/bash in your cron command and test again.
I am running Shopify Dashboard on Centos 6 (http://shopify.github.io/dashing/). I wish to start this on boot and via a cron when I pull down an update from git.
I have the following code in a bash script which is the same code I run via the command line to start dashboard.
#!/bin/bash
cd /usr/share/dashboard/
dashing start -p 500 -d
running the actual script as the root user from the command line starts the application no problem.
However when this script is run via a cron or on boot then the application is never started.
If anyone could shed some light as to why this is the case it would most appreciated.
Per my comment I am still not 100% sure that the script is being run as root. I would add a line in the script:
echo $user > /tmp/test.txt
Then run the script via cron and see what the value of the file is.
Also I question your script. Why is it necessary to cd?
How about
/usr/share/dashboard/dashing start -p 500 -d
Also you may have to do a nohup, which is the no hang up signal, so ...
nohup /usr/share/dashboard/dashing start -p 500 -d
Those are my guesses.