Results 1 to 7 of 7
I have a system could allow only one application running at any time. But without implementing any system wide protection or stamp. Application know nothing about running environment, will just ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 09-23-2011 #1
Common practice of preventing duplicate process?
I have a system could allow only one application running at any time. But without implementing any system wide protection or stamp. Application know nothing about running environment, will just go ahead and start.
Could use environment variable check or create something unique in system, and do check at the beginning of the application.
Curious about a common practice?
Please comment,
Thanks,
- 09-23-2011 #2
You can write a file to /var/run containing your process id, this is what many system processes do - take a look there you should see several named <service_name>.pid.
If you start a new instance you can check for the presence of that file and check that the pid in the file is still valid and quit if necessary. Don't forget to delete the pid file when your running process ends.Linux user #126863 - see http://linuxcounter.net/
- 09-30-2011 #3
solved
Thank you very much, that's exact what I want know.
- 09-30-2011 #4
Ultimate ps status source
Considering a rare case where the <service_name>.pid is off sync with the running process. #ps aux would be the ultimate source of actually runtime status.
Is there an existing tool to screen #ps aux output? Or I could implement a grep to search #ps aux output.
Would this be an overkilling thought, not necessary at all?
Please comment,
Thanks,
- 09-30-2011 #5Trusted Penguin
- Join Date
- May 2011
- Posts
- 3,657
I don't think it is overkill to run ps. In fact, I think it is smart (combined with the pidfile already mentioned). It can't be overkill after all, if you're only running it once (when the init script or whatever starts it up), right?
BTW, I think it's smart b/c sometimes your process dies unexpectedly and the pidfile does not get removed, and then your initscript thinks it is hung or whatever.
- 09-30-2011 #6
I think there are two separate issues.
1) Init script.
As roxoff already explained:
The init script of your service can
a) look for a pid file
and b) if there is one: check for a already running process.
"pgrep" is a slightly more elegant solution for that than ps + grep.
2) monitoring
For monitoring purposes you dont care so much which pid is running, just that a number of processes are running.
xymon for example has the PROC monitor, that can take a minimum and maximum of allowed processes.
From the xymon documentation:
# PROC processname minimumcount maximumcount color [TRACK=id] [TEXT=displaytext]
# The "ps" listing sent by the client will be scanned for how many
# processes containing "processname" are running, and this is then
# matched against the min/max settings defined here. If the running
# count is outside the thresholds, the color of the "procs" status
# changes to "color".You must always face the curtain with a bow.
- 09-30-2011 #7
Great thanks to all in depth comments and idea, I will go ahead implement it. Will append this thread if found something new and interesting.


Reply With Quote

