Find the answer to your Linux question:
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.
  1. #1
    Just Joined! legendbb's Avatar
    Join Date
    Mar 2007
    Location
    Canada
    Posts
    27

    Cool 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,

  2. #2
    Super Moderator Roxoff's Avatar
    Join Date
    Aug 2005
    Location
    Nottingham, England
    Posts
    3,882
    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/

  3. #3
    Just Joined! legendbb's Avatar
    Join Date
    Mar 2007
    Location
    Canada
    Posts
    27

    Cool solved

    Thank you very much, that's exact what I want know.

  4. #4
    Just Joined! legendbb's Avatar
    Join Date
    Mar 2007
    Location
    Canada
    Posts
    27

    Smile Ultimate ps status source

    Quote Originally Posted by Roxoff View Post
    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.
    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,

  5. #5
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,353
    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.

  6. #6
    Trusted Penguin Irithori's Avatar
    Join Date
    May 2009
    Location
    Munich
    Posts
    3,390
    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.

  7. #7
    Just Joined! legendbb's Avatar
    Join Date
    Mar 2007
    Location
    Canada
    Posts
    27

    Wink

    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •