LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   Start Ices Automatically At Boot Up (https://www.linuxquestions.org/questions/linux-software-2/start-ices-automatically-at-boot-up-643567/)

n8tgc 05-20-2008 01:17 PM

Start Ices Automatically At Boot Up
 
I have an OpenSuse 10.3 machine running a few applications including OpenPVN, Icecast and Ices for an audio streamer. My intention is to have all necessary programs startup automatically at bootup. I have them all doing so, except one; Ices.

Here is my boot.local file (below). OpenVPN and Icecast start just fine at bootup. However, even with the 30 second wait, Ices still requires manual intervention to get started.

Am I missing something? Once booted, if I type out the last line manually Ices starts just as desired. Why would it not start if the same syntax is generated automatically at bootup?

I have the feeling that the answer is a simple one (as they usually are).

Any and all assistance is greatly appreciated! Thanks in advance!



****
service openvpn start
sleep 10s
/usr/local/bin/icecast -b -c /usr/local/etc/icecast.xml &
sleep 30s
/usr/local/bin/ices /usr/local/etc/Multiple.xml
****

unSpawn 05-21-2008 06:24 AM

If you configured IceS to use a logfile, does it log something when it doesn't want to start? BTW, by default services like those should have an initscript in /etc/init.d. That makes it easier to monitor (Monit?), start, restart and stop them.

n8tgc 05-21-2008 10:14 AM

Here is rundown of the Ices log. The machine was rebooted at 11:45 and the Ices service did not start from what appears to be the case of the hardware not responding. However manually starting the service at 11:51, everything started as desired.

While I see your point regarding the initscript location, I'm not sure that would address the problem I am experiancing. Or, would it?

Could this possibly be the result of the service attempting to start before the hardware drivers are up and running. Would simply a longer sleep duration (from 30s to 60s) be a potential cure?

****
[2008-05-20 11:45:14] INFO ices-core/main IceS 2.0.1 started...
[2008-05-20 11:45:14] EROR input-oss/oss_open_module Failed to open audio device /dev/dsp: No such file or directory
[2008-05-20 11:45:14] EROR input/input_loop Couldn't initialise input module "oss"
[2008-05-20 11:45:14] INFO ices-core/main Shutdown complete
[2008-05-20 11:51:10] INFO ices-core/main IceS 2.0.1 started...
[2008-05-20 11:51:10] INFO input-oss/oss_open_module Opened audio device /dev/dsp at 2 channel(s), 44100 Hz
[2008-05-20 11:51:10] INFO encode/encode_initialise Encoder initialising in VBR mode: 2 channels, 44100 Hz, nominal 96000
[2008-05-20 11:51:10] INFO audio/downmix_initialise Enabling stereo->mono downmixing
[2008-05-20 11:51:10] INFO audio/resample_initialise Initialised resampler for 1 channels, from 44100 Hz to 22050 Hz
[2008-05-20 11:51:10] INFO encode/encode_initialise Encoder initialising in VBR mode: 1 channels, 22050 Hz, nominal 32000
[2008-05-20 11:51:10] INFO signals/signal_usr1_handler Metadata update requested
[2008-05-20 11:51:10] INFO stream/ices_instance_stream Connected to server: 127.0.0.1:8000/wionhigh.ogg
[2008-05-20 11:51:10] INFO stream/ices_instance_stream Connected to server: 127.0.0.1:8000/wion.ogg

unSpawn 05-21-2008 05:52 PM

Yes and no ;-p Kinda weird as it seems some devices aren't up (yet?) that should have been initalised long time ago during the boot process (Udev mostly) since boot.local is the last initscript (equivalent to rc.local). You could test for input module "oss" and force loading it, but audio device "/dev/dsp" should be there, maybe test and hold starting IceS.


All times are GMT -5. The time now is 02:04 PM.