I want to to run my program as soon as raspberry pi boot-up or restart. I've tried $contab -e and added program but in log it showed it started but no output nothin. I've to run it manually everyday using $nohup ./Code &
even tried adding the run command in /etc/rc.local with full path.
How can I run the program then. It's working very well and gives output at normal run.
Related
I'm running Windows 10 x64 with WSL2 (Ubuntu 20.04 on WSL2).
In WSL2, I have cron running the following task:
* * * * * /mnt/c/Users/Colin/Desktop/test.sh
The contents of test.sh (currently executing every minute for test purposes) are as follows:
#!/bin/bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32
taskkill.exe /im calibre.exe
sleep 5
<rsync command here>
echo "Done with rsync, launching calibre..."
screen -dm bash -c \"/mnt/c/Users/Colin/Desktop/startcalibre.sh\"
This script works perfectly when executed from the WSL2 prompt.
However, cron will not run either the taskkill.exe command nor the screen command (which launches calibre) in the script. I do see that cron executes the script because I see that rsync runs since I can see that in Wireshark. It seems that cron on WSL2 has problems with running Windows executables (taskkill.exe, etc) in particular (I can't even seem to get notepad.exe to launch via a cron-executed script).
What should I add to the script to get cron to execute Windows executables?
Not necessarily an answer, but I'm hoping this will lead us to one ...
First, let's try a script that pretty much anyone with WSL can run to see if we can reproduce the problem in more of an MRE:
#!/usr/bin/env bash
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32
echo $PATH > ~/cronlogger
notepad.exe &
sleep 2
which taskkill.exe >> ~/cronlogger
taskkill.exe /im notepad.exe >> ~/cronlogger 2>&1
I placed this script in my %userprofile%/Desktop/test.sh as well and set it to run with the same crontab line (via sudo crontab -u ntd -e):
* * * * * /mnt/c/Users/ntd/Desktop/test.sh
It works for me as expected -- Every minute, Notepad pops up and then after 2 seconds is killed. The contents of ~/cronlogger are:
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/usr/lib/wsl/lib:/mnt/c/Windows/system32:/mnt/c/Windows:/mnt/c/Windows/System32
/mnt/c/Windows/system32/taskkill.exe
SUCCESS: Sent termination signal to the process "Notepad.exe" with PID 4268.
Of course, wait until a few seconds after the top of the minute to make sure you capture the whole thing.
I notice that you have the ..\System32 path twice, but that shouldn't matter. Also, case-sensitivity isn't an issue unless you have specifically turned it on for Windows drives via /etc/wsl.conf.
I tested this:
On Windows 10 21H2
On Windows 11 using the latest Preview version of WSL
As my normal user sudo crontab -u ntd -e
As the root user sudo crontab -e
All worked okay for me.
At this point, the only thing I can think that might throw it off is if you were using a Systemd script of some sort. I've seen Systemd throw off the WSL binfmt_misc registration so that WSL can no longer run Windows executables. I could imagine this could happen inside the Cron daemon (but still be working via the default shell).
I have an issue about how to run screen through crontab, I made a script which check if a previous session is running and if not restart a screen.
cf screenshots below
crontab
restard_td.sh
When I run the script manually it's works fine, by cron, i can see my output "down, i will restart it " in my log file but no screen available and my script doesn't run.
Has someone got an idea ?
you can try checking the cron log, and use the screen full path.
I fixed it by using screen full path and python full path in my script.
like that
/usr/bin/screen -dmS team /usr/local/bin/python /home/admin/scripts/rattrapage/team.py
Since recently, I work on raspberry so I'm a noob. I wrote a shell script that runs my program to blink a LED by gpio in the boot.
Now when the raspbian boots show some log then my led start blinking and everything got stuck in this situation and I can't run the cmd.
Here is my script:
#!/bin/bash
cd /root/Desktop
./blink
My setup is:
#update-rc.d mystartup.sh defaults 100
What should I do now? I can't boot it and start GUI.
Have you tried
#!/bin/bash
cd /root/Desktop
./blink &
to run blink in the background?
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.
I have the current scenario to deal with:
I have to schedule the backup of my company's Linux-based server (under Suse Linux) with ARCServe R15 (installed on Windows 2003R2SP2).
I know I have the ability in my backup software (ARCServe) to add pre/post execution scripts to my backup-jobs.
If failure of the script, ARCServe would be specified NOT to run the backup-job, and if success, specified to be run. I have no problem with this.
The problem is, I want to make a windows script (to be launched by ARCServe) for executing a Linux script on the cluster:
- If this Linux-script fails, I want my windows-script to fail, so my backup job in ARCServe wouldn't run
- If the Linux-script success, I want my windows-script to end normally with error code 0, so my ARCServe job would run normally.
I've tried creating this batch file (let's call it HPC.bat):
echo ON
start /wait "C:\Program Files\PUTTY\plink.exe" -v -l root -i "C:\IST\admin\scripts\HPC\pri.ppk" [cluster_name] /appli/admin/backup_admin
exit %errorlevel%
If I manually launch this .bat by double-clicking on it, or launching it in a command prompt under Windows, it executes normally and then ends.
If I make it being launched by ARCServe, the script seems never to end.
My job stays in "waiting" status, it seems the execution code of the linux script isn't returned to my batch file, and this one doesn't close.
In my mind, what's happening is plink just opens the connection to the Linux, send the sript execution signal, and then close the connection, so the execution code can't be returned to the batch. Am I right ?
Is what I want to do possible or am I trying something impossible to do ?
So, do I have to proceed differently ?
Do I have to use PUTTY or CygWin instead of plink ?
Please, it's giving me headaches ...
If you install Cygwin, you could do it exactly like you can do it on Linux to Linux, i.e. remotely run a command with ssh someuser#remoteserver.com somecommand
This command will return with the same return code on the calling client, as the command exited with on the remote end. If you use SSH shared keys for authentication instead of passwords, it can also be scripted without user interaction.