I've inherited a script that tries to detect if the LSF daemons are running by doing a ps and then grepping for a mess of stuff. I think that's error prone and I'm looking for a better way. The best I've found so far is the LSF command lsid, but that only indicates if LSF is installed and doesn't really tell me things are up and running. Short of submitting a job, has anybody got a better idea? This needs to work with Linux & Solaris.


In general:

The only safe way on Linux/Unix to know if a certain process is running or not is to use the pidfile approach.

This means:

  1. When you start the process you save the PID of the newly started process in a pidfile. Typically this file is saved where the process has its log files and a good name in your case would be lsf.pid (this kind of seems to be the convention for such files).

  2. Now you need a script to start/stop/show status of your process that takes the pidfile into account. There are lots of these on the Internet.

The major benefits of this approach is that you can do ps -p <pidno>. This is the ONLY safe way to identify if a process is running or not. Also the ps -p command is portable across Linux/Unix versions unlike so much of the other stuff you can find.

All in all: Yes, you can use an approach with grep'ing on various forms of output from ps command but it will never be a safe method and it is difficult to make truly portable. Bite the bullet and use the pidfile approach.

With regards to Solaris:

Your daemon should really run under SMF.

This solves all of your problems (you do not need the general approach described above) and at the same time it also gives you:

  1. Automatic startup at boot.
  2. Dependency management: The process is only started when dependencies that you define are met, such as "network is up" or whatever.
  3. Automatic restart if process failure.
  4. Automatic restart if dependencies are restarted (if you want it to).
  5. SMF keeps track of the whole problem of uniquely identifying your process.
  6. You can define how many times you will allow your service to run concurrently. Typically this is 1. This avoids that the process can be started in duplicate.
  7. Administration delegation. You can delegate in a safe way to others the right to start/stop the service without such user having access to the privileges that the service requires (it is kind of sudo on steroids).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.