Why won't my script run?

["Terrell Prudé Jr."]

_______________________________
Do you GNU <http://www.gnu.org>?
Microsoft Free since 2003 <http://www.cmosnetworks.com>--the ultimate 
antivirus protection!


Nigel Ridley wrote:
> <div class="moz-text-flowed" style="font-family: -moz-fixed">Howard 
> Coles Jr. wrote:
>> On Saturday 14 March 2009 12:07:21 pm Mark Greenwood wrote:
>>> Another question for the boffins..
>>>
>>> My Acer Aspire One needs a special script to control the fan. This 
>>> script
>>> is called /usr/local/bin/acerfand and, when I run it from the 
>>> command line
>>> it does indeed control the fan. acerfand is a bash script which 
>>> daemonises
>>> itself using magic I do not understand.
>>>
>>> To get it to start at boot I'm instructed to place the command line 
>>> into
>>> /etc/rc.local, so ignoring comments my /etc/rc.local now looks like
>>>
>>> #!/bin/sh -e
>>> /usr/local/bin/acerfand
>>> exit 0
>>>
>>> If I run 'sudo /etc/rc.local' from the command line my fan script 
>>> starts
>>> running, the fan is being controlled and I can see acerfand as a 
>>> running
>>> process.
>>>
>>> On boot however, the script starts and then immediately exits (I put 
>>> debug
>>> in, I can see it in syslog starting up and then exiting). There is no
>>> running process called acerfand after boot. Again, I type 'sudo
>>> /etc/rc.local' at a command line and now there is a running acerfand
>>> process.
>>>
>>> Why the different behaviour at boot, and how can I make it work?
>>>
>>> It worked on Mandriva.... ;)
>>>
>>> Thanks,
>>>
>>> Mark
>>
>> It would be easier to copy your fan control script into the 
>> /etc/init.d directory and then add it to the /etc/rc#.d/ as a 
>> softlink with either "S##acerfan" or "K##acerfan"  (s is for start 
>> and the number is the order in which you want it to start, K is for 
>> kill or stop, and again the number indicates when you want it to stop 
>> relative to the other K's in the directory.).
>>
>> create a "acerfan" file (using /bin/bash instead of sh as its default 
>> on most Debian based distros) in /etc/init.d with the contents of 
>> what you put in rc.local (leaving off the "exit 0" line).
>> then softlink the script in rc2.d (default runlevel in Debian based 
>> distros) as follows:
>> ln -s /etc/init.d/acerfan /etc/rc2.d/S99acerfan
>> ln -s /etc/init.d/acerfan /etc/rc6.d/K03acerfan
>> that last line is optional.
>> Then see what happens.
>>
>>
>
> The correct Debian way (and I suppose it [still] applies to *ubuntu) is:
>
> [quote]
> Suppose a system needs to execute script foo on start-up, or on entry 
> to a particular (System V) runlevel. Then the system administrator 
> should:
>
>     * Enter the script foo into the directory /etc/init.d/.
>
>     * Run the Debian command update-rc.d with appropriate arguments, 
> to specify which runlevels should start the service, and which 
> runlevels should stop the service.
>
>     * Consider rebooting the system to check that the service starts 
> correctly (assuming that you've asked for it to be started in the 
> default runlevel). Otherwise, manually start it by running 
> `/etc/init.d/foo start'.
>
> One might, for example, cause the script foo to execute at boot-up, by 
> putting it in /etc/init.d/ and running update-rc.d foo defaults 19. 
> The argument `defaults' refers to the default runlevels, which means 
> (at least in absence of any LSB comment block to the contrary) to 
> start the service in runlevels 2 through 5, and to stop the service in 
> runlevels 0, 1 and 6. (Any LSB Default-Start and Default-Stop 
> directives in foo take precedence when using the sysv-rc version of 
> update-rc.d, but are ignored by the current (v0.8.10) file-rc version 
> of update-rc.d.) The argument `19' ensures that foo is called after 
> all scripts whose number is less than 19 have completed, and before 
> all scripts whose number is 20 or greater.
> [end quote]
> (Taken from: http://www.debian.org/doc/FAQ/ch-customizing.en.html (11.6)
>
> Blessings,
>
> Nigel

The odd part is that the script certainly is executing, and apparently 
so is acerfand.  But acerfand is apparently exiting immediately 
thereafter.  Given that /etc/rc.local executes in root's context, this 
is *very* weird behaviour indeed.

Unless there's something horribly broken in Ubuntu, then it shouldn't 
matter one damned bit how you start the daemon, be it in /etc/rc.local 
or in a SysV init script.  I put stuff in /etc/rc.local all the time on 
many distros, including Debian and Ubuntu Dapper/Hardy.

Let's try a couple of things, just to make _absolutely_ sure 
/usr/local/bin/acerfand is starting.  Tweak /etc/rc.local to look like this:

#!/bin/sh -e
echo "Starting acerfand..."  # new line
/usr/local/bin/acerfand
echo "Done."    # new line
sleep 1
exit 0

If that doesn't work, then try also adding " &" after "acerfand".  This 
will start the process in the background.  Yes, I know, it automatically 
daemonizes, but just give it a shot anyway and see if it stays alive.  
It can't hurt to try.

--TP
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kubuntu-users/attachments/20090315/2d45b8d0/attachment.html>