| Author |
Single application instance using lockfiles
|
|
| John Smith 2005-02-15, 8:06 am |
| I heard that lockfiles is the prefered method to prevent two instances of
same application running at the same time.
Does anyone know some resource where I could read more about it?
I need to write some C code which can do this so 2nd instances will
terminate.
Is it also possible to avoid external users like root from deleting the
files to allow a 2nd instance?
Thanks in advance.
-- John
| |
| Måns Rullgård 2005-02-15, 8:06 am |
| "John Smith" <john.smith@x-formation.com> writes:
> I heard that lockfiles is the prefered method to prevent two instances of
> same application running at the same time.
>
> Does anyone know some resource where I could read more about it?
Using open() with the O_EXCL flag is one method.
> I need to write some C code which can do this so 2nd instances will
> terminate.
> Is it also possible to avoid external users like root from deleting the
> files to allow a 2nd instance?
root can do anything, there is, and should not be, anything to stop
that.
--
Måns Rullgård
mru@inprovide.com
| |
| Jens.Toerring@physik.fu-berlin.de 2005-02-15, 8:06 am |
| Måns Rullgård <mru@inprovide.com> wrote:
> "John Smith" <john.smith@x-formation.com> writes:
[vbcol=seagreen]
> Using open() with the O_EXCL flag is one method.
And writing the programs PID into it is quite reasonable. Using that
the next instance of the program can figure out if the lockfile is
still relevant or has become stale because the previous instance of
the program crashed without deleteing the lockfile.
Regards, Jens
--
\ Jens Thoms Toerring ___ Jens.Toerring@physik.fu-berlin.de
\__________________________ http://www.toerring.de
| |
| Måns Rullgård 2005-02-15, 8:06 am |
| Jens.Toerring@physik.fu-berlin.de writes:
> Måns Rullgård <mru@inprovide.com> wrote:
>
>
>
> And writing the programs PID into it is quite reasonable. Using that
> the next instance of the program can figure out if the lockfile is
> still relevant or has become stale because the previous instance of
> the program crashed without deleteing the lockfile.
Big fat warning: O_EXCL does not work over NFS, and PIDs are obviously
meaningless there too.
--
Måns Rullgård
mru@inprovide.com
| |
| Chuck Dillon 2005-02-15, 6:02 pm |
| Jens.Toerring@physik.fu-berlin.de wrote:
> Måns Rullgård <mru@inprovide.com> wrote:
>
>
>
>
>
>
>
> And writing the programs PID into it is quite reasonable. Using that
> the next instance of the program can figure out if the lockfile is
> still relevant or has become stale because the previous instance of
> the program crashed without deleteing the lockfile.
>
It should be pointed out that using a stored PID to guess whether or
not a process is still running is suspect on all systems if a
significant time has passed and suspect on some systems no matter how
much time has passed.
-- ced
--
Chuck Dillon
Senior Software Engineer
NimbleGen Systems Inc.
| |
| David Schwartz 2005-02-15, 6:02 pm |
|
"John Smith" <john.smith@x-formation.com> wrote in message
news:cusjau$dcp$1@news.net.uni-c.dk...
>I heard that lockfiles is the prefered method to prevent two instances of
> same application running at the same time.
>
> Does anyone know some resource where I could read more about it?
>
> I need to write some C code which can do this so 2nd instances will
> terminate.
> Is it also possible to avoid external users like root from deleting the
> files to allow a 2nd instance?
What's your outer problem? If two different users want to run your
application, why is it okay for them to run it on two different machines but
not okay for them to run it on the same machine? The answer to your question
will depend a lot on exactly what it is you're trying to avoid.
DS
| |
| John Smith 2005-02-15, 6:02 pm |
| > What's your outer problem? If two different users want to run your
> application, why is it okay for them to run it on two different machines
but
> not okay for them to run it on the same machine? The answer to your
question
> will depend a lot on exactly what it is you're trying to avoid.
>
I have a network daemon which hosts a database to clients. The database can
only be accessed by one daemon at a time. Thats why I want to lock out other
daemons so only one instance is running. Naturally you can easily hosts more
daemons+database on each their machine but not on one.
So the idea was to create a lockfile to e.g. /var/tmp. Maybe theres some api
which can give a specific temp path for the running system instead of
assuming that /var/tmp exist?
Since root will be able to delete files I assume I must have a mechanism to
detect if the lock is still valid. E.g. run a thread every now and then and
make sure we are still locked.
-- John
| |
| Eric Sosman 2005-02-15, 6:02 pm |
|
John Smith wrote:
>
> but
>
>
> question
>
>
>
> I have a network daemon which hosts a database to clients. The database can
> only be accessed by one daemon at a time.
Why? That is, does the database enforce this? If so, it
seems the database itself could be your exclusion mechanism:
second daemon instance attempts to connect, fails, says "Aha!
Somebody is already using the database," and exits.
What happens if process P1 connects to the database and
then P2 attempts to connect?
--
Eric.Sosman@sun.com
| |
| Mark Rafn 2005-02-15, 6:02 pm |
| >> What's your outer problem? If two different users want to run your
John Smith <john.smith@x-formation.com> wrote:[vbcol=seagreen]
>I have a network daemon which hosts a database to clients. The database can
>only be accessed by one daemon at a time.
You should perhaps look into locking on the database (assuming you mean a
database file, rather than an RDBMS connection), rather than a
system-wide restriction. Is it possible that two different underlying
databases might need to be accessed by two distinct daemons?
Alternately, if the daemon listens on a specific network port, you already get
locking because you'll fail to bind to it if another process already has
it. If you need to run two, you can, but they need to specify different
ports.
>daemons so only one instance is running. Naturally you can easily hosts more
>daemons+database on each their machine but not on one.
A lot of systems can hosts multiple instances of a database on one machine,
with different connection methods.
>Since root will be able to delete files I assume I must have a mechanism to
>detect if the lock is still valid. E.g. run a thread every now and then and
>make sure we are still locked.
Yes, if this is a problem, you'll want to exit if your lockfile is removed or
changed. If you define your uniqueness requirement to be network port or
specific database file, this won't be a problem, as root would have to kill
your process or destroy your database to nullify your lock.
--
Mark Rafn dagon@dagon.net <http://www.dagon.net/>
| |
| David Schwartz 2005-02-16, 2:48 am |
|
"John Smith" <john.smith@x-formation.com> wrote in message
news:4212480c$0$48638$edfadb0f@dread15.news.tele.dk...
[vbcol=seagreen]
> I have a network daemon which hosts a database to clients. The database
> can
> only be accessed by one daemon at a time. Thats why I want to lock out
> other
> daemons so only one instance is running. Naturally you can easily hosts
> more
> daemons+database on each their machine but not on one.
Since the database can only be accessed by one daemon at a time,
attempting to start a second will fail when it tries to access the database.
So you don't have a problem.
DS
| |
| Nils Weller 2005-02-16, 5:57 pm |
| In article <yw1x650u85j5.fsf@ford.inprovide.com>, Måns Rullgård wrote:
> "John Smith" <john.smith@x-formation.com> writes:
>
>
> Using open() with the O_EXCL flag is one method.
Using open() with O_EXCL alone is unreliable for obvious reasons (the
application or system may crash, thus leaving a stale lockfile.)
Personally, I tend to use open() + O_EXCL lockfiles in conjunction with
advisory record locking (fcntl() + F_SETLK): If the file exists and
cannot be locked, an instance is still running. If the file exists but
can be locked, the previous instance has already exited or crashed.
Using this method, you don't even have to worry about cleaning up the
file when you exit, since the advisory lock is the determining factor
anyway.
--
My real email address is ``nils<at>gnulinux<dot>nl''
| |
| Nils Weller 2005-02-16, 5:57 pm |
| In article <37hdr3F5cdo6pU2@individual.net>, Nils Weller wrote:
> Personally, I tend to use open() + O_EXCL lockfiles in conjunction
^^^^^^^^
> with advisory record locking (fcntl() + F_SETLK): If the file exists
> and
Whoops, strike this!
--
My real email address is ``nils<at>gnulinux<dot>nl''
| |
| Bjorn Reese 2005-02-16, 5:57 pm |
| John Smith wrote:
> I have a network daemon which hosts a database to clients. The database can
> only be accessed by one daemon at a time. Thats why I want to lock out other
> daemons so only one instance is running. Naturally you can easily hosts more
> daemons+database on each their machine but not on one.
You may consider using a socket as the "lock file". It is automatically
removed (assuming you set the SO_REUSEADDR socket option) by the OS.
--
mail1dotstofanetdotdk
|
|
|
|