Running single binary/process on linux/unix

[reachvimalm]

How do I make sure in my linux binary that I run only single instance of it on particular machine and or for particular user? so that if other second one is run, it should exit with error.
thanks,
~Vimal

[writetonsharma]

create a pid file at some location which will have process id. all the instances will check for this pid, if its there exit or proceed with execution. during closing the process will delete this pid. this is one of the common ways in unix to stop multiple instances.
the common path can be /tmp.

[chrisname]

all the instances will check for this pid

How would you know what the PID is?

I agree though; it would definitely be best done through files (or a pipe or through signals, but you'd have to already know the process is there so that's redundant). You could fopen() a file in the /tmp directories; and write something to it... Then delete it when the process exits. If the file is there when an instance is loaded; there is already another instance running. Alternatively you could write the PID of the current process (make sure you don't write -1) and then kill that PID if the file is still there.
Maybe that's what writeonsharma meant.

[writetonsharma]

exactly. thats what i meant. :) sorry for not being very clear.
the file will have some naming convention, so it will be easy to find that file and inside that there will be pid, not necessarily pid, can be anything for that matter but pid looks fine.
at exit it will be deleted.

[reachvimalm]

thanks for reply.
But if someone deletes the file or process exits without cleaning up the file. will it work on production. I doubt.if process couldn't clean it up before exiting then somebody has to manually search for this file and delete it. what u say, how else we can do it.

[writetonsharma]

yes this can happen. you can lock the file so that it cannot be deleted.
for the second case if the application crashes the pid will not clean itself which needs to be deleted manually. (if your application crashes frequently this is not a good option.. :P)

alternate way can be reading the process table and see if your process is there in the list.
i have not done it but may be you can find something useful in /proc directory or google it to find how can you read process table in unix.

[reachvimalm]

any post production issue requiring manual intervention is not good option. how do u lock the file which can't be deleted. I don't think that there is any way you can do that.
regarding reading process table I don't know how to do it. anybody knows
?
thanks

[z05DSL3A]

Could you not do it with the folowing?
(it has been a while since I messed with the POSIX API):

int main()
{   
    sem_t *mysem;
    mysem = sem_open("MyUniqueName", O_CREAT|O_EXCL);
    if ( mysem == NULL )
    {      
        fprintf(stderr, "I am already running!\n");
        exit(1);
    }  
 
    /* the app code here*/    

    /* end of the app */   

    sem_unlink("MyUniqueName"); 
    sem_close(mysem);
}

^{(link with the POSIX pthread library).}

[reachvimalm]

good solution. Another could be binding on service. but above seems valid. in case of seg violation and others I think we can go unlink it in sig_handler.
thanks for nice solution.

[writetonsharma]

if application crashes in between what will happen? i have seen deadlocks even when the application restarts.

[z05DSL3A]

if application crashes in between what will happen?

I can't remember. If a *nix app crashes, is there any attempt to clean up or does it just core dump? I'm fairly sure that it can be handled gracefully somehow.

I remember doing this in my university days as an excises, I remember wrapping it in a class so that it was opened in the constructor and closed in the destructor when the object went out of scope.

[writetonsharma]

any application can crash, we cannot guarantee that the application will not crash. Destructors will only run if the application is closed correctly but during segmentation faults or any abnormal terminations the application will not get a chance to clean itself.

though we can catch all these exceptions by installing signals but then it will again go the first solution which i was talking about. the pid file.

[reachvimalm]

your solution was fine of file. But file can be deleted also accidently much easily.

[z05DSL3A]

any application can crash, we cannot guarantee that the application will not crash.

I never suggested otherwise.

though we can catch all these exceptions by installing signals...

As far as I'm concerned, all applications should be written in a manner that, in the face of catastrophic failure, do there best to clean up and exit gracefully.

I'm not saying that one solution is better than the other, just presenting an alternative.

[writetonsharma]

So where are we finally.. :)

Edit: looks like a new version of cplusplus.com.. new icons.. wow..

[reachvimalm]

semphore solution looks better for now until unless somebody can come up with much appealing solution.

[writetonsharma]

Looks better for sure..I agree..
but for simple things using complex solutions may not be a good idea..
just for one more try see how you can read the process table in unix. /proc directory contains information regarding running processes..

[vijkrr]

shared mem is one more concept that we can try. again the question will arise for the abnormal cresh.

In one of my application i've used this concept to start and stop the service with key_t as a configurable one.

[firedraco]

Destructors will only run if the application is closed correctly but during segmentation faults or any abnormal terminations the application will not get a chance to clean itself.

What? Doesn't that defeat the point of having destructors? If you throw and exception or something gets thrown/raised, AFAIK all the destructors are run.

[writetonsharma]

i am talking about crashes, core dumps etc etc..
throwing exceptions and catching them doesnt come in abnormal terminations. for those abnormal cases we need to take care of.. errors like segmentation fault cant be caught by exceptions.