Programming in C I have tried to figure out what (Linux !?) API I
should use to detect how many instances of my program are running. I
have read about the pidfile method and also I had a quick look at
semaphores but somehow I simply could not get it to work.
What I'm trying to do is something like this:
int main(void){int n; n=howmanyofme();if(n>3) printf("Over 3 instances
\n");return 0;}
So if anyone can point me to something useful I would appreciate it.
(yes I Googled and even re-Googled the question).
PS! I'm no newsgroup guru so sorry for any mistakes I might be doing.
Thanks in advance.

[ Post a follow-up to this message ]

Waxhead wrote:
> programming in C I have tried to figure out what (Linux !?) API I
> should use to detect how many instances of my program are running.

There is no standard API to do that. There are, however, a number of
programming techniques (that do not depend on a specific "how many instances
"
API) that you can use to determine "how many instances".

> I
> have read about the pidfile method and also I had a quick look at
> semaphores but somehow I simply could not get it to work.
> What I'm trying to do is something like this:
> int main(void){int n; n=howmanyofme();if(n>3) printf("Over 3 instance
s
> \n");return 0;}
> So if anyone can point me to something useful I would appreciate it.
> (yes I Googled and even re-Googled the question).

You could
a) popen("ps aux | grep my_binary_name", "r") and count the number of lines
returned

2) have each process manage a separate PID file (myprocess.<pid> ), creating 
it
when started, and deleting it when ending, then count the number of pid file
s

3) have each process update a single specific counter file (myprocess.counte
r)
with lock, and increment the count in the file when starting. Update the fil
e
and decrement the count when terminating, and check the value when determini
ng
the # of processes (a crude, file-based semaphore)

4) variations on any of the above, including using special "counting" server
s
to manage the semaphore count, or registering and unregistering processes as
they run

> PS! I'm no newsgroup guru so sorry for any mistakes I might be doing.
> Thanks in advance.
>

No problem. We all have to start somewhere. Welcome to the group.

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/   | GPG public key available by request
----------      Slackware - Because I know what I'm doing.          ------

[ Post a follow-up to this message ]

On Sep 9, 6:52 pm, Lew Pitcher <lpitc...@teksavvy.com> wrote:
> Waxhead wrote: 
>
> There is no standard API to do that. There are, however, a number of
> programming techniques (that do not depend on a specific "how many instanc
es"
> API) that you can use to determine "how many instances".
> 
>
> You could
> a) popen("ps aux | grep my_binary_name", "r") and count the number of line
s
> returned
>
> 2) have each process manage a separate PID file (myprocess.<pid> ), creatin
g it
> when started, and deleting it when ending, then count the number of pid fi
les
>
> 3) have each process update a single specific counter file (myprocess.coun
ter)
> with lock, and increment the count in the file when starting. Update the f
ile
> and decrement the count when terminating, and check the value when determi
ning
> the # of processes (a crude, file-based semaphore)
>
> 4) variations on any of the above, including using special "counting" serv
ers
> to manage the semaphore count, or registering and unregistering processes 
as
> they run
> 
>
> No problem. We all have to start somewhere. Welcome to the group.
>
> --
> Lew Pitcher
>
> Master Codewright & JOAT-in-training | Registered Linux User #112576http:/
/pitcher.digitalfreehold.ca/  | GPG public key available by request
> ----------      Slackware - Because I know what I'm doing.          ------

Thanks for your suggestions. I have already implemented something
close to your suggestion a/1. However I can't help thinking that there
must be a way of traversing the processlist myself. In windows I can
always use the CreateToolhelp32Snapshot() function and it's friends ;)
I guess there is some similar mechanism for Unix/Linux as well but I
have been unable to dig up any information about it.

[ Post a follow-up to this message ]

dirtcellar@gmail.com writes:

> On Sep 9, 6:52 pm, Lew Pitcher <lpitc...@teksavvy.com> wrote: 
<suggestions snipped>[vbcol=seagreen] 

A usenet tip: don't quote people's sigs: the parts after (and
including) the "-- ".
[vbcol=seagreen]
> Thanks for your suggestions. I have already implemented something
> close to your suggestion a/1. However I can't help thinking that there
> must be a way of traversing the processlist myself. In windows I can
> always use the CreateToolhelp32Snapshot() function and it's friends ;)
> I guess there is some similar mechanism for Unix/Linux as well but I
> have been unable to dig up any information about it.

Windows and *nix have sufficiently different views of what processes
are (and who is allowed to find out what about them) that it is not
surprising that this is not catered for.

In fact, what you are doing is quite rare in *nix systems.  The only
common case is at the whole app level where some systems require only
a single copy to be running and that is enforced by some locking
mechanism (like the pid file technique) or an "execution" server (I
think that is how KDE does it for example).  It might help for you to
say why you want this mechanism.  There may be a better (or at least
more natural) solution to the base problem in *nix systems.

--
Ben.

[ Post a follow-up to this message ]

On Sep 9, 5:48 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:

> In fact, what you are doing is quite rare in *nix systems.  The only
> common case is at the whole app level where some systems require only
> a single copy to be running and that is enforced by some locking
> mechanism (like the pid file technique) or an "execution" server (I
> think that is how KDE does it for example).  It might help for you to
> say why you want this mechanism.  There may be a better (or at least
> more natural) solution to the base problem in *nix systems.

Exactly. What you are asking is difficult in UNIX-style operating
systems for good reasons. Why should my attempt to run your program be
affected by what someone else is doing that's none of my business?

Now, there might be a legitimate reason this should be the case. If
that's true, then what that reason is will determine how you proceed.

For example, suppose there's a machine-wide license that only permits
three users to access the program at a time. In that case, it is the
license that should be enforcing the limit, through some centralized
"license manager" that manages the license. If each program needs to
get permission to run from a manager, that manager can monitor the
program's lifespan.

If the logic is something else, the solution may be something else.

DS

[ Post a follow-up to this message ]

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

>In fact, what you are doing is quite rare in *nix systems.  The only
>common case is at the whole app level where some systems require only
>a single copy to be running and that is enforced by some locking
>mechanism (like the pid file technique) or an "execution" server (I
>think that is how KDE does it for example).  It might help for you to
>say why you want this mechanism.  There may be a better (or at least
>more natural) solution to the base problem in *nix systems.
>

If all one wishes to do is to track the number of copies of a given
executable within that executable, system V semaphores are an
appropriate API.

Use ftok(3)/semget(2) to get the semaphore and use semop(2) with SEM_UNDO
to increase the semaphore value each time the executable is run.  semctl(2)
can be used to determine the current sempahore value.

If one wishes to actually walk the active process list, for most flavors of
unix one can use opendir(3)/readdir(3)/closedir(3) or ftw(3)/nftw(3) to
walk the /proc directory.   This will be operating system specific as the
/proc implementations have subtle differences between SVR4-based unix system
s
and linux.

scott

[ Post a follow-up to this message ]

On Sep 10, 10:51 pm, sc...@slp53.sl.home (Scott Lurndal) wrote:
> Ben Bacarisse <ben.use...@bsb.me.uk> writes: 
>
> If all one wishes to do is to track the number of copies of a given
> executable within that executable, system V semaphores are an
> appropriate API.
>
> Use ftok(3)/semget(2) to get the semaphore and use semop(2) with SEM_UNDO
> to increase the semaphore value each time the executable is run.  semctl(2
)
> can be used to determine the current sempahore value.
>
> If one wishes to actually walk the active process list, for most flavors o
f
> unix one can use opendir(3)/readdir(3)/closedir(3) or ftw(3)/nftw(3) to
> walk the /proc directory.   This will be operating system specific as the
> /proc implementations have subtle differences between SVR4-based unix syst
ems
> and linux.
>
> scott

The reason for asking this question is that I just needed a quick
solution to stop a program
from using to much resources (out of memory = swapping). Yes I know
this exposes a badly
written app but instead of rewriting (something I don't have time for
now) I would rather just get rid of the problem by applying a
"dirtyfix" and rewrite it later when I have enough time ;)

[ Post a follow-up to this message ]

dirtcellar@gmail.com writes:

> On Sep 10, 10:51 pm, sc...@slp53.sl.home (Scott Lurndal) wrote: 
<snip>[vbcol=seagreen]
>
> The reason for asking this question is that I just needed a quick
> solution to stop a program
> from using to much resources (out of memory = swapping). Yes I know
> this exposes a badly
> written app but instead of rewriting (something I don't have time for
> now) I would rather just get rid of the problem by applying a
> "dirtyfix" and rewrite it later when I have enough time ;)

Ah.  If counting processes is a dirty solution, the problem must be an
app that forks too often.  If so, the best fix is to stop it doing
that!  The second best may well be to re-write it using threads.  The
third best is probably to use semaphores to count instances as the
"dirty fix".

--
Ben.

[ Post a follow-up to this message ]

Waxhead <zoiled@online.no> writes:
> programming in C I have tried to figure out what (Linux !?) API I
> should use to detect how many instances of my program are running. I
> have read about the pidfile method and also I had a quick look at
> semaphores but somehow I simply could not get it to work.
> What I'm trying to do is something like this:
> int main(void){int n; n=howmanyofme();if(n>3) printf("Over 3 instance
s
> \n");return 0;}

The only "correct" way to do it I know is to have a counting daemon,
to which each process will connect via a socket, and keep this
connection open its whole life.  The daemon will then be able to
detect when a such a process exits or is killed to decrement the
count.  Of course, nothing prevents the process to close that socket
and go on running.

As explained in the other answers, on unix there are other ways to
answer your real question, if only we knew what it is...

--
__Pascal Bourguignon__                     http://www.informatimago.com/

[ Post a follow-up to this message ]