Below is a good example of misusing init.d scripts with the obvious results of the need for ugly workarounds. Why do you fight against the design of your system?
See specific comments below, On Wed, Aug 16, 2006 at 08:20:55AM -0400, Steven wrote: > rc.local: > > touch /var/lock/subsys/local > > setpci -v -s 00:1f.1 LATENCY_TIMER=4 > setpci -v -s 02:0e.0 LATENCY_TIMER=4 > setpci -v -s 0b:07.0 LATENCY_TIMER=4 > setpci -v -s 0c:08.0 LATENCY_TIMER=4 > setpci -v -s 10:0d.0 LATENCY_TIMER=0 > setpci -v -s 06:02.0 LATENCY_TIMER=ff > sleep 5 Why a sleep here? What exactly do you wait for? "sleep" is an indication of a bad workaround for a race condition. It is a bad workaround, as you can never know if you sleep enough. > > echo UnLoading wct4xxp > rmmod -v wct4xxp > rmmod -v zaptel > sleep 3 Huh? Why is that? BTW: 'genzaptelconf -u' will unload all zaptel modules. If 'modprobe -r' works on your system: that's even better. > > echo Loading wct4xxp > /sbin/modprobe -v zaptel > sleep 5 > /sbin/modprobe -v wct4xxp > sleep 5 > # ztcfg -vvvv > #sleep 5 The 'sleep'-s here are because of the following bugs: 1. running ztcfg automatically on modules load 2. not properly waiting for /dev/zap/ctl to be generated by udev > > echo 1 > /proc/irq/201/smp_affinity > echo 1 > /proc/irq/217/smp_affinity > echo 0 > /proc/irq/209/smp_affinity > echo 1 > /proc/irq/14/smp_affinity > > /usr/sbin/amportal start Now, that's an init.d script. Most of the code above should be merged into the zaptel init.d script (which is run before asterisk/amportal). Then the init system will run amportal later. If actually needed. -- Tzafrir Cohen sip:[EMAIL PROTECTED] icq#16849755 iax:[EMAIL PROTECTED] +972-50-7952406 jabber:[EMAIL PROTECTED] [EMAIL PROTECTED] http://www.xorcom.com _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
