[Home]

Summary:ASTERISK-07427: [patch] Debian does not have /var/lock/subsys
Reporter:Marc Casillo (mcasillo)Labels:
Date Opened:2006-07-31 04:13:10Date Closed:2006-08-15 20:41:03
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) etcinitd-zaptel-diff.txt
Description:A clean install of Debian does not have a /var/lock/subsys directory as it is a non-debianism, thus causing the /etc/init.d/zaptel script to fail.

The offending line is :
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/zaptel

I think if you change the above line as follows, it will accomplish what is needed in the same fashion that the script uses earlier to determine its environment. I've attached a diff -u for this

if [ $system = debian ]; then
   [ $RETVAL -eq 0 ] && touch /var/lock/zaptel
elif [ $system = redhat ]; then
   [ $RETVAL -eq 0 ] && touch /var/lock/subsys/zaptel
fi
Comments:By: Russell Bryant (russell) 2006-08-05 01:20:26

Would you mind filling out one of the license agreements that are linked near the bottom of the main page of bugs.digium.com?  It is best if we have one on file for all contributions.

Thanks!
By: Tzafrir Cohen (tzafrir) 2006-08-12 11:02:38

IMHO the actions of the current init.d script are wrong.

There is no point in automatically rmmod-ing modules on shut-down. Apart from wasting time.

In the current init.d script in the Debian package there is a separate "unload" action to remove the modules. The "stop" action does nothing.

As the "stop" action does nothing, there is no point is usiing a lock file or saving a state.

For the unload opration we use the following function (disclaimed):

# recursively unload a module and its dependencies, if possible.
# where's modprobe -r when you need it?
# inputs: module to unload.
unload_module() {
       set +e
       module="$1"
       line=`lsmod 2>/dev/null | grep "^$module "`
       if [ "$line" = '' ]; then return; fi # module was not loaded

       set -- $line
       # $1: the original module, $2: size, $3: refcount, $4: deps list
       mods=`echo $4 | tr , ' '`
       for mod in $mods; do
               # run in a subshell, so it won't step over our vars:
               (unload_module $mod)
       done
       rmmod $module || true
       set -e
}



Try: unload_module zaptel

This removes the need to maintain a list of modules to remove.
By: Russell Bryant (russell) 2006-08-13 21:02:07

Perhaps we should just have a debian specific init script just like we have separate init scripts for Asterisk
By: Tzafrir Cohen (tzafrir) 2006-08-14 07:41:15

First off, I believe that there is to need to save state: the 'unload_module' procedure above will work just the same.

Another note: both Debian and gentoo have simple files that are list of modules to load on system startup. Those modules are loaded very early on system startup and specifically before any automatic hardware module load takes place and before networking is loaded.

For the case of Debian, we aim for users to load modules through that file (/etc/modules) rather than the zaptel init.d script. The zaptel init.d script just loads ztdummy if no other module was loaded. IMHO loading the modules from that file is a saner approach, because:

1. Zaptel may be needed to load networking, in some extreme cases

2. Zaptel modules will be loaded before any hotpluged modules, if needed. Else the modules may be loaded by hotplug.

Is there any similar loading method for RedHats? for SuSE? For any other distribution?
By: Tilghman Lesher (tilghman) 2006-08-15 20:41:03

Slightly different fix.  Committed to 1.2 and merged to trunk.

Thanks for the bug report.