Alot of those are to ensure that a given program is not started again if
it has already started. For example, I chose a random file:
/etc/init.d/isdn on my machine
Here is a snippet of the start function:
function start()
{
isapnp activate
# don't start again if it's already started
[ ! -f /var/lock/subsys/isdn ] || exit 0
# load modules
load_modules
...
}
The load_modules is a function like this:
function load_modules()
{
if [ -f /lib/modules/$(uname -r)/kernel/drivers/isdn/isdn_lzscomp.o
] ; then modprobe isdn_lzscomp comp=$COMPRESSION debug=0 >
/dev/null 2>&1
fi
[ "$PCMCIA" = "no" ] || return
modprobe $MODULE $RESOURCES > /dev/null 2>&1
isdnctrl list all >/dev/null 2>&1
if [ $? = 0 ] ; then
action $"Loading ISDN modules" /bin/true
touch /var/lock/subsys/isdn
...
As you can see, this module creates the /var/lock/subsys/isdn file when
it loads the modules. Therefore, if isdn has already been started, the
start() function has a way to tell that it is running already, and will
not start.
Likewise, the stop() function makes a call to remove_modules()
function stop()
{
stop_isdnlog
remove_modules
isapnp deactivate
}
remove_modules will then 'cleanup' the lock file so that if we are to
start isdn again, the start() function will note that the file does not
exist, and continue with the startup. Here is the relevant cleanup bits
from remove_modules():
function remove_modules()
{
modprobe -r isdn_lzscomp >/dev/null 2>&1
# Unload hisax modules
[ "$PCMCIA" = "no" ] || return
if lsmod | grep "^$MODULE" >/dev/null 2>&1 ; then
action $"Unloading ISDN modules" modprobe -r $MODULE
rm -f /var/lock/subsys/isdn
fi
}
Note the 'rm -f /var/lock/subsys/isdn' command which removes the lock file.
The lock files (in the case of isdn at least) are there to ensure that
only one copy of the isdn related services are running at a time. If a
user tries to start more than one copy of the isdn services, they will
get a warning that it is already running, and the services will not be
run again.
Does this help to answer your question?
Ian.
Stephen Cartwright wrote:
Normally, I would agree with you completely... However the particular
lock files I am talking about are in /var/lock/subsys (on Red Hat and
Red Hat based distros). The reason I became curious about this is I
had to create an init script and while looking at other init scripts I
realized that many (all the ones I looked at) would "touch" to create
a file in this directory under their start function and then remove it
when the stop function is run. In this case the lock seems to be based
on the process, not a data file. I can't think of any good reason for
this so it is bothering me... Please help!
Thank you!
On 6/28/05, Neil Bower <[EMAIL PROTECTED]> wrote:
On Tue June 28 2005 09:24, Stephen Cartwright wrote:
So why the need for both files though... The file dosen't have to be
empty to be used as a lock... Why not just create a pid file and check
that instead of having one file to just hold the pid and another file
just to lock -- I'm just trying to determine if there is a specific
reason or it just has developed that way. Also just to be clear -- the
application is responsable for creating the pid file right?
Just a guess here, but I do believe the pid file is associated with the
process or executible, whereas the lock file is associated with the data
file.
You may have one pid file associated with a running process, but this process
may be accessing or modifying several different data files that you would
want to lock off from other processes to prevent corruption. The pid file
will not change for the duration the process is running, but the data files
may be locked at different times.
Hope this helps,
Neil
--
Neil Bower
CLUG - http://clug.ca
Registered Linux User # 323470
( http://counter.li.org )
_______________________________________________
clug-talk mailing list
[email protected]
http://clug.ca/mailman/listinfo/clug-talk_clug.ca
Mailing List Guidelines (http://clug.ca/ml_guidelines.php)
**Please remove these lines when replying
_______________________________________________
clug-talk mailing list
[email protected]
http://clug.ca/mailman/listinfo/clug-talk_clug.ca
Mailing List Guidelines (http://clug.ca/ml_guidelines.php)
**Please remove these lines when replying
_______________________________________________
clug-talk mailing list
[email protected]
http://clug.ca/mailman/listinfo/clug-talk_clug.ca
Mailing List Guidelines (http://clug.ca/ml_guidelines.php)
**Please remove these lines when replying
