How to lock on Solaris 10?
ceving
exclusive lock.
What is the standard operating system command of Solaris 10 to do the
same in a shell?
http://unix.stackexchange.com/questions/12997/how-to-lock-on-solaris-10
Mr. Nice Guy
Solaris file locks are "advisory," meaning that they can be ignored by
other processes. If yours is the only program reading or writing a
file, you should be able to figure out how to "play nice." If you're
talking about a global file, such as /etc/hosts, then there's no
guarantee that your flock() will prevent anyone else from clobbering
your changes.
ceving
>
> >http://unix.stackexchange.com/questions/12997/how-to-lock-on-solaris-10
>
> Solaris file locks are "advisory," meaning that they can be ignored by
> other processes.
This is the same with Linux as long as one does not use the mand mount
option:
http://www.hackinglinuxexposed.com/articles/20030623.html
> If yours is the only program reading or writing a
> file, you should be able to figure out how to "play nice."
You want to say, that I have to touch files and see if they are there?
> If you're
> talking about a global file, such as /etc/hosts, then there's no
> guarantee that your flock() will prevent anyone else from clobbering
> your changes.
I think this is always right?
Mr. Nice Guy
> On 12 Mai, 00:20, "Mr. Nice Guy" <aa...@mcs-partners.com> wrote:
>
> > If yours is the only program reading or writing a
> > file, you should be able to figure out how to "play nice."
>
> You want to say, that I have to touch files and see if they are there?
Not necessarily. The flock() system call can help you, in this case,
if you're worried about two instances of your application accessing a
file simultaneously.
> > If you're talking about a global file, such as /etc/hosts, then there's no
> > guarantee that your flock() will prevent anyone else from clobbering
> > your changes.
>
> I think this is always right?
I vaguely remember in my research on this that flock(), or its
equivalent, on some OSs does a better job of actually preventing file
access than Solaris does. Don't quote me on it.
Wayne
UFS on Solaris does support manditory locks. You have to enable the
correct mount option, then use chmod to set the correct modes. If you
do it correctly, the system will enforce exclusive manditory locks.
See the mount man page options, "mand" or "nbmand" IIRC, and the
chmod man page.
Not sure about ZFS.
For shell scripts, you can use lock files, something like this:
set -C # or set -o noclobber
: > lock-file 2>/dev/null
if test $? = 0; then
got lock...
rm -f lock-file
fi
(You can change the if to a while loop, if you want blocking
behavior instead.)
--
Wayne
Richard B. Gilbert
OpenVMS, for example, supports mandatory locking. If you wish to use a
resource you request the resource from the O/S. If the resource is
available you are allowed to go ahead. If the the lock is already held
by another user, you must wait until he releases the lock.
The Unix model, OTOH, goes something like this: the key to the lavatory
is hung upon a hook. If you need to use the lavatory, you take the key
from the hook, use the lavatory, and return the key to the hook. If the
key is not on the hook, you must wait until the key is returned. The
lavatory door HAS NO LOCK!
Cydrome Leader
That's hillarious.
A security-type person I knew would frequently remind people that "unix
was made for sharing", which it was and lacks lots of the controls and
security of grandaddy type OSes on mainframes and the like. It's a pretty
good thing to always keep in mind.
ceving
>
> For shell scripts, you can use lock files, something like this:
>
> set -C # or set -o noclobber
> : > lock-file 2>/dev/null
> if test $? = 0; then
> got lock...
> rm -f lock-file
> fi
Nice trick with "noclobber"!
But the stderr redirection does not work:
$ set -o noclobber
$ : > lock 2>/dev/null
$ : > lock 2>/dev/null
bash: lock: cannot overwrite existing file
I think it must be the other way round:
2>/dev/null : > /lock
Thanks!
Geoff Clare
> Nice trick with "noclobber"!
>
> But the stderr redirection does not work:
>
> $ set -o noclobber
> $ : > lock 2>/dev/null
> $ : > lock 2>/dev/null
> bash: lock: cannot overwrite existing file
>
> I think it must be the other way round:
>
> 2>/dev/null : > /lock
Redirections are done left-to-right, so yes the stderr redirection
needs to be before the redirection that attempts to create the file.
However, it doesn't have to be before the command name. This
should work the same:
$ : 2>/dev/null > lock
--
Geoff Clare <net...@gclare.org.uk>