There is no way to solve this in the general case. Whatever mechanism you come up with, I believe that it will always be possible to write a process that will elude you, unless you modify the way that processes are launched in the first place in order to track them that way.
Upstart has to deal with exactly the same problem to track if daemons are still running, and upstart job authors have to specify details (the number of forks) for upstart to track. Given that upstart cannot manage it without help, I don't think that you can, either. And upstart is even in control of the way that processes are launched, which I don't think you are here.
I think the best you can do is what you are doing already. Looking at /proc/<pid>/stat and /proc/<pid>/cmdline is a reasonably general way, but still will not catch every case. The pgrep command wraps this. If you aren't already using pgrep, take a look at the pgrep manpage for options of things you can match against.
Having said all that, I'm not convinced that you really need to do this in the first place. If you can't track the process, then I don't see how Unity could do this either. Wouldn't a better approach be to eliminate the application crashes in the first place? I would look into details of why your applications are crashing (surely that's a bug somewhere?), rather than trying to work around it as you have described. I wonder if this only affects Unity-aware applications which are calling back to Unity for extra functionality via DBus?
There is the infamous lsof:
sudo lsof /var/lib/dpkg/lock
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
aptitude 4974 root 3uW REG 8,23 0 815673 /var/lib/dpkg/lock
In this case aptitude is using the file. You should use root in case you are not sure which user is locking the file. It's useful for a bunch of things too, sadly it doesn't come installed with Ubuntu, so you have to install it first.
For the rest of mortals, there's the fuser command. This is peculiar since it only returns the PID instead of the name of the process:
➜ ~ sudo fuser /var/lib/dpkg/lock
/var/lib/dpkg/lock: 4974
Here it says that the file and PID, which is 4974, so we must investigate who is:
➜ ~ ps 4974
PID TTY STAT TIME COMMAND
4974 pts/1 Sl+ 0:06 aptitude
Best Answer
The
/procway would be to inspect theexelink in the directory corresponding to the pid.Let's take an example with
update-notifier:Find the pid, which is 15421 in this example:
Look up the symbolic link: