Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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!
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.
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
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.