Reputation: 5
I am currently writing a script that is writing scripts and then executing them.
The user that is running the parent script is the root user.
Here is the code:
1 for i in $(seq 1 $num)
2 do
3
4
5 scriptL1="#!/bin/bash"
6 scriptL2="i=$i"
7 echo $scriptL1 > /tmp/pulse$i.sh
8 echo $scriptL2 >> /tmp/pulse$i.sh
9
10 #this loop writes line-by-line from a file to the child script file
11 for j in $(seq 1 $(cat $HOME/mainscript.txt | wc -l))
12 do
13 line=$(head -n $j $HOME/mainscript.txt | tail -n 1)
14 echo $line >> /tmp/pulse$i.sh
15 done
16
17 chmod +x /tmp/pulse$i.sh
18
19 setsid /tmp/pulse$i.sh &
20 done
What it is essentially doing is for $num number of items in a directory, it makes $num number of scripts in /tmp. Each script made in /tmp from this script works as expected. In fact, this overall script works. However, when I run this parent script from the terminal, it fails to start any /tmp/pulseVM$i.sh executables.
In short, this script fails to execute line 19 as expected and I have no idea why.
I am expecting that this parent script will fork these child scripts to the background. That way, this parent script can end while the child scripts continue. Currently, child scripts aren't being executed.
Here is a sample mainscript.txt:
WORK="#Write a directory path here"
#This directory is owned by root and must be owned by the root. It is also shared with a virtual machine that is using root.
rm $WORK/VMInputShared/VM$i/pong/pulse
touch $WORK/VMInputShared/VM$i/ready
sleep 10
fails=0
while true
do
if [[ $(ls $WORK/VMInputShared/VM$i/pong) == "pulse" ]]
then
touch $WORK/VMReadyKeys/VM$i
fails=0
mv $WORK/VMInputShared/VM$i/pong/pulse $WORK/VMInputShared/VM$i/ping/pulse
else
((fails++))
if [ $fails -le 9 ]
then
echo "Failure $fails/10..."
else
echo "Failure $fails/10..."
rm $WORK/VMReadyKeys/VM$i
fi
fi
sleep 3.2
done
It is important to note that .../VM$i is a shared folder with a virtual machine running on this system. The virtual machine is running under root and due to the purposes of the virtual machine, it needs root privileges at all times.
Upvotes: 0
Views: 521
Reputation: 5
I am very confident that I have found out why it was not working. This parent script was made for the root user, but as I was testing under an account that did not have root privileges by default, I tried using sudo as a way to test this script with superuser privileges, but that did not work. It only started working once I became root by logging into su.
I believe this stems from the contents of the child script "/tmp/pulse$i.sh". This script uses commands that require superuser privileges. I believe that when I used sudo on the parent script, when the child script was setsid'd to the background, it did not retain these superuser privileges from sudo that the parent had. I believe that this is what made setsid appear to fail, when in reality it was running the script but immediately failing due to needing permission from the superuser.
This was confusing as when I was testing the parent script, I would get no prompts from the terminal telling me anything was wrong.
In the end, if the child script needs superuser privileges, then running the parent script while logged in as the superuser through su fixes this issue. If it will be run as the superuser, try running it as the superuser (not sudo).
Upvotes: 0