Re: How can i check my script is already running?

One obvious source of error is that 'ps aux' is not portable - it only works with GNU ps. It will not, for example, work on Solaris, or on Windows. Take a look at Proc::ProcessTable instead, which supports the most common Unix variants - still no Win32 support though.

The approach taken by rsnapshot (backup software; needs to be safe and reliable) is to drop a PID file somewhere - the default is /var/run/rsnapshot.pid - and look for that when starting up. If it already exists, we read it to get the PID of the process that may be hanging around, and then try to send it a signal. If we can successfully send it a signal (ie, if a process with that PID exists) we log that, and stop. If there is no such process, then whether to continue or not is configurable.

This is safe - it guarantees that (provided nothing else messes with the PID file!) you won't have two instances of rsnapshot running at once. And it's *failsafe* because if rsnapshot exits without cleaning up the PID file *and* that PID is in use by something else next time rsnapshot runs, it still won't run. Better to miss a backup than to potentially have two backups fighting each other and screwing up.

Comment on Re: How can i check my script is already running?

Replies are listed 'Best First'.
Re^2: How can i check my script is already running? by afoken (Chancellor) on May 12, 2010 at 14:19 UTC
I would not consider a backup program "safe", "failsafe" or "reliable" if it stops working just because it left some arbitary file after a crash and refuses to write backups after that until someone manually removes that file. And I wouldn't consider it "safe", "failsafe" or "reliable" if it stops working because some long-running daemon accidentally has the process ID stored in that file. PID files always cause race conditions, that's why I don't use them. For daemons, the daemontools work fine without PID files, and as a nice side effect of the management done by daemontools, there is at any time at most one instance of any daemon under control of daemontools. For other programs, one has to define for which "circle" the "only one instance at a time" rule applies. Only one instance per machine works fine with a lock on the executable itself. Only one instance per machine per user already becomes difficult, because locking the executable would lock out other users. So one has to use a dedicated lock file below the users home directory. Only one instance per local network can become really tricky. With a distributed lock manager, you could still get away by locking a file on a shared drive, else you would need to implement some kind of IPC. And as soon as the circle becomes larger than a network of connected machines, I don't see any technical solution to prevent multiple instances. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply]

Replies are listed 'Best First'.

Re^2: How can i check my script is already running?
by afoken (Chancellor) on May 12, 2010 at 14:19 UTC

I would not consider a backup program "safe", "failsafe" or "reliable" if it stops working just because it left some arbitary file after a crash and refuses to write backups after that until someone manually removes that file. And I wouldn't consider it "safe", "failsafe" or "reliable" if it stops working because some long-running daemon accidentally has the process ID stored in that file.

PID files always cause race conditions, that's why I don't use them.

For daemons, the daemontools work fine without PID files, and as a nice side effect of the management done by daemontools, there is at any time at most one instance of any daemon under control of daemontools.

For other programs, one has to define for which "circle" the "only one instance at a time" rule applies. Only one instance per machine works fine with a lock on the executable itself. Only one instance per machine per user already becomes difficult, because locking the executable would lock out other users. So one has to use a dedicated lock file below the users home directory. Only one instance per local network can become really tricky. With a distributed lock manager, you could still get away by locking a file on a shared drive, else you would need to implement some kind of IPC. And as soon as the circle becomes larger than a network of connected machines, I don't see any technical solution to prevent multiple instances.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

[reply]