|
Home > Archive > Unix Programming > November 2004 > Use of lock directories
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Use of lock directories
|
|
| Keith Doyle 2004-11-16, 5:49 pm |
| I'm trying to write some relatively portable (unices) code that needs to create a
resource lock for itself-- LCK..fubar, etc. I'd just as soon NOT put it in
/tmp or /var/tmp, etc., and seeing as how there exists /var/locks (AIX) and
/var/spool/locks (SCO and others) I figure this is where such a thing should go.
However, I note on SCO that the permissions of the directory make it only
writable by bin-- and I'd also just as soon NOT change permissions on the
directory from its default to make it work.
Is there a "recommended" means of creating LCK.. files for independent
apps to use? Should I use /tmp on SCO because I know it at least to be writable?
What use is /var/spool/locks on SCO if it's only writable by bin? Is there
a system call that will do this that I've just been unable to find?
--
Keith
| |
| Fletcher Glenn 2004-11-16, 5:49 pm |
|
Keith Doyle wrote:
> I'm trying to write some relatively portable (unices) code that needs to create a
> resource lock for itself-- LCK..fubar, etc. I'd just as soon NOT put it in
> /tmp or /var/tmp, etc., and seeing as how there exists /var/locks (AIX) and
> /var/spool/locks (SCO and others) I figure this is where such a thing should go.
> However, I note on SCO that the permissions of the directory make it only
> writable by bin-- and I'd also just as soon NOT change permissions on the
> directory from its default to make it work.
>
> Is there a "recommended" means of creating LCK.. files for independent
> apps to use? Should I use /tmp on SCO because I know it at least to be writable?
> What use is /var/spool/locks on SCO if it's only writable by bin? Is there
> a system call that will do this that I've just been unable to find?
>
>
>
> --
>
> Keith
Can't you use the lockf() functionality?
--
Fletcher Glenn
| |
| Keith Doyle 2004-11-18, 5:52 pm |
| Fletcher Glenn <fletcher@removethisfoglight.com> wrote in message news:<419A8D80.9050206@removethisfoglight.com>...
> Keith Doyle wrote:
[vbcol=seagreen]
> Can't you use the lockf() functionality?
Well, I'm trying to create a lock file, not a file lock. Even if I
did decide to use lockf to lock a file for access controls, I'd still
need a file to lock-- and that's the problem...
Here's a little more detail on the scenario as explanation:
1. Application program "mydemon" is run. It runs in background until
further notice. When it runs, it creates an LCK..mydemon file that
contains its PID.
2. If mydemon is run again, it checks via the logfile to see if it's
already running, and if so, exits.
3. Another process want's to send a signal, or terminate, or (etc.)
mydemon. It gets the PID out of the logfile and uses it to deal with
the daemon.
In this case, the reason I'm not putting these files in the
application tree is that we support multiple applications, all of
which need to use this facility and none of which are guaranteed to be
installed on any given system. Also, some of these apps were
"aquired" and are now being combined and further enhanced with some
common features-- some mixture of pre-aquisition and post-aquisition
packages may exist on a system, so the idea of having a
/current_company_name_common_files directory won't mean very much...
But it could be that I'm making an erroneous assumption here-- that
because some Unix apps (kermit?) have been known to create LCK..tty###
files for controlling access to /dev/tty### devices, it is therefore
reasonable for our apps to create similar files in that same directory
to control access to certain app resources in a similar fashion.
Obviously, such files could go most anywhere and work. The use of
LCK.. files by some apps may be just a convention that has been
imitated here and there adding to the confusion-- what I'm ultimately
trying to find out here is *what is the intended purpose of the
/var/spool/locks and/or /var/locks directories?* Is it just
up-for-grabs for locking purposes or is it off-limits to anything but
certain standard unix utilities, or something inbetween? Is there a
semi-standardized unix locks directory where it would be a "good idea"
to put locking files or should we all create and use /usr/local/locks
or /proc/locks if we are looking for a "public" area to put lock
files? Or should we always just keep putting more and more crap in
/tmp?
--
Keith Doyle
|
|
|
|
|