I'm no expert but I see the pid and lock files serving two different
functions:
1) The pid file stores the process id of the currently running process. When
you deal with apps that can spawn new instances of themselves (like Apache),
then a pid file pertains to each spawned process (I think).
2) The lock file simply says either "the service is already started", or
"another process is using this file" (in terms of file locking). What the
scripts do with this information is up to them - for instance "The service is
already started, so do not start it again."
The locking has nothing to do with the pid files. However, it is sometimes
necessary for a process to determine it's own pid. I understand this to be
true when using process spawning as a way to do multithreading.
Don't know if that helps much, but here's hoping....
Shawn
On Tuesday 28 June 2005 10:19, Ian Wormsbecker wrote:
> 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
_______________________________________________
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
