Delaying/Conditionally Starting Apps from .X.d

[SamK]

Is it possible at boot-up to delay starting or conditionally start apps from .X.d?

Currently I am looking for a way wait for a remote machine on the LAN to be seen from the local machine before starting apps in .X.d.

The set-up I am working with boots TC3 from a USB flash drive (sda1) which holds persistent home, opt and tce directories.  Also attached at boot-up is a USB hard disk (sdb) holding various ext and NTFS partitions.  The USB-HD does not form part of the active TC system, holds only data and is used on multiple machines and operating systems. An NTFS partition (sdb1) is mounted at boot-up from /opt/bootlocal.sh using ntfs-3g.

When booting without the USB-HD attached everything works as expected, i.e. the remote machine can be seen from the local machine and the apps from .X.d load successfully.

When booting with the USB-HD attached, the apps in .X.d load before TC has finished working with the USB-HD. This results in the network being unavailable at the time the .X.d apps load.  Subsequently, TC successfully finishes working with the USB-HD.

I have tried various combinations of backgrounding and sleep commands in /opt/booloacal.sh all without success.
 

[gerald_clark]

Have your .X.d script ( or bootlocal.sh ) loop until it successfully pings the remote machine.

[SamK]

Have your .X.d script ( or bootlocal.sh ) loop until it successfully pings the remote machine.

Thanks for this it seems blindingly obvious - once you have suggested it of course.

This works a treat in /opt/bootlocal.sh:

Code: [Select]

# Wait until a remote machine IP address can be contacted
while ! ping -c1 -W1 ipaddress ; do sleep 1 ; done
It sends a single ping (-c1) to the remote machine (ipaddress) and waits 1 second (-W1) for a reply then loops on a 1 second cycle (sleep 1) until it is successful.

This works fine if the remote machine is up and running and able to respond to the ping.  If the remote machine cannot respond, the local machine will wait indefinitely and not complete the boot-up.  Can anyone suggest a way to modify the loop with a simple counter into which I could put the number of times the ping should be tried before continuing the boot-up?
 

[jl]

Hi, Something like this should work:

Code: [Select]

ip=192.168.0.2          
attempts=10    
sleeptime=5    
counter=0      
                
while [ $counter -lt $attempts ] ; do
     ping -c1 -W1 $ip            
     if [ $? -eq 0 ]; then          
        echo Host is alive          
        break                        
     fi                              
     counter=$(( $counter + 1 ))    
     sleep $sleeptime                
done            


[SamK]

Hi, Something like this should work:

Hi and thanks for your suggestion.  It may be a short while until I can test it as it seems I was a little premature in reporting success when running the ping command from /opt/bootlocal.sh.

Code: [Select]

while ! ping -c1 -W1 ipaddress ; do sleep 1 ; done
As far as I can tell the issue seems not to be the ping command but issuing it from bootlocal. My initial hope was that doing this would pause the boot-up when the remote ipaddress could not be contacted.  The command is not backgrounded yet when the remote machine is powered down, bootlocal seems to proceed to the following command.

To test this all entries in bootlocal have been removed and a single entry made:

Code: [Select]

until [ -e /mnt/sda9 ] ; do sleep 1 ; done
sda9 does not exist on my test rig; the boot-up proceeds without a pause and continues to load the apps specified in .X.d.  It will be helpful if someone confirm that the commands are constructed correctly and that bootlocal is not the place to attempt to conditionally pause the boot-up and subsequent loading of apps in .X.d.

However, following the suggestion by gerald_clark and issuing the ping command from a file in .X.d does appear to have the desired outcome of not starting the app until the remote ipaddress can be contacted.
 

[maro]

Please be aware that '/opt/bootlocal.sh' gets called as a background process. So any delay created in that file will only apply to whatever is following in the same file. It won't delay the execution of other processes (e.g. auto-login as user 'tc' which in itself starts the X-server).

[SamK]

Please be aware that '/opt/bootlocal.sh' gets called as a background process. So any delay created in that file will only apply to whatever is following in the same file. It won't delay the execution of other processes (e.g. auto-login as user 'tc' which in itself starts the X-server).

Thanks for this it explains the behaviour I observed and also why I made an incorrect choice in trying to use /opt/bootlocal.sh.  Everything has now been transferred to .X.d and is working in the way I want..

Thanks to all who helped.