How to avoid the binary to be launched more than one time in linux?

Question

I have a binary and it's a daemon and it's developed in C. I want to add a check at the beginning of my program to guarantee that the binary is launched only one time. My binary runs on Linux.

Any suggestions?

I think this is answered by http://stackoverflow.com/q/1599459/20270, though I'm hesitant to mark it as a duplicate. — Hasturkun, Jun 04 '13 at 16:20

score 5 · Accepted Answer · edited May 23 '17 at 12:28

5

A common method is to put a PID file in /var/run. After your daemon starts successfully, you flock write its PID to this file. At startup, you check the value of the PID in this file, if it exists. If there is no PID currently running, it's safe for the application to startup. If the PID exists, perform a check to see if that PID is an instance of your executable. If it's not, it is also safe to startup. You should delete the file on exit, but it's not strictly necessary.

edited May 23 '17 at 12:28

Community

1
1

answered Jun 04 '13 at 16:21

jason

236,483
35
423
525

2

Actually, using `flock` mostly saves you from needing to check if the PID exists, as if your program keeps the lock throughout its run, its being locked indicates that the process exists. – Hasturkun Jun 04 '13 at 16:25
@Hasturkun: The PID file has other uses, which is why it's often done this way. – jason Jun 04 '13 at 16:27
2

Stale pid files are evil: pids get reused, and on long-running servers many sysadmins will own up to having downtime as a result of accidentally killing the wrong process! It's not the end of the world if you can't clean up, but it's very sloppy not to try. Always clean up pidfiles when you exit. – Nicholas Wilson Jun 04 '13 at 16:34

pilcrow · Answer 2 · 2013-06-05T15:16:56.080

The best way to do this, in my opinion, is not to do it. Let your initialization scheme serialize instances of the daemon: systemd, runit, supervise, upstart, launchd, and so on can make sure there are no double invocations.

If you need to invoke your daemon "by hand," try the linux utility flock(1) or a 3rd-party utility like setlock. Both of these will run the daemon under the protection of a (perhaps inherited) lockfile which remains locked for the life of the program.

If you insist upon adding this functionality to the daemon itself (which, in my opinion, is complication that most daemons don't need), choose a lockfile and keep it exclusively flock(2)d. Unlike most pidfile/process table approaches, this approach is not race-prone. Unlike POSIX system semaphores, this mechanism will correctly handle the case of a crashed daemon (the lock vanishes when the process does).

There may be other easy serializations, too. If your daemon binds to a socket, you know that EADDRINUSE probably means that another instance is running...

score 0 · Answer 3 · answered Jun 04 '13 at 16:15

0

Fork and execute this:

 pidof nameOfProgram

If it returns a value, you know your program is running!

answered Jun 04 '13 at 16:15

KrisSodroski

2,796
3
24
39

With `pidof` you only know that a program having the same name (not even the same path) is in execution. `pidof` is also racy, since there is no locking between the execution of pidof and the starting of the process. This means you system would most probably fail if you do `./mybin & ./mybin &`. – Raúl Salinas-Monteagudo Jul 19 '17 at 07:56

score 0 · Answer 4 · answered Jun 04 '13 at 16:19

The other classic method is to have a lock file - the program creates a file, but only if that file does not already exist. If the file does exist, it presumes there's another copy of the program running. Because the program could crash after creating the file, smarter versions of this have ways to detect that situation.

How to avoid the binary to be launched more than one time in linux?

4 Answers4