[mythtv] [Feature request] Startup delay

[Ben de Luca]

> Well, if I was using an off-the-shelf distro, that would be the proper 
> way
> to do things.
>
> (And yes, I know how to use many flavors of scripts which
> work just fine for a desktop machine. However MOST of the scripts do 
> not
> provide for automatic restarting of a service and the ones that do are 
> a
> bit too complex and they tend to be a bit unreliable; they also don't 
> tend
> to work well with busybox, you need a full copy of bash available.)
>

my shell is simply a simlink to bash, but I am sure this will work 
under ash at least. I dont remember if sh supports whiles. But given 
the size of myth your not fitting this on a floppy, no reason to not 
have a feature filled environment.

#!/bin/ash
while  [ -f /etc/inittab ]
do
echo usr/local/bin/mythfrontend -v all  2>&1 /tmp/mythlog
sleep 10
done

you can even not use inittab but some other file /etc/autostartmyth to 
turn its automatic starting on and off.



> In my application I have a very minimal system (busybox, dietlibc, a 7
> line startup script) that is built for reliablilty (even the kernel is
> tweaked to reboot if init dies). So it comes down to two options:
> 1. Write a new init that is specific for the job.
> 2. Add a startup delay to mythbackend.

I have never seen init die! never! ever in years of systems 
administration.


> At the moment I am considering writing a specific init to eliminate the
> startup script that I currently have as all the startup script does 
> call a
> few things in busybox that mount a few things and play with a few 
> values
> in the /proc directory. (It would be nice to add these values into
> inittab.) However, adding a startup delay to init to handle one issue 
> is
> less attractive than adding a delay to the application in question..
Why thats the whole point of startup scripts? Any how submit a patch if 
you feel its a must have feature but I am 100% sure it will be 
rejected.

Scripts are there to tie your system together. Just because you dont 
seem to like them, it doesnt mean they are not the best tool for the 
job.

bd




> -Neil Whelchel-